summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2020-04-29winsys/svga: Optionally avoid caching buffer mapsHEADmasterThomas Hellstrom4-12/+22
Mapping of graphics kernel buffers is quite costly. Therefore the svga drm winsys caches all kernel buffer maps. However, that may lead to less testing coverage of the unmap paths and (possibly) processes running out of virtual memory space. Introduce a possibility to avoid that caching by setting the environment variable SVGA_FORCE_KERNEL_UNMAPS to 1. Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com> Reviewed-by: Roland Scheidegger <sroland@vmware.com> Reviewed-by: Matthew McClure <mcclurem@vmware.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4804>
2020-04-29gallium/pipebuffer: Use persistent maps for slabsThomas Hellstrom3-4/+14
Instead of the ugly practice of relying on the provider caching maps, introduce and use persistent pipebuffer maps. Providers that can't handle persistent maps can't use the slab manager. The only current user is the svga drm winsys which always maps persistently. Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com> Reviewed-by: Charmaine Lee <charmainel@vmware.com> Reviewed-by: Brian Paul <brianp@vmware.com> Reviewed-by: Roland Scheidegger <sroland@vmware.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4804>
2020-04-29radv: Use smaller esgs_itemsize for ACO.Timur Kristóf4-23/+30
Signed-off-by: Timur Kristóf <timur.kristof@gmail.com> Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4388>
2020-04-29aco: Use new default driver locations.Timur Kristóf1-107/+17
The way the new locations are set up has much fewer gaps between each I/O slot, so this results in a massive reduction in the LDS usage of tessellation shaders. Totals (GFX10): VGPRS: 3976792 -> 3974864 (-0.05 %) Code Size: 260552784 -> 260532860 (-0.01 %) bytes LDS: 48723 -> 30179 (-38.06 %) blocks Max Waves: 1053407 -> 1053583 (0.02 %) Totals from affected shaders (1407 shaders on GFX10): SGPRS: 59144 -> 59216 (0.12 %) VGPRS: 63024 -> 61096 (-3.06 %) Code Size: 2695508 -> 2675584 (-0.74 %) bytes LDS: 47109 -> 28565 (-39.36 %) blocks Max Waves: 12999 -> 13175 (1.35 %) Signed-off-by: Timur Kristóf <timur.kristof@gmail.com> Reviewed-by: Rhys Perry <pendingchaos02@gmail.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4388>
2020-04-29radv: Use new linking helper to set default driver locations.Timur Kristóf2-0/+58
Signed-off-by: Timur Kristóf <timur.kristof@gmail.com> Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4388>
2020-04-29nir: Add new linking helper to set linked driver locations.Timur Kristóf2-0/+108
This commit introduces a new function nir_assign_linked_io_var_locations which is intended to help with assigning driver locations to shaders during linking, primarily aimed at the VS->TCS->TES->GS stages. It ensures that the linked shaders have the same driver locations, and it also packs these as close to each other as possible. Signed-off-by: Timur Kristóf <timur.kristof@gmail.com> Reviewed-by: Rhys Perry <pendingchaos02@gmail.com> Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4388>
2020-04-29aco: Set config->lds_size when TES or VS is running on HW ESGS.Timur Kristóf1-0/+1
This doesn't fix anything, just reports the LDS size used by merged ESGS shaders, such as vertex_geometry_gs and tess_eval_geometry_gs. Signed-off-by: Timur Kristóf <timur.kristof@gmail.com> Reviewed-by: Rhys Perry <pendingchaos02@gmail.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4388>
2020-04-29aco: Calculate workgroup size of legacy GS.Timur Kristóf1-1/+5
Signed-off-by: Timur Kristóf <timur.kristof@gmail.com> Reviewed-by: Rhys Perry <pendingchaos02@gmail.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4388>
2020-04-29aco: Remember VS/TCS output driver locations.Timur Kristóf2-10/+18
Instead of relying on calling shader_io_get_unique_index repeatedly, remember the which output driver location corresponds to which varying slot. Signed-off-by: Timur Kristóf <timur.kristof@gmail.com> Reviewed-by: Rhys Perry <pendingchaos02@gmail.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4388>
2020-04-29aco: Use context variables instead of calculating TCS inputs/outputs.Timur Kristóf2-11/+7
VS needs the number of TCS inputs, and TES needs the number of TCS outputs. It is error-prone to repeat those calculations in both instruction selection and setup. Just set them in one place instead. Signed-off-by: Timur Kristóf <timur.kristof@gmail.com> Reviewed-by: Rhys Perry <pendingchaos02@gmail.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4388>
2020-04-29radv: Refactor calculate_tess_lds_size and get_tcs_num_patches.Timur Kristóf3-21/+25
Previously these functions needed the bit mask of the TCS outputs and patch outputs written, and concluded the number of outputs from that. Now, they take the number of outputs and patch outputs instead. This will allow the backend compiler to better optimize the LDS layout. Signed-off-by: Timur Kristóf <timur.kristof@gmail.com> Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4388>
2020-04-29aco: consider blocks unreachable if they are in the logical cfgRhys Perry6-9/+2
unreachable was true if the last block is unreachable in the linear cfg, but it should also be true if it is unreachable in the logical cfg. Fixes dEQP-VK.graphicsfuzz.for-with-ifs-and-return Signed-off-by: Rhys Perry <pendingchaos02@gmail.com> Fixes: 8d8c864beba399ae4ee2267f680d1f600ad32767 ('aco: improve check for unreachable loop continue blocks') Reviewed-by: Daniel Schürmann <daniel@schuermann.dev> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4764>
2020-04-29egl/wayland: Fix zwp_linux_dmabuf usageChristopher James Halse Rogers1-12/+20
There's no guarantee that the formats advertised by wl_drm and the formats advertised by zwp_linux_dmabuf_v1 are the same. get_back_bo() handles this by falling back from createImageWithModifiers() to createImage() when there's a wl_drm format but no corresponding linux_dmabuf format, but create_wl_buffer() unconditionally tries to create a linux_dmabuf buffer unless DRIimage has DRM_FORMAT_MOD_INVALID. Fix this by always checking if the DRIimage modifier has been advertised by zwp_linux_dmabuf_v1, and falling back to wl_drm if not. If DRM_FORMAT_MOD_INVALID has been advertised then we trust the client has allocated something appropriate and treat any modifier as matching. Closes: https://gitlab.freedesktop.org/mesa/mesa/issues/2220 Signed-off-by: Christopher James Halse Rogers <christopher.halse.rogers@canonical.com> Reviewed-by: Daniel Stone <daniels@collabora.com> Reviewed-by: Simon Ser <contact@emersion.fr> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4294>
2020-04-29iris/bufmgr: Check if iris_bo_gem_mmap failedDanylo Piliaiev1-0/+8
After refactoring of iris_bo_map_cpu and iris_bo_map_wc - immediate return of NULL on failure to mmap a buffer was lost. Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/2855 Fixes: 5bc3f52dd8c2b5acaae959ccae2e1fb7c769bb22 Signed-off-by: Danylo Piliaiev <danylo.piliaiev@globallogic.com> Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4786>
2020-04-29anv: remove assert from GetImageMemoryRequirements[2]Tapani Pälli1-12/+0
This assert is actually correct but due to how android hardware buffer support is implemented we should remove it, otherwise debug build of mesa hits the assert with Android CTS tests. Test creates VkImage with non-external format and sets up VkExternalMemoryImageCreateInfo to indicate that image *may* be used with Android hardwarebuffer handle. Then test attempts to get image memory requirements. Problem with this is that we setup all android supporting images as having external format and thus hit the assert as the size has not been set yet. This is not a problem in practice since android will bind ahw memory with the image later on. Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/2807 Signed-off-by: Tapani Pälli <tapani.palli@intel.com> Acked-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4762>
2020-04-29gitlab-ci: add a list of expected failures for FIJI with ACOSamuel Pitoiset1-0/+36
Timur has this chip now. The depth stencil resolve failures are somehow unexpected. Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4805>
2020-04-29radv: advertise VK_EXT_robustness2Samuel Pitoiset3-1/+17
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com> Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4775>
2020-04-29radv: handle NULL vertex bindingsSamuel Pitoiset1-4/+7
With VK_EXT_robustness2, an element of pBuffers can be NULL. Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com> Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4775>
2020-04-29radv: handle NULL descriptorsSamuel Pitoiset1-2/+24
All fields must be zero, otherwise the HW hangs. Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com> Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4775>
2020-04-29aco: fix adjusting the sample index with FMASK if value is negativeSamuel Pitoiset1-2/+6
The SPIR-V spec doesn't say explicitly that the sample index must be an unsigned integer. This fixes crashes with some new VK_EXT_robustness2 tests. Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com> Reviewed-by: Daniel Schürmann <daniel@schuermann.dev> Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4775>
2020-04-29aco: fix nir_texop_texture_samples with NULL descriptorsSamuel Pitoiset1-2/+12
With VK_EXT_robustness2, descriptors can be NULL and the number of samples returned by nir_texop_texture_samples should be 0. Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com> Reviewed-by: Daniel Schürmann <daniel@schuermann.dev> Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4775>
2020-04-29ac/llvm: fix nir_texop_texture_samples with NULL descriptorsSamuel Pitoiset1-1/+22
With VK_EXT_robustness2, descriptors can be NULL and the number of samples returned by nir_texop_texture_samples should be 0. Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com> Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4775>
2020-04-29intel/fs: Only stall after sending all memory fence messagesCaio Marcelo de Oliveira Filho1-19/+16
In Gen11+, when emitting a fence for both L3 and SLM, the generated code would look like SEND, MOV (for stall), SEND, MOV (for stall) This commit change that so two SENDs are emitted before the MOVs for stall. This is similar to the approach used in Ivy Bridge for the render fence. Reviewed-by: Francisco Jerez <currojerez@riseup.net> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/3278>
2020-04-29intel/fs,vec4: Pull stall logic for memory fences up into the IRCaio Marcelo de Oliveira Filho7-109/+118
Instead of emitting the stall MOV "inside" the SHADER_OPCODE_MEMORY_FENCE generation, use the scheduling fences when creating the IR. For IvyBridge, every (data cache) fence is accompained by a render cache fence, that now is explicit in the IR, two SHADER_OPCODE_MEMORY_FENCEs are emitted (with different SFIDs). Because Begin and End interlock intrinsics are effectively memory barriers, move its handling alongside the other memory barrier intrinsics. The SHADER_OPCODE_INTERLOCK is still used to distinguish if we are going to use a SENDC (for Begin) or regular SEND (for End). This change is a preparation to allow emitting both SENDs in Gen11+ before we can stall on them. Shader-db results for IVB (i965): total instructions in shared programs: 11971190 -> 11971200 (<.01%) instructions in affected programs: 11482 -> 11492 (0.09%) helped: 0 HURT: 8 HURT stats (abs) min: 1 max: 3 x̄: 1.25 x̃: 1 HURT stats (rel) min: 0.03% max: 0.50% x̄: 0.14% x̃: 0.10% 95% mean confidence interval for instructions value: 0.66 1.84 95% mean confidence interval for instructions %-change: 0.01% 0.27% Instructions are HURT. Unlike the previous code, that used the `mov g1 g2` trick to force both `g1` and `g2` to stall, the scheduling fence will generate `mov null g1` and `mov null g2`. During review it was decided it was not worth keeping the special codepath for the small effect will have. Shader-db results for HSW (i965), BDW and SKL don't have a change on instruction count, but do report changes in cycles count, showing SKL results below total cycles in shared programs: 341738444 -> 341710570 (<.01%) cycles in affected programs: 7240002 -> 7212128 (-0.38%) helped: 46 HURT: 5 helped stats (abs) min: 14 max: 1940 x̄: 676.22 x̃: 154 helped stats (rel) min: <.01% max: 2.62% x̄: 1.28% x̃: 0.95% HURT stats (abs) min: 2 max: 1768 x̄: 646.40 x̃: 362 HURT stats (rel) min: <.01% max: 0.83% x̄: 0.28% x̃: 0.08% 95% mean confidence interval for cycles value: -777.71 -315.38 95% mean confidence interval for cycles %-change: -1.42% -0.83% Cycles are helped. This seems to be the effect of allocating two registers separatedly instead of a single one with size 2, which causes different register allocation, affecting the cycle estimates. while ICL also has not change on instruction count but report changes negative changes in cycles total cycles in shared programs: 352665369 -> 352707484 (0.01%) cycles in affected programs: 9608288 -> 9650403 (0.44%) helped: 4 HURT: 104 helped stats (abs) min: 24 max: 128 x̄: 88.50 x̃: 101 helped stats (rel) min: <.01% max: 0.85% x̄: 0.46% x̃: 0.49% HURT stats (abs) min: 2 max: 2016 x̄: 408.36 x̃: 48 HURT stats (rel) min: <.01% max: 3.31% x̄: 0.88% x̃: 0.45% 95% mean confidence interval for cycles value: 256.67 523.24 95% mean confidence interval for cycles %-change: 0.63% 1.03% Cycles are HURT. AFAICT this is the result of the case above. Shader-db results for TGL have similar cycles result as ICL, but also affect instructions total instructions in shared programs: 17690586 -> 17690597 (<.01%) instructions in affected programs: 64617 -> 64628 (0.02%) helped: 55 HURT: 32 helped stats (abs) min: 1 max: 16 x̄: 4.13 x̃: 3 helped stats (rel) min: 0.05% max: 2.78% x̄: 0.86% x̃: 0.74% HURT stats (abs) min: 1 max: 65 x̄: 7.44 x̃: 2 HURT stats (rel) min: 0.05% max: 4.58% x̄: 1.13% x̃: 0.69% 95% mean confidence interval for instructions value: -2.03 2.28 95% mean confidence interval for instructions %-change: -0.41% 0.15% Inconclusive result (value mean confidence interval includes 0). Now that more is done in the IR, more dependencies are visible and more SWSB annotations are emitted. Mixed with different register allocation decisions like above, some shaders will see more `sync nops` while others able to avoid them. Most of the new `sync nops` are also redundant and could be dropped, which will be fixed in a separate change. Reviewed-by: Francisco Jerez <currojerez@riseup.net> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/3278>
2020-04-29intel/fs: Allow FS_OPCODE_SCHEDULING_FENCE stall on registersCaio Marcelo de Oliveira Filho2-2/+30
It will generate the MOVs (or SYNC_NOP in Gen12+) needed for stall. Reviewed-by: Francisco Jerez <currojerez@riseup.net> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/3278>
2020-04-29radv: Expose 4G element texel buffers.Bas Nieuwenhuizen1-1/+1
Old value seems to be copied from anv. Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4787>
2020-04-29iris: Fix downcast of bound_vertex_buffers from uint64_t to intKenneth Graunke1-1/+1
This is the wrong data type, the original field - and the values we're adding in - are both 64-bit unsigned. Keep the original data type. Thanks to Dave Airlie for finding this while reading the code. Reviewed-by: Caio Marcelo de Oliveira Filho <caio.oliveira@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4802>
2020-04-28intel/ir: Remove scheduling-based cycle count estimates.Francisco Jerez3-26/+1
The cycle count estimation logic part of the scheduler is now redundant with the shader performance modeling pass, and the estimates can be consolidated into the brw::performance analysis result object instead of being part of the CFG, which guarantees that the estimates cannot be accessed without previously calling the performance_analysis::require() method, which makes sure that the right analysis pass is executed at the right time if we don't already have up-to-date cached results. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2020-04-28intel/ir: Pass block cycle count information explicitly to disassembler.Francisco Jerez5-6/+11
So we can eventually remove the cycle count estimates from the CFG data structure and consolidate performance information in the brw::performance object. It would be cleaner to pass the brw::performance object directly to the disassembler but that isn't straightforward since the disassembler is built as a plain C file unlike the rest of the compiler back-end. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2020-04-28intel/ir: Use brw::performance object instead of CFG cycle counts for ↵Francisco Jerez9-22/+45
codegen stats. These should be more accurate than the current cycle counts, since among other things they consider the effect of post-scheduling passes like the software scoreboard on TGL. In addition it will enable us to clean up some of the now redundant cycle-count estimation functionality in the instruction scheduler. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2020-04-28intel/fs: Add INTEL_DEBUG=no32 debugging flag.Francisco Jerez3-2/+5
This is useful in order to identify codegen issues caused by SIMD32. It doesn't currently have any effect on compute shaders since SIMD32 dispatch is only enabled for CS when it's strictly necessary to do so in order to support the workgroup size requested for the shader -- That might change in the future though when we hook up the SIMD32 heuristic to CS compilation. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2020-04-28intel/fs: Implement performance analysis-based SIMD32 heuristic for fragment ↵Francisco Jerez1-7/+17
shaders. The heuristic enables the SIMD32 fragment shader based on whether the IR performance modeling pass predicts it to have greater throughput than the SIMD16 and SIMD8 variants of the same shader. It would be straightforward to do the same thing in order to control whether SIMD16 dispatch is enabled, but it's pending additional performance evaluation. The INTEL_DEBUG=do32 option is left around in order to force the SIMD32 shader to be used regardless of the result of the heuristic, since it's useful as a debugging aid e.g. in order to identify SIMD32-specific codegen issues which may be masked by the SIMD32 heuristic, or cases where the heuristic is incorrectly disabling SIMD32 shaders that offer a performance advantage. Currently this is only enabled on Gen6+, since SIMD32 codegen support is incomplete on earlier platforms. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2020-04-28intel/fs: Heap-allocate fs_visitors in brw_compile_fs().Francisco Jerez1-38/+39
This makes brw_compile_fs() look a bit more similar to brw_compile_cs(). It saves us three v*_shader_stats local variables, and will save us additional triplicated declarations as we start tracking IR performance analysis results. The triplicated cfg pointers are left around because they're set to NULL to mark specific dispatch modes as disabled (e.g. in order to enforce hardware restrictions). Doing the same thing with the visitor pointers would cause data leaks. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2020-04-28intel/ir: Import shader performance analysis pass.Francisco Jerez8-1/+1660
This introduces an analysis pass intended to estimate several performance statistics of the shader, including cycle count latency and throughput values, based on static modeling. It has instruction performance information more comprehensive than the current scheduling pass for all platforms between Gen4-11, and works on both the FS and VEC4 back-end. The most immediate purpose of this pass is to implement a heuristic meant to determine whether using SIMD32 dispatch for a fragment shader can be expected to help more than it hurts. In addition this will allow the effect of passes run after scheduling (e.g. the TGL software scoreboard pass and the VEC4 dependency control pass) to be visible in shader-db statistics. But that isn't the end of the story, other potential applications of this pass (not part of this MR) I've been playing around with are: - Implement a similar SIMD16 heuristic allowing the identification of inefficient SIMD16 fragment shaders. - Implement similar SIMD16 and SIMD32 heuristics for the compute shader stage -- Currently compute shader builds always use the SIMD16 shader if available and never use the SIMD32 shader unless strictly necessary, which is suboptimal under certain conditions. - Hook up to the instruction scheduler in order to improve the accuracy of its timing information. - Use as heuristic in order to drive the selection of scheduling modes (Matt was experimenting with that). - Plug to the TGL software scoreboard pass in order to implement a more effective SBID token allocation algorithm, since in general the optimal token allocation depends on the timings of all instructions in the program. - Use its bottleneck detection functionality in order to implement a heuristic computing a more optimal bound for the number of fragment shader threads executed in parallel (by adjusting the MaximumNumberofThreadsPerPSD control of 3DSTATE_PS). As a follow-up I'm planning to submit updated timing information for Gen12 platforms -- Everything else required to support Gen12 like SWSB handling is already included in this patch, but there were some IP concerns regarding the TGL timing parameters since they cannot currently be obtained with the documentation and hardware which is publicly available. The timing parameters for any previous Gen7-11 platforms can be obtained by anyone by sampling the timestamp register using e.g. shader_time, though I have some more convenient instrumentation coming up. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2020-04-28intel/vec4: Fix constness of vec4_instruction::reads_flag() and ::writes_flag().Francisco Jerez1-2/+2
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2020-04-28intel/fs: Replace fs_visitor::bank_conflict_cycles() with stand-alone function.Francisco Jerez4-17/+17
This will be re-usable by the IR performance analysis pass. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2020-04-28intel/fs: Fix constness of argument of ↵Francisco Jerez1-2/+2
fs_instruction_scheduler::is_compressed(). Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2020-04-28intel/fs: Rename half() helpers to quarter(), allow index up to 3.Francisco Jerez4-14/+14
Makes more sense considering SIMD32. Relaxing the assertion in brw_ir_fs.h will be required in order to avoid assertion failures on SNB with SIMD32 fragment shaders. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2020-04-28intel/ir: Add missing initialization of backend_reg::offset during construction.Francisco Jerez1-1/+1
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2020-04-28intel/fs/gen12: Fix Render Target Read header setup for new thread payload ↵Francisco Jerez1-0/+17
layout. In Gen12 the Poly 0 Info DWORD containing the Viewport Index and Render Target Index fields were moved from r0.0 to r1.1 in order to make room for dual-polygon dispatch. The render target message format was updated to expect that information in the same location, so we didn't need to make any changes for framebuffer fetch to work with SIMD8 and SIMD16 dispatch. Unfortunately that won't work with SIMD32, since the render target message header is assembled from r0 and r2 instead of r1, and the r2 thread payload wasn't updated with an additional copy of the same information. We need to fix things up manually instead. This avoids a handful of EXT_shader_framebuffer_fetch regressions in combination with SIMD32 fragment shaders. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2020-04-28intel/fs/gen12: Work around dual-source blending hangs in combination with ↵Francisco Jerez1-2/+3
SIMD32. This applies the same work-around I commited as b84fa0b31e67 "intel/fs/gen11: Work around dual-source blending hangs in combination with SIMD32." to Gen12, which seems to suffer from the same hardware bug found empirically. The failure mode seems to be identical. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2020-04-28intel/fs/gen12: Fix hangs with per-sample SIMD32 fragment shader dispatch.Francisco Jerez1-3/+10
The Gen12 docs are rather contradictory regarding the dispatch configurations supported by the fragment shader -- The same table present in previous generations seems to imply that only one dispatch mode can be enabled when doing per-sample shading, but a restriction documented in the 3DSTATE_PS_BODY page implies the opposite: That SIMD32 can only be used in combination with some other dispatch mode. The latter seems to match the behavior of real hardware as I could tell from my testing: A bunch of multisample test-cases that do per-sample shading hang if we only provide a SIMD32 shader. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2020-04-29mesa: Follow OpenGL conversion rules for values that exceed storage sizeDylan Baker1-4/+33
Section 2.2.2 (Data Conversions For State Query Commands) of the OpenGL 4.5 spec says: Following these steps, if a value is so large in magnitude that it cannot be represented by the returned data type, then the nearest value representable using that type is returned. The current code doesn't do the correct thing, because it truncates a long (potentially a 64bit values) to an int. Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/2828 Fixes: 53c36dfcfe3eb3749a53267f054870280afb0d71 ("replace IROUND with util functions") Reviewed-by: Matt Turner <mattst88@gmail.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4673>
2020-04-29pan/bit: Add BITWISE testAlyssa Rosenzweig1-0/+32
Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4790>
2020-04-29pan/bit: Interpret BI_BITWISEAlyssa Rosenzweig1-2/+22
No shifting yet. Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4790>
2020-04-29pan/bi: Handle iand/ior/ixor in NIR->BIRAlyssa Rosenzweig1-0/+18
Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4790>
2020-04-29pan/bi: Pack BI_BITWISEAlyssa Rosenzweig2-2/+77
Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4790>
2020-04-29pan/bi: Add bitwise modifiersAlyssa Rosenzweig2-0/+12
Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4790>
2020-04-29freedreno/a6xx: invalidate tex state cache entries on rebindRob Clark3-1/+30
When a resource's backing bo changes, its seqno will be incremented. Which would result in a new tex state cache key, and nothing to clean up the old tex state until the sampler view/state is destroyed. But in some games, that may never happen, or at least not happen before we run out of memory. Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/2830 Signed-off-by: Rob Clark <robdclark@chromium.org> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4744>
2020-04-29freedreno: rebind_resource() *before* bo changesRob Clark1-4/+2
This will matter in the next patch, where we need the original rsc->seqno. It means slight shuffling of where we call rebind_resource() in the `fd_try_shadow_resource()` path. Signed-off-by: Rob Clark <robdclark@chromium.org> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4744>
generated by cgit v1.2.3 (git 2.39.1) at 2024-05-15 11:39:47 +0000