summaryrefslogtreecommitdiffstats
path: root/src/gallium
Commit message (Collapse)AuthorAgeFilesLines
* tgsi: add DDIV instructionNicolai Hähnle2017-01-164-1/+17
| | | | | | | | | Double-precision division, to allow more precision than a DRCP + DMUL sequence. Reviewed-by: Roland Scheidegger <[email protected]> Reviewed-by: Ilia Mirkin <[email protected]> Reviewed-by: Marek Olšák <[email protected]>
* radeonsi: fix R600_DEBUG=nooptvariantNicolai Hähnle2017-01-161-1/+1
| | | | | Reviewed-by: Marek Olšák <[email protected]> Reviewed-by: Vedran Miletić <[email protected]>
* radeonsi: implement GL_FIXED vertex formatMarek Olšák2017-01-163-7/+20
| | | | Reviewed-by: Nicolai Hähnle <[email protected]>
* radeonsi: implement 32-bit SNORM/UNORM/SSCALED/USCALED vertex formatsMarek Olšák2017-01-163-18/+90
| | | | Reviewed-by: Nicolai Hähnle <[email protected]>
* radeonsi: make fix_fetch 64-bitMarek Olšák2017-01-165-9/+9
| | | | | | v2: add u_bit_consecutive64 Reviewed-by: Nicolai Hähnle <[email protected]>
* gallium/hud: avoid buffer overrunThomas Hindoe Paaboel Andersen2017-01-161-2/+4
| | | | | | | | | | | | Renaming data sources was added in e8bb97ce30051b999a4a69c9b27884daeb8d71e6 It was possible to use a new name longer than the name array in hud_graph of 128. This patch truncates the name to fit the array. CC: Marek Olšák <[email protected]> Signed-off-by: Marek Olšák <[email protected]>
* gallium/radeon: add GPU-shaders-busy HUD queryMarek Olšák2017-01-164-1/+31
| | | | | | | It should be close to the GPU load, but it can be much lower if something is stalling shader execution (e.g. CP DMA). Reviewed-by: Nicolai Hähnle <[email protected]>
* gallium/radeon: make the GPU load / GRBM_STATUS monitoring extensibleMarek Olšák2017-01-163-32/+53
| | | | | | The next patch will add SPI_BUSY monitoring. Reviewed-by: Nicolai Hähnle <[email protected]>
* radeonsi: show average results per frame for perf counters in HUDMarek Olšák2017-01-161-1/+1
| | | | | | so that the graphs are independent from FPS. Reviewed-by: Nicolai Hähnle <[email protected]>
* gallium/hud: disable queries during HUD draw callsMarek Olšák2017-01-163-1/+29
| | | | Reviewed-by: Nicolai Hähnle <[email protected]>
* gallium/hud: increase the vertex buffer size for background quadsMarek Olšák2017-01-161-1/+1
| | | | Reviewed-by: Nicolai Hähnle <[email protected]>
* st/va: delay calling begin_frame until we have all parametersNayan Deshmukh2017-01-161-3/+3
| | | | | | | | | | If begin_frame is called before setting intra_matrix and non_intra_matrix it leads to segmentation faults when vl_mpeg12_decoder.c is used. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92634 Signed-off-by: Nayan Deshmukh <[email protected]> Reviewed-by: Christian König <[email protected]>
* nvc0/ir: emit FMZ flag when requested on FFMAIlia Mirkin2017-01-151-0/+4
| | | | Signed-off-by: Ilia Mirkin <[email protected]>
* st/va: flush pipeline after post processingsguttula2017-01-131-0/+1
| | | | | | | | This will flush the pipeline,which will allow to share dma-buf based buffers. Signed-off-by: Suresh Guttula <[email protected]> Reviewed-by: Christian König <[email protected]>
* radeonsi: replace si_shader_context::soa by bld_baseSamuel Pitoiset2017-01-133-82/+78
| | | | | | | | | | We no longer need to use lp_build_tgsi_soa_context. No regressions founds with full piglit run. Signed-off-by: Samuel Pitoiset <[email protected]> Reviewed-by: Nicolai Hähnle <[email protected]> Reviewed-by: Marek Olšák <[email protected]>
* radeonsi: replace ctx->soa.outputs by ctx->outputsSamuel Pitoiset2017-01-132-23/+26
| | | | | | | | | The plan is to replace si_shader_context::soa with its parent structure (ie. bld_base). Signed-off-by: Samuel Pitoiset <[email protected]> Reviewed-by: Nicolai Hähnle <[email protected]> Reviewed-by: Marek Olšák <[email protected]>
* radeonsi: move si_shader_context::soa::addr to si_shader_contextSamuel Pitoiset2017-01-133-11/+12
| | | | | | | | | The plan is to replace si_shader_context::soa with its parent structure (ie. bld_base). Signed-off-by: Samuel Pitoiset <[email protected]> Reviewed-by: Nicolai Hähnle <[email protected]> Reviewed-by: Marek Olšák <[email protected]>
* radeonsi: allocate the array of immediates dynamicallySamuel Pitoiset2017-01-133-13/+24
| | | | | | | | | | | | | | | Currently, we can store up to 256 immediates in a static array, but this is not always enough. Instead, allocate a dynamic array like what we currently do for temps. This fixes a segfault with dEQP-GLES31.functional.ssbo.layout.random.all_shared_buffer.23 No regressions found with full piglit run. Signed-off-by: Samuel Pitoiset <[email protected]> Reviewed-by: Nicolai Hähnle <[email protected]> Reviewed-by: Marek Olšák <[email protected]>
* nvc0/ir: only try to check for zero LOD if we aren't already forcing itIlia Mirkin2017-01-121-1/+1
| | | | | | | | | | There's a levelZero flag which forces texturing to pick level zero (and not consume an explicit LOD argument). This is set for MS targets, but could also be set for any other incoming instruction. As that is what determines whether a LOD argument is present, check that rather than the more indirect isMS logic. Signed-off-by: Ilia Mirkin <[email protected]>
* nouveau: take extra push space into account for pushbuf_space callsIlia Mirkin2017-01-1215-56/+26
| | | | | | | | | | | | | | | | | | | | | | Ever since a long time ago when I messed around with fences, I ensure that after a PUSH_SPACE call there is enough space to write a fence out into the pushbuf. However the PUSH_SPACE macro is not all-knowing, and so sometimes we have to invoke nouveau_pushbuf_space manually with the relocs/pushes args set. If we don't take the extra allocation from PUSH_SPACE into account, then we will end up accidentally flushing when the code was not expecting a flush. This can lead to various runtime and rendering failures. The amount of extra allocation isn't that important - it has to be at least 8 based on the current nouveau_winsys.h setting, but even more won't hurt. I just rounded up to powers of 2. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99354 Cc: "12.0 13.0" <[email protected]> Signed-off-by: Ilia Mirkin <[email protected]> Acked-by: Ben Skeggs <[email protected]>
* radeonsi: remove unused si_prepare_cube_coordsNicolai Hähnle2017-01-132-200/+0
| | | | | Reviewed-by: Bas Nieuwenhuizen <[email protected]> Reviewed-by: Marek Olšák <[email protected]>
* amd/common: unify cube map coordinate handling between radeonsi and radvNicolai Hähnle2017-01-133-1/+11
| | | | | | | | | | | | | | | Code is taken from a combination of radv (for the more basic functions, to avoid gallivm dependencies) and radeonsi (for the new and improved derivative calculations). v2: add 0.5 offset to tex coords only after derivative calculation v3: - really only touch the first three coordinates - rebase on the removal of the 1.5 --> 0.5 offset change Reviewed-by: Bas Nieuwenhuizen <[email protected]> (v2) Reviewed-by: Marek Olšák <[email protected]>
* radeonsi: only touch first three coordinates in si_prepare_cube_coordsNicolai Hähnle2017-01-131-12/+1
| | | | | | | | Sourcing coords_arg[4] is actually never correct, since bias is handled differently in tex_fetch_args anyway. Reviewed-by: Bas Nieuwenhuizen <[email protected]> Reviewed-by: Marek Olšák <[email protected]>
* radeonsi: remove unused si_llvm_cube_to_2d_coordsNicolai Hähnle2017-01-131-28/+0
| | | | | Reviewed-by: Bas Nieuwenhuizen <[email protected]> Reviewed-by: Marek Olšák <[email protected]>
* radeonsi: restrict cube map derivative computations to the correct planeNicolai Hähnle2017-01-131-23/+107
| | | | | | | | | | | | | | | | | | | | As remarked by the comment in the original code, the old algorithm fails when (tc + deriv) points at a different cube face. Instead, simply project the derivative directly to the plane of the selected cube face. The new code is based on exactly differentiating (using the chain rule) the projection onto a plane corresponding to a fixed cube map face (which is still selected in the usual way based on the texture coordinate itself). The computations end up fairly involved, but we do save two reciprocal computations. Fixes GL45-CTS.texture_cube_map_array.sampling. v2: add 0.5 offset to tex coords only after derivative calculation v3: go back to 1.5 offset Reviewed-by: Bas Nieuwenhuizen <[email protected]> (v2) Reviewed-by: Marek Olšák <[email protected]>
* radeonsi: communicate cube map coordinates more explicitlyNicolai Hähnle2017-01-131-33/+43
| | | | | | | v2: fix compile error that snuck in during rebase Reviewed-by: Bas Nieuwenhuizen <[email protected]> Reviewed-by: Marek Olšák <[email protected]>
* ac/debug: move .gitignore for sid_tables.h tooGrazvydas Ignotas2017-01-131-1/+0
| | | | | | | | b838f642 "ac/debug: Move sid_tables.h generation to common code." moved sid_tables.h but forgot the corresponding .gitignore. Signed-off-by: Grazvydas Ignotas <[email protected]> Reviewed-by: Nicolai Hähnle <[email protected]>
* glx: Add missing glproto dependency for gallium-xlib glxChuck Atkins2017-01-121-0/+1
| | | | | | | | Cc: [email protected] Cc: Bruce Cherniak <[email protected]> Signed-of-by: Chuck Atkins <[email protected]> Reviewed-by: Bruce Cherniak <[email protected]> Reviewed-by: Emil Velikov <[email protected]>
* ac, radeonsi: automake: add missing builddir includeEmil Velikov2017-01-121-0/+1
| | | | | | | | | | The generated file is correctly stored in the builddir as of earlier commit. Yet the commit forgot to add the respective include flag thus the compiler would error out failing to find sid_tables.h Bugzila: https://bugs.freedesktop.org/show_bug.cgi?id=99389 Fixes: d1dc22eb466 "ac: automake: rework sid_tables.h generation" Signed-off-by: Emil Velikov <[email protected]>
* st/nine: Protect dtors with mutexAxel Davy2017-01-124-19/+64
| | | | | | | | | | | | | | | | | | | | | When the flag D3DCREATE_MULTITHREAD is set, a global mutex is used to protect nine calls. However for performance reasons, AddRef and Release didn't hold the mutex, and instead used atomics. Unfortunately at item release, the item can be destroyed, and that destruction path should be protected by a mutex (at least for some objects). Without this patch, it is possible an app thread is in a dtor while another thread is making gallium nine calls. It is possible that two threads are using the same gallium pipe, which is forbiden. The problem has been made worse with csmt, because it can cause hang, since nine_csmt_process is not threadsafe. Fixes Hitman hang, and possibly others. Signed-off-by: Axel Davy <[email protected]>
* st/nine: Flush the queue at device dtorAxel Davy2017-01-121-1/+6
| | | | | | | | Flush the queue to get refcounts right, and properly release the items, instead of throwing away all pending commands. Signed-off-by: Axel Davy <[email protected]>
* st/nine: Process pending commands on ResetAxel Davy2017-01-123-0/+5
| | | | | | | | Some nine_state_* and nine_context_* functions used for Reset() require all pending commands are flushed. Signed-off-by: Axel Davy <[email protected]>
* st/nine: Flush pending commands if needed for surface9 changesAxel Davy2017-01-122-13/+32
| | | | | | | nine_context uses NineSurface9 fields, thus we need to flush pending commands using the surface before changing the fields. Signed-off-by: Axel Davy <[email protected]>
* st/nine: Rework CreatePipeSurfaceAxel Davy2017-01-122-22/+30
| | | | | | Create both surfaces in one call. Signed-off-by: Axel Davy <[email protected]>
* st/nine: Remove duplicated checksAxel Davy2017-01-122-10/+7
| | | | | | | | There is no need to check on csmt_active before calling nine_csmt_process, because the function checks already. Signed-off-by: Axel Davy <[email protected]>
* st/nine: Don't call u_box_union_* when dirty region is emptyMasanori Kakura2017-01-123-10/+22
| | | | | | | | | | When dirty region is empty, u_box_union_* incorrectly expands the new region. This fixes broken font rendering issue in WOLF RPG Editor v2.10 games. Signed-off-by: Masanori Kakura <[email protected]> Reviewed-by: Axel Davy <[email protected]>
* winsys/etnaviv: automake: introduce Makefile.sourcesEmil Velikov2017-01-122-1/+5
| | | | | | ... and list the public header within it. Signed-off-by: Emil Velikov <[email protected]>
* etnaviv: automake: include all files in the sources listsEmil Velikov2017-01-121-1/+9
| | | | | | Note: the currently mentioned etnaviv_utils.h is typo. Signed-off-by: Emil Velikov <[email protected]>
* imx: gallium driver for imx-drm scanout driverChristian Gmeiner2017-01-1212-0/+182
| | | | | | | | | | Changes from V1 -> V2: - updated Copyright - added $(top_srcdir)/src/gallium/winsys to include path (suggested by Emil) - adapted driver to new renderonly API Signed-off-by: Christian Gmeiner <[email protected]> Acked-by: Emil Velikov <[email protected]>
* etnaviv: gallium driver for Vivante GPUsThe etnaviv authors2017-01-1270-0/+14952
| | | | | | | | | | | | | | | | | This driver supports a wide range of Vivante IP cores like GC880, GC1000, GC2000 and GC3000. Changes from V1 -> V2: - added missing files to actually integrate the driver into build system. - adapted driver to new renderonly API Signed-off-by: Christian Gmeiner <[email protected]> Signed-off-by: Lucas Stach <[email protected]> Signed-off-by: Philipp Zabel <[email protected]> Signed-off-by: Rob Herring <[email protected]> Signed-off-by: Russell King <[email protected]> Signed-off-by: Wladimir J. van der Laan <[email protected]> Acked-by: Emil Velikov <[email protected]>
* gallium: add renderonly libraryChristian Gmeiner2017-01-125-0/+303
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This a very lightweight library to add basic support for renderonly GPUs. A kms gallium driver must specify how a renderonly_scanout objects gets created. Also it must provide file handles to the used kms device and the used gpu device. This could look like: struct renderonly ro = { .create_for_resource = renderonly_create_gpu_import_for_resource, .kms_fd = fd, .gpu_fd = open("/dev/dri/renderD128", O_RDWR | O_CLOEXEC) }; The renderonly_scanout object exits for two reasons: - Do any special treatment for a scanout resource like importing the GPU resource into the scanout hw. - Make it easier for a gallium driver to detect if anything special needs to be done in flush_resource(..) like a resolve to linear. A GPU gallium driver which gets used as renderonly GPU needs to be aware of the renderonly library. This library will likely break android support and hopefully will get replaced with a better solution based on gbm2. Changes from V1 -> V2: - reworked the lifecycle of renderonly object (suggested by Nicolai Hähnle) - killed the midlayer (suggested by Thierry Reding) - made the API more explicit regarding gpu and kms fd's - added some docs Signed-off-by: Christian Gmeiner <[email protected]> Acked-by: Emil Velikov <[email protected]> Tested-by: Alexandre Courbot <[email protected]>
* Always defer memory free in swr_resource_destroyGeorge Kyriazis2017-01-121-12/+5
| | | | | | | Defer delete on regular resources. This ensures that any work being done on the resource is completed before freeing up the resource's memory. Reviewed-by: Bruce Cherniak <[email protected]>
* nvc0: enable GL 4.3 on gm107+Samuel Pitoiset2017-01-121-7/+4
| | | | | | | | | | | | Although, arb_shader_image_load_store-atomicity will most likely hang your box, I think it's now quite reasonable to enable GL 4.3 on Maxwell/Pascal GPUs. I suspect that test to be wrong because it doesn't even work on the NVIDIA blob. I have tested a bunch of benchmarks (UE4 demos) and real games like Shadow of Mordor and they all work fine. Signed-off-by: Samuel Pitoiset <[email protected]>
* nvc0: use sched control codes for gm107 MP counters codeSamuel Pitoiset2017-01-121-44/+44
| | | | | Signed-off-by: Samuel Pitoiset <[email protected]> Reviewed-by: Pierre Moreau <[email protected]>
* nvc0: use sched control codes for gm107 blitter shaderSamuel Pitoiset2017-01-121-6/+14
| | | | | | Signed-off-by: Samuel Pitoiset <[email protected]> Reviewed-by: Pierre Moreau <[email protected]> Acked-by: Ilia Mirkin <[email protected]>
* nv50/ir: use sched control codes for gm107 builtinsSamuel Pitoiset2017-01-122-40/+40
| | | | | | | | | | Yes, IMUL/IMAD require dependency barriers and we should definitely replace these instructions by XMAD but the different flags need to be figured out. Note that XMAD only supports 16-bits integers. Signed-off-by: Samuel Pitoiset <[email protected]> Reviewed-by: Pierre Moreau <[email protected]>
* nv50/ir: improve instruction pipelining on gm107Samuel Pitoiset2017-01-123-4/+1027
| | | | | | | | | | | | | | | | | | | | | This makes use of scheduling control codes which are very useful for improving the instruction pipelining. This patch will increase performance on Maxwell GPUs by, at least, x1.5 up to x3.5 for some benchmarks. Although this has been fairly well tested, I would not be suprised if someone hit a corner case somewhere. That way, the scheduler is enabled by default but it can be deactivated by using NV50_PROG_SCHED=0. Thanks to Scott Gray for the reverse engineering work available from https://github.com/NervanaSystems/maxas/wiki/Control-Codes. Signed-off-by: Samuel Pitoiset <[email protected]> Acked-by: Pierre Moreau <[email protected]> Tested-by: Alexandre Courbot <[email protected]> Tested-by: Jan Vesely <[email protected]>
* nv50/ir: do not insert texture barriers on gm107Samuel Pitoiset2017-01-121-1/+2
| | | | | | | | | | It's actually useless to insert those texture barriers post RA because the current control code (ie. st 0x0) will wait for all dependencies before issuing a new instruction. Signed-off-by: Samuel Pitoiset <[email protected]> Reviewed-by: Ilia Mirkin <[email protected]> Reviewed-by: Pierre Moreau <[email protected]>
* radeonsi: num_records is in units of stride for swizzled buffers even on VINicolai Hähnle2017-01-121-2/+0
| | | | | | The old setting didn't hurt, but this is cleaner. Reviewed-by: Marek Olšák <[email protected]>
* clover: Check for executables before enqueueing a kernelPierre Moreau2017-01-111-1/+4
| | | | | | | | | | Without this check, the kernel::bind() method would fail with a std::out_of_range exception, letting an exception escape from the library into the client, rather than returning the corresponding error code CL_INVALID_PROGRAM_EXECUTABLE. Signed-off-by: Pierre Moreau <[email protected]> Reviewed-by: Francisco Jerez <[email protected]>