summaryrefslogtreecommitdiff
path: root/src
Commit message (Collapse)AuthorAgeFilesLines
* util/rb_tree: Add the unit testsJason Ekstrand2019-09-202-0/+199
| | | | | | | When I wrote the red-black tree implementation, I wrote tests for it but they never got imported into mesa. Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
* anv: implement ICD interface v4Eric Engestrom2019-09-201-1/+29
| | | | | | Signed-off-by: Eric Engestrom <eric.engestrom@intel.com> Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
* anv: split instance dispatch tableEric Engestrom2019-09-203-1/+198
| | | | | | | | | | | | | This effectively breaks the instance dispatch table in 2 with entry points using a physical device as first argument getting their own dispatch table. As a result we now have to check instance & physical device dispatch table instead of just the instance dispatch table before. Signed-off-by: Eric Engestrom <eric.engestrom@intel.com> Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
* glx: Fix drawable lookup bugs in glXUseXFontAdam Jackson2019-09-191-16/+6
| | | | | | | | | | | | We were using the current drawable of the context to name the appropriate screen for creating the bitmaps. But one, the current drawable can be None, and two, it can be a GLXDrawable. Passing either one as the second argument to XCreatePixmap will throw BadDrawable. Use the root window of the context's screen instead. Gitlab: https://gitlab.freedesktop.org/mesa/mesa/issues/89 LOLed-by: Kristian H. Kristensen <hoegsberg@google.com> Reviewed-by: Kristian H. Kristensen <hoegsberg@google.com>
* glx: Avoid atof() when computing the server's GLX versionAdam Jackson2019-09-191-1/+2
| | | | | | | | | | | atof() is locale-dependent (sigh), which means 1.3 becomes 1.0 if the locale's decimal separator isn't a full-stop. Just use the protocol major/minor instead. This would be slightly broken if the server generically implements 1.3+ but a particular screen is only capable of less, but in practice no such servers exist. Gitlab: https://gitlab.freedesktop.org/mesa/mesa/issues/74 Reviewed-by: Eric Engestrom <eric.engestrom@intel.com>
* nir/algebraic: Additional D3D Boolean optimizationIan Romanick2019-09-191-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | I observed this pattern in several shaders in Hand of Fate 2 while investigating bugzilla #111490. This also led to the related bugzilla #111578. The shaders from HoF2 are *not* in shader-db. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> Skylake and Ice Lake had similar results. (Ice Lake shown) total instructions in shared programs: 16222621 -> 16205419 (-0.11%) instructions in affected programs: 798418 -> 781216 (-2.15%) helped: 548 HURT: 0 helped stats (abs) min: 2 max: 158 x̄: 31.39 x̃: 35 helped stats (rel) min: 0.45% max: 28.64% x̄: 2.83% x̃: 2.09% 95% mean confidence interval for instructions value: -33.22 -29.56 95% mean confidence interval for instructions %-change: -3.11% -2.56% Instructions are helped. total cycles in shared programs: 364676209 -> 363345763 (-0.36%) cycles in affected programs: 112810504 -> 111480058 (-1.18%) helped: 546 HURT: 7 helped stats (abs) min: 2 max: 118913 x̄: 2439.77 x̃: 2340 helped stats (rel) min: 0.08% max: 37.56% x̄: 1.46% x̃: 1.08% HURT stats (abs) min: 2 max: 770 x̄: 238.00 x̃: 43 HURT stats (rel) min: 0.02% max: 11.24% x̄: 3.71% x̃: 0.35% 95% mean confidence interval for cycles value: -2884.33 -1927.41 95% mean confidence interval for cycles %-change: -1.59% -1.21% Cycles are helped. total spills in shared programs: 8870 -> 8514 (-4.01%) spills in affected programs: 1230 -> 874 (-28.94%) helped: 161 HURT: 0 total fills in shared programs: 21901 -> 21348 (-2.52%) fills in affected programs: 2120 -> 1567 (-26.08%) helped: 155 HURT: 5 Broadwell and Haswell had similar results. (Broadwell shown) total instructions in shared programs: 14994910 -> 14975495 (-0.13%) instructions in affected programs: 839033 -> 819618 (-2.31%) helped: 548 HURT: 0 helped stats (abs) min: 2 max: 299 x̄: 35.43 x̃: 49 helped stats (rel) min: 0.39% max: 19.89% x̄: 2.91% x̃: 2.22% 95% mean confidence interval for instructions value: -37.46 -33.40 95% mean confidence interval for instructions %-change: -3.12% -2.70% Instructions are helped. total cycles in shared programs: 386032453 -> 384450722 (-0.41%) cycles in affected programs: 117807357 -> 116225626 (-1.34%) helped: 547 HURT: 6 helped stats (abs) min: 2 max: 22096 x̄: 2892.01 x̃: 3926 helped stats (rel) min: 0.17% max: 10.34% x̄: 1.56% x̃: 1.31% HURT stats (abs) min: 4 max: 60 x̄: 32.83 x̃: 29 HURT stats (rel) min: 0.38% max: 12.79% x̄: 5.86% x̃: 4.65% 95% mean confidence interval for cycles value: -3060.28 -2660.27 95% mean confidence interval for cycles %-change: -1.59% -1.37% Cycles are helped. total spills in shared programs: 23372 -> 21869 (-6.43%) spills in affected programs: 11730 -> 10227 (-12.81%) helped: 352 HURT: 0 total fills in shared programs: 34747 -> 35351 (1.74%) fills in affected programs: 11013 -> 11617 (5.48%) helped: 3 HURT: 347 Ivy Bridge and Sandybridge had similar results. (Ivy Bridge shown) total instructions in shared programs: 11956420 -> 11956126 (<.01%) instructions in affected programs: 14898 -> 14604 (-1.97%) helped: 98 HURT: 0 helped stats (abs) min: 3 max: 3 x̄: 3.00 x̃: 3 helped stats (rel) min: 1.30% max: 3.57% x̄: 2.08% x̃: 2.00% 95% mean confidence interval for instructions value: -3.00 -3.00 95% mean confidence interval for instructions %-change: -2.18% -1.98% Instructions are helped. total cycles in shared programs: 178791217 -> 178790792 (<.01%) cycles in affected programs: 149763 -> 149338 (-0.28%) helped: 91 HURT: 7 helped stats (abs) min: 3 max: 107 x̄: 20.63 x̃: 16 helped stats (rel) min: 0.13% max: 6.91% x̄: 1.40% x̃: 1.18% HURT stats (abs) min: 3 max: 322 x̄: 207.43 x̃: 322 HURT stats (rel) min: 0.14% max: 19.85% x̄: 12.73% x̃: 17.41% 95% mean confidence interval for cycles value: -18.94 10.27 95% mean confidence interval for cycles %-change: -1.28% 0.49% Inconclusive result (value mean confidence interval includes 0).
* nir/algebraic: Do not apply late DPH optimization in vertex processing stagesIan Romanick2019-09-191-3/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Some shaders do not use 'invariant' in vertex and (possibly) geometry shader stages on some outputs that are intended to be invariant. For various reasons, this optimization may not be fully applied in all shaders used for different rendering passes of the same geometry. This can result in Z-fighting artifacts (at best). For now, disable this optimization in these stages. In tessellation stages applications seem to use 'precise' when necessary, so allow the optimization in those stages. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111490 Fixes: 09705747d72 ("nir/algebraic: Reassociate fadd into fmul in DPH-like pattern") All Gen8+ platforms had similar results. (Ice Lake shown) total instructions in shared programs: 16194726 -> 16344745 (0.93%) instructions in affected programs: 2855172 -> 3005191 (5.25%) helped: 6 HURT: 20279 helped stats (abs) min: 1 max: 3 x̄: 1.33 x̃: 1 helped stats (rel) min: 0.44% max: 1.00% x̄: 0.54% x̃: 0.44% HURT stats (abs) min: 1 max: 32 x̄: 7.40 x̃: 7 HURT stats (rel) min: 0.14% max: 42.86% x̄: 8.58% x̃: 6.56% 95% mean confidence interval for instructions value: 7.34 7.45 95% mean confidence interval for instructions %-change: 8.48% 8.67% Instructions are HURT. total cycles in shared programs: 364471296 -> 365014683 (0.15%) cycles in affected programs: 32421530 -> 32964917 (1.68%) helped: 2925 HURT: 16144 helped stats (abs) min: 1 max: 403 x̄: 18.39 x̃: 5 helped stats (rel) min: <.01% max: 22.61% x̄: 1.97% x̃: 1.15% HURT stats (abs) min: 1 max: 18471 x̄: 36.99 x̃: 15 HURT stats (rel) min: 0.02% max: 52.58% x̄: 5.60% x̃: 3.87% 95% mean confidence interval for cycles value: 21.58 35.41 95% mean confidence interval for cycles %-change: 4.36% 4.52% Cycles are HURT.
* Move blob from compiler/ to util/Jason Ekstrand2019-09-1915-23/+24
| | | | | | | | There's nothing whatsoever compiler-specific about it other than that's currently where it's used. Reviewed-by: Kristian H. Kristensen <hoegsberg@google.com> Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
* Revert "panfrost: Rework midgard_pair_load_store() to kill the nested ↵Boris Brezillon2019-09-191-29/+34
| | | | | | | | | | foreach loop" There's a missing prev_ldst = NULL; assignment in the new logic, but even with this fixed it seems to regress some applications, so let's revert the change until we find the real problem. This reverts commit c9bebae2877e55cdcd94f9f9f3f6805238caeb28.
* intel/fs: Add Fall-through commentCaio Marcelo de Oliveira Filho2019-09-191-0/+3
| | | | Reviewed-by: Andres Gomez <agomez@igalia.com>
* nir/algebraic: refactor inexact opcode restrictionsSamuel Iglesias Gonsálvez2019-09-191-3/+5
| | | | | | | | | | Refactor the code to avoid calling a lot of time to auxiliary functions when it is not really needed. Signed-off-by: Samuel Iglesias Gonsálvez <siglesias@igalia.com> Reviewed-by: Caio Marcelo de Oliveira Filho <caio.oliveira@intel.com> Reviewed-by: Kristian H. Kristensen <hoegsberg@google.com> Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
* docs: Update bug report URLs for the gitlab migrationAdam Jackson2019-09-191-1/+1
| | | | | | Cc: mesa-stable@lists.freedesktop.org Reviewed-by: Eric Anholt <eric@anholt.net> Reviewed-by: Eric Engestrom <eric.engestrom@intel.com>
* glx: Remove redundant null check.Bas Nieuwenhuizen2019-09-191-1/+1
| | | | | Gitlab: https://gitlab.freedesktop.org/mesa/mesa/issues/64 Reviewed-by: Adam Jackson <ajax@redhat.com>
* iris: Skip double-disabling TCS/TES/GS after BLORP operationsKenneth Graunke2019-09-191-0/+17
| | | | | | | | | | | BLORP always turns off TCS/TES/GS. If regular drawing also has them disabled (the overwhelmingly common case), then leaving them disabled is just fine by us and we can skip dirtying them, as that would just re-disable them a second time on the next draw. If they are actually enabled, however, we do need to flag them. Cuts 52% of the 3DSTATE_HS packets in an Aztec Ruins trace.
* anv: fix descriptor limits on gen8Arcady Goldmints-Orlov2019-09-192-4/+6
| | | | | | | | | | | | | | Later generations support bindless for samplers, images, and buffers and thus per-stage descriptors are not limited by the binding table size. However, gen8 doesn't support bindless images and thus needs to report a lower per-stage limit so that all combinations of descriptors that fit within the advertised limits are reported as supported by vkGetDescriptorSetLayoutSupport. Fixes test dEQP-VK.api.maintenance3_check.descriptor_set Fixes: 79fb0d27f3 ("anv: Implement SSBOs bindings with GPU addresses in the descriptor BO") Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
* radv: remove dead shared variablesDaniel Schürmann2019-09-191-1/+1
| | | | | | | LLVM does this anyway, but for ACO we need to do it in NIR. Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com> Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
* radv/aco: enable VK_EXT_shader_demote_to_helper_invocationDaniel Schürmann2019-09-193-0/+8
| | | | | | | For now, this extension will only be enabled for ACO. Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com> Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
* radv: enable clustered reductionsDaniel Schürmann2019-09-191-0/+1
| | | | | | | These work with both, LLVM and ACO. Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com> Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
* radv/aco: Setup alternate path in RADV to support the experimental ACO compilerDaniel Schürmann2019-09-1911-103/+205
| | | | | | | | | | LLVM remains default and ACO can be enabled with RADV_PERFTEST=aco. Co-authored-by: Daniel Schürmann <daniel@schuermann.dev> Co-authored-by: Rhys Perry <pendingchaos02@gmail.com> Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com> Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
* aco: Initial commit of independent AMD compilerDaniel Schürmann2019-09-1931-0/+25572
| | | | | | | | | | | | | | | | | | | | | | ACO (short for AMD Compiler) is a new compiler backend with the goal to replace LLVM for Radeon hardware for the RADV driver. ACO currently supports only VS, PS and CS on VI and Vega. There are some optimizations missing because of unmerged NIR changes which may decrease performance. Full commit history can be found at https://github.com/daniel-schuermann/mesa/commits/backend Co-authored-by: Daniel Schürmann <daniel@schuermann.dev> Co-authored-by: Rhys Perry <pendingchaos02@gmail.com> Co-authored-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl> Co-authored-by: Connor Abbott <cwabbott0@gmail.com> Co-authored-by: Michael Schellenberger Costa <mschellenbergercosta@googlemail.com> Co-authored-by: Timur Kristóf <timur.kristof@gmail.com> Acked-by: Samuel Pitoiset <samuel.pitoiset@gmail.com> Acked-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
* egl: check for NULL value like eglGetSyncAttribKHR doesTapani Pälli2019-09-191-0/+4
| | | | | | | | | | | | | Commit d1e1563bb63 added a NULL check for eglGetSyncAttribKHR but eglGetSyncAttrib does not do this. Patch adds same check to happen with eglGetSyncAttrib. Fixes crashes in (when exposing EGL 1.5): dEQP-EGL.functional.fence_sync.invalid.get_invalid_value Signed-off-by: Tapani Pälli <tapani.palli@intel.com> Reviewed-by: Eric Engestrom <eric.engestrom@intel.com> Cc: mesa-stable@lists.freedesktop.org
* iris: Rework iris_update_draw_parameters to be more efficientKenneth Graunke2019-09-183-40/+56
| | | | | | | | | | | | | | | | | | | | | | | | | | This improves a couple of things: 1. We now only update anything if the shader actually cares. Previously, is_indexed_draw was causing us to flag dirty vertex buffers, elements, and SGVs every time the shader switched between indexed and non-indexed draws. This is a very common situation, but we only need that information if the shader uses gl_BaseVertex. We were also flagging things when switching between indirect/direct draws as well, and now we only bother if it matters. 2. We upload new draw parameters only when necessary. When we detect that the draw parameters have changed, we upload a new copy, and use that. Previously we were uploading it every time the vertex buffers were dirty (for possibly unrelated reasons) and the shader needed that info. Tying these together also makes the code a bit easier to follow. In Civilization VI's benchmark, this code was flagging dirty state many times per frame (49 average, 16 median, 614 maximum). Now it occurs exactly once for the entire run.
* iris: Use state_refs for draw parameters.Kenneth Graunke2019-09-183-23/+21
| | | | | iris_state_ref is a <resource, offset> tuple, which is exactly what we need here.
* util/disk_cache: make use of the total job size limiting featureTimothy Arceri2019-09-191-1/+1
| | | | | | | | | | | This makes use of the total job size limiting feature added in the previous patch. The idea is to avoid an excessive build up in memory use due to the use of both the UTIL_QUEUE_INIT_RESIZE_IF_FULL and UTIL_QUEUE_INIT_USE_MINIMUM_PRIORITY flags. Reviewed-by: Marek Olšák <marek.olsak@amd.com>
* util/u_queue: track job size and limit the size of queue growthTimothy Arceri2019-09-199-13/+28
| | | | | | | | | | | | | | | | | | | | | When both UTIL_QUEUE_INIT_RESIZE_IF_FULL and UTIL_QUEUE_INIT_USE_MINIMUM_PRIORITY are set, we can get into a situation where the queue never executes and grows to a huge size due to all other threads being busy. This is the case with the shader cache when attempting to compile a huge number of shaders up front. If all threads are busy compiling shaders the cache queues memory use can climb into the many GBs very fast. The use of these two flags with the shader cache is intended to allow shaders compiled at runtime to be compiled as fast as possible. To avoid huge memory use but still allow the queue to perform optimally in the run time compilation case, we now add the ability to track memory consumed by the jobs in the queue and limit it to a hardcoded 256MB which should be more than enough. Reviewed-by: Marek Olšák <marek.olsak@amd.com>
* util/disk_cache: bump thread count assigned to disk cache queueTimothy Arceri2019-09-191-3/+7
| | | | | | | | | | | | | | | Since we set the UTIL_QUEUE_INIT_USE_MINIMUM_PRIORITY flag this should have little impact on low core systems. However just about all modern CPUs currently available that run Mesa have *at least* 4 cores. For these CPUs allowing more threads can result in the queue being processed faster and avoid excessive memory use due to a backlog of cache entrys building up in the queue. This change helps avoid a huge build up of cache entrys in the queue due to using both the UTIL_QUEUE_INIT_USE_MINIMUM_PRIORITY and UTIL_QUEUE_INIT_RESIZE_IF_FULL flags. Reviewed-by: Marek Olšák <marek.olsak@amd.com>
* intel/fs: fix SHADER_OPCODE_CLUSTER_BROADCAST for SIMD32Paulo Zanoni2019-09-191-1/+10
| | | | | | | | | | | | | The current code can create functions with a width of 32, which is not supported by our hardware. Add some code to simplify how we express what we want and prevent such cases. For some unknown reason, all the tests I could run seem to work even with these unsupported MOVs. Fixes: b0858c1cc6 "intel/fs: Add a couple of simple helper opcodes" Reviewed-by: Jason Ekstrand <jason@jlekstrand.net> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
* intel/fs: the maximum supported stride width is 16Paulo Zanoni2019-09-191-1/+3
| | | | | | | | | | | | | | | | There are cases where we try to generate registers with a stride of 32, while the hardware maximum is just 16. This happens, for example, when using 8 bit integers on SIMD32. This results in a crash because the variable 'width' has a value of 32: ../../src/intel/compiler/brw_reg.h:550: brw_reg brw_vecn_reg(unsigned int, brw_reg_file, unsigned int, unsigned int): Assertion `!"Invalid register width"' failed. This change prevents the crash and makes the tests pass. Reviewed-by: Jason Ekstrand <jason@jlekstrand.net> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
* intel/fs: roll the loop with the <0,1,0> additions in emit_scan()Paulo Zanoni2019-09-191-32/+14
| | | | | | | | | | | | IMHO the code is easier to understand this way, being explicit that we're doing exactly the same thing every time. No functional changes. v2: Adjust the loop breaking condition (Jason). Reviewed-by: Jason Ekstrand <jason@jlekstrand.net> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
* intel/fs: make scan/reduce work with SIMD32 when it fits 2 registersPaulo Zanoni2019-09-191-0/+23
| | | | | | | | | | | | When dealing with uint16_t and uint8_t on SIMD32 we can do all the operations using just 2 registers, so we don't hit the recursion at the beginning of emit_scan(). Because of that, we need to actually compute scan/reduce for channels 31:16. v2: Still missed instructions (Jason). Reviewed-by: Jason Ekstrand <jason@jlekstrand.net> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
* freedreno/regs: A couple of tess updatesKristian H. Kristensen2019-09-182-3/+41
| | | | Reviewed-by: Eric Anholt <eric@anholt.net>
* freedreno/regs: Fix CP_DRAW_INDX_OFFSET commandKristian H. Kristensen2019-09-181-0/+14
| | | | | | On A5xx+ the INDX_BASE pointer is 64 bit. Reviewed-by: Eric Anholt <eric@anholt.net>
* freedreno/a6xx: Write multiple regs for SP_VS_OUT_REG and SP_VS_VPC_DST_REGKristian H. Kristensen2019-09-181-6/+5
| | | | | | | Compute the number of writes up front. Signed-off-by: Kristian H. Kristensen <hoegsberg@google.com> Reviewed-by: Eric Anholt <eric@anholt.net>
* freedreno/a6xx: Turn on vectorize_ioKristian H. Kristensen2019-09-181-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We want this for tessellation eventually, but we can turn it on now. Shader-db results: total instructions in shared programs: 8612905 -> 8611387 (-0.02%) instructions in affected programs: 164952 -> 163434 (-0.92%) total dwords in shared programs: 11952000 -> 11950560 (-0.01%) dwords in affected programs: 68096 -> 66656 (-2.11%) total full in shared programs: 315019 -> 315009 (<.01%) full in affected programs: 1642 -> 1632 (-0.61%) total constlen in shared programs: 2463654 -> 2463654 (0.00%) constlen in affected programs: 0 -> 0 total (ss) in shared programs: 152379 -> 152409 (0.02%) (ss) in affected programs: 1503 -> 1533 (2.00%) total (sy) in shared programs: 96473 -> 96525 (0.05%) (sy) in affected programs: 654 -> 706 (7.95%) total max_sun in shared programs: 1172454 -> 1172472 (<.01%) max_sun in affected programs: 104 -> 122 (17.31%) Signed-off-by: Kristian H. Kristensen <hoegsberg@google.com> Reviewed-by: Eric Anholt <eric@anholt.net>
* freedreno/a6xx: Share shader state constructor and destructorKristian H. Kristensen2019-09-186-190/+76
| | | | | | | Also, swap vs and fs constructor or so fs comes first. Signed-off-by: Kristian H. Kristensen <hoegsberg@google.com> Reviewed-by: Eric Anholt <eric@anholt.net>
* freedreno/a6xx: Track location of gl_Position out as we link itKristian H. Kristensen2019-09-183-13/+13
| | | | | | | | | | | | | | When using xfb and rasterizing, the fragment shader may have fewer inputs than the vertex shader outputs. We can't rely on gl_Position to be placed at fs->total_in, but have to instead remember where we add it in the link map and use that location. Fixes 100+ tesselation dEQPs under dEQP-GLES31.functional.tessellation.primitive_discard.* dEQP-GLES31.functional.tessellation.user_defined_io.* Reviewed-by: Eric Anholt <eric@anholt.net>
* spirv: Add missing break for capability handlingCaio Marcelo de Oliveira Filho2019-09-181-0/+1
| | | | | | | New added cases "stole" the previous break. Fixes: 420ad0a1a3d ("spirv: check support for SPV_KHR_float_controls capabilities") Reviewed-by: Eric Engestrom <eric.engestrom@intel.com>
* iris: Avoid uploading SURFACE_STATE descriptors for UBOs if possibleKenneth Graunke2019-09-183-17/+53
| | | | | | | | | | | | | | | | | | If we can entirely push uniform data, we don't need a SURFACE_STATE descriptor for pulling data. Since constant uploads are a very common operation, and being able to push all data is also very common, we would like to avoid the overhead in this case. This patch defers uploading new descriptors. Instead of handling that at iris_set_constant_buffer, we do it at iris_update_compiled_shaders, where we can see the currently bound shader variants. If any need pull descriptors, and descriptors are missing, we update them and flag that the binding table also needs to be refreshed. Improves performance in GFXBench5 gl_driver2 on an i7-6770HQ by 31.9774% +/- 1.12947% (n=15). Reviewed-by: Caio Marcelo de Oliveira Filho <caio.oliveira@intel.com>
* intel/compiler: Record whether any pull constant loads occurKenneth Graunke2019-09-183-0/+11
| | | | | | | | | | | | | | | | | | | | | | | | I would like for iris to be able to avoid setting up SURFACE_STATE for UBOs in the common case where all constants are pushed. Unfortunately, we don't know up front whether everything will be pushed: the backend is allowed to demote pushed UBOs to pull loads fairly late in the process. This is probably desirable though, as we'd like the backend to be able to re-pull pushed data to break up long live ranges in response to register pressure. Here we simply add a "are there any pull loads at all" boolean to prog_data, which is a bit crude but at least allows us to skip work in the common "everything pushed" case. We could skip more work by tracking exactly which UBO surfaces are pulled in a bitmask, but I wanted to avoid bringing back the old mark_surface_used() mechanism. Finer-grained tracking could allow us to skip a bit more work when multiple UBOs are in use and /some/ are 100% pushed, but others are accessed via pulls. However, I'm not sure how common this is and it would save at most 4 pull descriptors, so we defer that for now. Reviewed-by: Caio Marcelo de Oliveira Filho <caio.oliveira@intel.com>
* iris: Track per-stage bind history, reduce work accordinglyKenneth Graunke2019-09-184-6/+16
| | | | | | | | | | | | | | We now track per-stage bind history for constant and shader buffers, shader images, and sampler views by adding an extra res->bind_stages field to go with res->bind_history. This lets us flag IRIS_DIRTY_CONSTANTS for only the specific stages involved, and also skip some CPU overhead in iris_rebind_buffer. Cuts 4% of 3DSTATE_CONSTANT_XS packets in a Shadow of Mordor trace on Icelake. Reviewed-by: Caio Marcelo de Oliveira Filho <caio.oliveira@intel.com>
* iris: Don't flag IRIS_DIRTY_BINDINGS for constant usage historyKenneth Graunke2019-09-181-2/+1
| | | | | | | | | | | | | | | | | | | The underlying buffer isn't changing - so we don't need to update any SURFACE_STATE descriptors - we just might have new constants, meaning we need to re-emit 3DSTATE_CONSTANT_XS. On Gen9, this means we need to update 3DSTATE_BINDING_TABLE_POINTERS_XS too, but that's now handled by the explicit check in the previous patch. On Gen9, this should cause us to re-emit the binding table /pointer/ on writing to a buffer with PIPE_BIND_CONSTANT_BUFFER, rather than emitting a whole new /table/. On Gen8 and Gen11, this avoids binding table churn altogether. Cuts 61% of 3DSTATE_BINDING_TABLE_POINTERS_XS packets in a Shadow of Mordor trace on Icelake. Reviewed-by: Caio Marcelo de Oliveira Filho <caio.oliveira@intel.com>
* iris: Explicitly emit 3DSTATE_BTP_XS on Gen9 with DIRTY_CONSTANTS_XSKenneth Graunke2019-09-181-1/+6
| | | | | | | | | | | | | Right now, we usually flag both IRIS_DIRTY_{CONSTANTS,BINDINGS}_XS, because we have SURFACE_STATE for constant buffers in case the shaders access them via pull mode. But this flagging is overkill in many cases. Gen8 and Gen11 don't need it at all. Gen9 doesn't need that large of a hammer in all cases. Just handle it explicitly so the right thing happens. Reviewed-by: Caio Marcelo de Oliveira Filho <caio.oliveira@intel.com>
* iris: Flag IRIS_DIRTY_BINDINGS_XS on constant buffer rebindsKenneth Graunke2019-09-181-1/+2
| | | | | | | We upload a new SURFACE_STATE for the UBO/SSBO in question, which means that we need new binding tables as well. Reviewed-by: Caio Marcelo de Oliveira Filho <caio.oliveira@intel.com>
* radv: Add DFSM support.Bas Nieuwenhuizen2019-09-181-5/+17
| | | | | | | | | | | | Apparently we already enabled it without having support ... Not sure if we also need to set disable_start_of_prim when the PS has memory writes, but this mirrors radeonsi. Doubles fillrate in my dual_quad_bench from ~16 pixels/cycles to ~32 pixels/cycle on a Raven. Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
* radv: Disable dfsm by default even on Raven.Bas Nieuwenhuizen2019-09-182-3/+4
| | | | | | When actually implementing it, Talos on low is still 3% slower. Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
* radv: Only break batch on framebuffer change with dfsm.Bas Nieuwenhuizen2019-09-181-1/+1
| | | | Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
* nir/opt_if: Fix undef handling in opt_split_alu_of_phi()Connor Abbott2019-09-181-55/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The pass assumed that "Most ALU ops produce an undefined result if any source is undef" which is completely untrue. Due to how we lower if statements to selects and then optimize on those selects later, we simply cannot make that assumption. In particular this pass tried to replace an ior of undef and true, which had been generated by optimizing a select which itself came from flattening an if statement, to undef causing a miscompilation for a CTS test with radeonsi NIR. We fix this by always doing what the non-undef path did, i.e. duplicate the instruction twice. If there are cases where the instruction before the loop can be folded away due to having an undef source, we should add these to opt_undef instead. The comment above the pass says that if the phi source from before the loop is undef, and we can fold the instruction before the loop to undef, then we can ignore sources of the original instruction that don't dominate the block before the loop because we don't need them to create the instruction before the loop. This is incorrect, because the instruction at the bottom of the loop would get those sources from the wrong loop iteration. The code never actually did what the comment said, so we only have to update the comment to match what the pass actually does. We also update the example to more closely match what most actual loops look like after vtn and peephole_select. There are no shader-db changes with i965, radeonsi NIR, or radv. With anv and my vkpipeline-db there's only one change: total instructions in shared programs: 14125290 -> 14125300 (<.01%) instructions in affected programs: 2598 -> 2608 (0.38%) helped: 0 HURT: 1 total cycles in shared programs: 2051473437 -> 2051473397 (<.01%) cycles in affected programs: 36697 -> 36657 (-0.11%) helped: 1 HURT: 0 Fixes KHR-GL45.shader_subroutine.control_flow_and_returned_subroutine_values_used_as_subroutine_input with radeonsi NIR.
* gl: drop incorrect pkg-config file for glvndEric Engestrom2019-09-181-12/+2
| | | | | | | | | | | | | | | Akin to 1a25980c469b38d2c645 ("egl: drop incorrect pkg-config file for glvnd") and b01524fff05eef66e8cd ("meson: don't build libGLES*.so with GLVND") , removes a pkg-config file that shouldn't have been there in the first place, but was needed because of that GLVND bug. Now that the glvnd bug has been fixed, it was apparent that this gl.pc pkg-config file was forgotten to be removed, so let's do just that :) Suggested-by: Matt Turner <mattst88@gmail.com> Cc: mesa-stable@lists.freedesktop.org Signed-off-by: Eric Engestrom <eric.engestrom@intel.com> Reviewed-by: Matt Turner <mattst88@gmail.com>
* nir/opcodes: Clear variable names confusionAndres Gomez2019-09-181-10/+15
| | | | | | | | | | | Having Python and C variables sharing name in the same block of code makes its understanding a bit confusing. Make it explicit that the Python bit_size variable refers to the destination bit size. Suggested-by: Caio Marcelo de Oliveira Filho <caio.oliveira@intel.com> Signed-off-by: Andres Gomez <agomez@igalia.com> Reviewed-by: Jason Ekstrand <jason@jlekstrand.net> Reviewed-by: Caio Marcelo de Oliveira Filho <caio.oliveira@intel.com>
* radv: never kill a NGG GS shaderRhys Perry2019-09-181-1/+3
| | | | | | | | Seems to fix a hang with excessive vertex emissions when NGG is used for GS. Signed-off-by: Rhys Perry <pendingchaos02@gmail.com> Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
View Lorry Controller Status