- Mar 14, 2020
-
-
Icenowy Zheng authoredSigned-off-by:Icenowy Zheng <icenowy@aosc.io>
-
Fragment shader can write depth and stencil if we set necessary flags in RSW. In addition to that we need to use special format for Z24S8. Original format is apparently Z24X8 since we can't sample stencil in GLES2. Signed-off-by:
Vasily Khoruzhick <anarsoul@gmail.com>
-
Matt Turner authored
EXPECT_DEATH works by forking the process and letting the forked process fail with an assertion. This process is evidently incredibly expensive, taking ~30 seconds to run the whole isl_aux_info_test on a 2.8GHz Skylake. Annoyingly all of the (expected) assertion failures also leaves lots of messages in dmesg and potentially generates lots of coredumps. Instead, avoid the expense of fork/exec by redefining assert() and unreachable() in the code we're testing to return a unit-test-only value. With this patch, the test takes ~1ms. Also, while modifying the EXPECT_EQ() calls, reverse the arguments so that the expected value comes first, as is intended. Otherwise gtest failure messages don't make much sense. Fixes: mesa/mesa#2567 Reviewed-by:
Nanley Chery <nanley.g.chery@intel.com> Tested-by: Marge Bot <mesa/mesa!4174> Part-of: <mesa/mesa!4174>
-
- Mar 13, 2020
-
-
Jan Zielinski authoredReviewed-by:
Alok Hota <alok.hota@intel.com>
In LLVM11, ConstantVector::getSplat() function definition
has changed and the first function argument has now ElementCount type.
Tested-by: Marge Bot <mesa/mesa!4188>
Part-of: <mesa/mesa!4188> -
Christian Gmeiner authored
We are not using any pctx reference in the shader so it seems fine to enable this cap. Signed-off-by:
Christian Gmeiner <christian.gmeiner@gmail.com> Reviewed-by:
Lucas Stach <l.stach@pengutronix.de> Tested-by: Marge Bot <!4095> Part-of: <!4095>
-
Christian Gmeiner authored
There is no need to have a complete copy of etna_spec - just reference the one and only from etna_screen. Signed-off-by:
-
Faith Ekstrand authoredReviewed-by:
Lionel Landwerlin <lionel.g.landwerlin@intel.com> Tested-by: Marge Bot <mesa/mesa!4173> Part-of: <mesa/mesa!4173>
-
Rhys Perry authoredThis allows us to move v_cvt_pkrtz_f16_f32 instructions upwards, improving schedules and (somewhat unintentionally) moving the exports slightly closer together. Totals from affected shaders: SGPRS: 1030224 -> 1030248 (0.00 %) VGPRS: 794080 -> 794392 (0.04 %) Spilled SGPRs: 127117 -> 127117 (0.00 %) Spilled VGPRs: 0 -> 0 (0.00 %) Scratch size: 0 -> 0 (0.00 %) dwords per thread Code Size: 89028152 -> 89032312 (0.00 %) bytes LDS: 0 -> 0 (0.00 %) blocks Max Waves: 65252 -> 65219 (-0.05 %) SMEM score: 843808.00 -> 843918.00 (0.01 %) VMEM score: 5331687.00 -> 5397802.00 (1.24 %) SMEM clauses: 567659 -> 567655 (-0.00 %) VMEM clauses: 290715 -> 290716 (0.00 %) Instructions: 17143219 -> 17144259 (0.01 %) Cycles: 1098442808 -> 1098446968 (0.00 %) Signed-off-by:
Rhys Perry <pendingchaos02@gmail.com> Reviewed-by:
Daniel Schürmann <daniel@schuermann.dev> Tested-by: Marge Bot <mesa/mesa!3776> Part-of: <mesa/mesa!3776>
-
Rhys Perry authored
Much better scheduling apparently in 160 shaders Totals from affected shaders: SGPRS: 6272 -> 6344 (1.15 %) VGPRS: 4832 -> 4844 (0.25 %) Spilled SGPRs: 0 -> 0 (0.00 %) Spilled VGPRs: 0 -> 0 (0.00 %) Scratch size: 0 -> 0 (0.00 %) dwords per thread Code Size: 467192 -> 467428 (0.05 %) bytes LDS: 459 -> 459 (0.00 %) blocks Max Waves: 1407 -> 1409 (0.14 %) SMEM score: 9309.00 -> 11216.00 (20.49 %) VMEM score: 26679.00 -> 33652.00 (26.14 %) SMEM clauses: 1817 -> 1776 (-2.26 %) VMEM clauses: 2286 -> 2288 (0.09 %) Instructions: 86537 -> 86596 (0.07 %) Cycles: 676260 -> 676568 (0.05 %) Signed-off-by:
-
Rhys Perry authored
Pipeline-db changes in 721 shaders. Totals from affected shaders: SGPRS: 42336 -> 42656 (0.76 %) VGPRS: 38368 -> 38636 (0.70 %) Spilled SGPRs: 11967 -> 11967 (0.00 %) Spilled VGPRs: 0 -> 0 (0.00 %) Scratch size: 0 -> 0 (0.00 %) dwords per thread Code Size: 52680886 -> 5269840 (0.03 %) bytes LDS: 1069 -> 1069 (0.00 %) blocks Max Waves: 4473 -> 4447 (-0.58 %) SMEM score: 41155.00 -> 41826.00 (1.63 %) VMEM score: 146339.00 -> 147471.00 (0.77 %) SMEM clauses: 24434 -> 24535 (0.41 %) VMEM clauses: 16637 -> 16592 (-0.27 %) Instructions: 996037 -> 996388 (0.04 %) Cycles: 76476112 -> 75281416 (-1.56 %) Signed-off-by:
-
Rhys Perry authored
No pipeline-db changes Signed-off-by:
-
Samuel Pitoiset authored
To match aco_compile_shader(). Signed-off-by:
Samuel Pitoiset <samuel.pitoiset@gmail.com> Reviewed-by:
Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl> Tested-by: Marge Bot <mesa/mesa!4163> Part-of: <mesa/mesa!4163>
-
Samuel Pitoiset authored
They are already included from src/amd/llvm. Signed-off-by:
-
Samuel Pitoiset authored
Signed-off-by:
-
Samuel Pitoiset authored
Signed-off-by:
-
Danylo Piliaiev authoredFixes: 67b32190 Closes: mesa/mesa#2619 Signed-off-by:
Danylo Piliaiev <danylo.piliaiev@globallogic.com> Reviewed-by:
Timothy Arceri <tarceri@itsqueeze.com> Tested-by: Marge Bot <mesa/mesa!4146> Part-of: <mesa/mesa!4146>
-
- Mar 12, 2020
-
-
Caio Oliveira authored
Also use a single condition statement instead of two. Reviewed-by:
Jason Ekstrand <jason@jlekstrand.net> Tested-by: Marge Bot <mesa/mesa!4040> Part-of: <mesa/mesa!4040>
-
Caio Oliveira authored
The batch associated with the compute pipeline only needs room for a MEDIA_VFE_STATE. So this patch moves the batch_data to each pipeline struct and cap the one in compute pipeline. Reviewed-by:
-
Caio Oliveira authored
Add two new structs that use the anv_pipeline as base. Changed all functions that work on a specific pipeline to use the corresponding struct. Reviewed-by:
-
Caio Oliveira authored
This is a preparation for splitting the compute and graphics pipelines into separate structs. Reviewed-by:
-
Caio Oliveira authored
Explicitly pass the active stages and the array (and size) of shaders to be processed. This will make easy to store only the shaders needed for each pipeline. The active stages can be identified by a non-NULL shader in the shaders array, so stop using it and keep track of the flushed stages as iteration happens. Reviewed-by:
-
Caio Oliveira authored
Pass the `anv_shader_bin *` instead of expecting the helpers to peek into the pipeline struct. Also reach for the device from the cmd_buffer instead of the pipeline. Reviewed-by:
Ian Romanick <ian.d.romanick@intel.com> Reviewed-by:
-
Caio Oliveira authored
These helpers are only called for stages that are active, so the code for a non-active stage is never executed. Reviewed-by:
-
Caio Oliveira authored
The caller has this information, so pass directly instead of making each helper function call figure that one out. Also, since we can reach the pipeline from pipe_state, drop that parameter from the function. Reviewed-by:
-
Caio Oliveira authored
This will be used to decouple the logic flush_descriptor_sets() from the position in the shader array, allowing us to store just the shaders needed for each pipeline. Reviewed-by:
-
Caio Oliveira authored
Avoids waste for pipelines that don't use all the shaders, and is flexible enough to cover cases where there are multiple variants per shader (e.g. SIMD8/16/32 for fragment shader). Even though we could pre-calculate the exact size of the array, this is not a critical path so it is worth preventing the bug that will likely happen when new variants are added but not accounted for. Reviewed-by:
-
Caio Oliveira authored
Reviewed-by:
-
Caio Oliveira authored
Reviewed-by:
-
Emma Anholt authored
We were wasting 4s on waiting for expected-not-to-appear files to show up on every test. Using timeouts in test code is error-prone anyway, as our shared runners may be busy on other jobs. Fixes: 50989f87 ("util/disk_cache: use a thread queue to write to shader cache") Link: mesa/mesa#2505 Reviewed-by:
-
Emma Anholt authored
A recent pipeline (https://gitlab.freedesktop.org/Venemo/mesa/-/jobs/1893357 ) failed with what looks like an intermittent error related to making files for the cache test inside of the core of the cache. Given some of the errors, it looks like maybe a mkdir failed, so log those errors earlier so we can debug what's going on next time. Reviewed-by:
-
Caio Oliveira authored
This will avoid generating multiple identical fences in a row. For Gen11+ we have multiple types of fences (affecting different variable modes), but is still better to combine them in a single scoped barrier so that the translation to backend IR have the option of dispatching both fences in parallel. This will clean up redundant barriers from various dEQP-VK.memory_model.* tests. Reviewed-by:
-
Caio Oliveira authored
SPIR-V generates very granular barriers, however HW and backends might not necessarily take advantage of those. This pass provides a general mechanism to combine such barriers. Reviewed-by:
Eric Anholt <eric@anholt.net> Reviewed-by:
-
Caio Oliveira authored
Makes code comparing and combining scopes slightly more readable. Reviewed-by:
-
Caio Oliveira authored
There was another enum entry in the draft versions of nir_memory_semantics, but when it got dropped the entries were not updated. Reviewed-by:
-
Samuel Pitoiset authored
Based on PAL and RadeonSI. Signed-off-by:
-
Samuel Pitoiset authored
Based on PAL and RadeonSI. Signed-off-by:
-
Samuel Pitoiset authored
Based on PAL and RadeonSI. Signed-off-by:
-
Samuel Pitoiset authored
Based on PAL and RadeonSI. Signed-off-by:
-
Samuel Pitoiset authored
Based on PAL and RadeonSI. Signed-off-by:
-
Faith Ekstrand authored
In ISL, usage flags only carry intent and not semantic meaning. We don't have a bulletproof way in ISL to specify that an image is of depth/stencil type. The usage flags are great but blorp, for instance, loves to disrespect them. One proposed solution to this problem is to add explicit depth/stencil formats which are distinct from the corresponding color formats. Fortunately, however, empirical evidence suggests that this bit only affects the sampler's interpretation of the CCS data. Therefore, we can set the bit based off of the aux_usage which is now very specific and does carry semantic meaning. In particular, aux_usage now makes a distinction between color CCS and depth/stencil CCS which appears to be exactly what the DepthStencilResource bit is for. Reviewed-by:
-
