Commits on Source (83)
-
Currently `util_idalloc_foreach()` isn't being used in the codebase but if used it causes a build error as `num_used` doesn't exist. Fix that by using `num_set_elements`. Fixes: 0589dfe4 ("util/idalloc: optimize foreach by tracking the greatest non-zero element") Signed-off-by:
Karmjit Mahil <karmjit.mahil@igalia.com> Reviewed-by:
Marek Olšák <marek.olsak@amd.com> Part-of: <!32546>
-
Changes the `for` loop code to be similar to `util_idalloc_forach_no_zero_safe()` for cohesion. Signed-off-by:
-
Signed-off-by:
Jordan Justen <jordan.l.justen@intel.com> Reviewed-by:
José Roberto de Souza <jose.souza@intel.com> Part-of: <!32359>
-
Signed-off-by:
-
Signed-off-by:
-
Rather than checking hwconfig items when using them, wait until after devinfo has been fully initialized. This includes having workarounds implemented. We can then check if the hwconfig data and final Mesa initialization agree. If the match fails, we need to investigate if Mesa or the hwconfig data is wrong. This code becomes a no-op when not on a release build. Fixes: a4c5bfd3 ("intel/dev: Use hwconfig for urb min/max entry values") Closes: #12141 Signed-off-by:
-
Foz-DB Navi31: Totals from 2561 (3.23% of 79206) affected shaders: CodeSize: 10399004 -> 10389120 (-0.10%) Reviewed-by:
Rhys Perry <pendingchaos02@gmail.com> Part-of: <!32532>
-
Part-of: <!32574>
-
Seems like the multiview feature unlocked some tests that triggers a previously unknown bug. This results in an assert triggering, but that reveals a real, underlying issue. A few of these doesn't trigger the assert, but still fails due to a GPU hang. Let's mark all of these as failures, to avoid holding back other MRs in the mean time. Part-of: <!32574>
-
Reviewed-by:
Samuel Pitoiset <samuel.pitoiset@gmail.com> Part-of: <!32518>
-
Reviewed-by:
-
This reduces the fixed function hardware bottleneck in vertex shading heavy sections with d3d9 DXVK. DXVK always declares 6 clip distances, and with https://github.com/doitsujin/dxvk/pull/4508 it writes 0 for disabled clip planes. But while working on this, I also discovered that other games also write constant clip/cull distances: Foz-DB Navi21: Totals from 442 (0.56% of 79206) affected shaders: MaxWaves: 10880 -> 10900 (+0.18%) Instrs: 283569 -> 282493 (-0.38%); split: -0.38%, +0.01% CodeSize: 1497596 -> 1491948 (-0.38%); split: -0.38%, +0.00% VGPRs: 18928 -> 18888 (-0.21%) Outputs: 3026 -> 2970 (-1.85%) Latency: 1051990 -> 1048878 (-0.30%); split: -0.47%, +0.18% InvThroughput: 184190 -> 183366 (-0.45%); split: -0.45%, +0.01% VClause: 6071 -> 6077 (+0.10%); split: -0.38%, +0.48% SClause: 6724 -> 6725 (+0.01%); split: -0.12%, +0.13% Copies: 19624 -> 19160 (-2.36%); split: -2.44%, +0.08% PreSGPRs: 18634 -> 18526 (-0.58%) PreVGPRs: 15522 -> 15465 (-0.37%) VALU: 156964 -> 156330 (-0.40%); split: -0.41%, +0.01% SALU: 41802 -> 41748 (-0.13%); split: -0.13%, +0.00% Reviewed-by:
-
these need to be kept in sync to avoid loader splat. Signed-off-by:
Alyssa Rosenzweig <alyssa@rosenzweig.io> Reviewed-by:
-
Cc: mesa-stable Closes: #12280 Signed-off-by:
Tapani Pälli <tapani.palli@intel.com> Reviewed-by:
Nanley Chery <nanley.g.chery@intel.com> Part-of: <!32555>
-
abort() for the gpu, implemented with the printf infrastructure since they go together. Signed-off-by:
Konstantin Seurer <konstantin.seurer@gmail.com> Reviewed-by:
Lionel Landwerlin <lionel.g.landwerlin@intel.com> Part-of: <!32564>
-
fixed address printf buffers can avoid a lot of complexity, especially with the general case of (e.g.) DGC-enqueued precompiled kernels. so add a knob for that and save the driver the need to write a lowering pass. Signed-off-by:
-
Signed-off-by:
-
negative offsets/sizes don't make sense, and zero-extension is often easier to optimize/lower than sign-extension. Signed-off-by:
-
this lets load_store_vectorize vectorize the stores we produce. it also matches actual OpenCL kernel code looks, so drivers need to have an optimized path for these 64+32 patterns regardless. Signed-off-by:
-
this can happen with shader aborts. don't blow up with theatrics. Signed-off-by:
-
drivers wishing to integrate driver CL printf/abort have to do some delicate dances to maintain the data structure with the buffer size and abort flag. wrap it all up in common helpers -- the driver just supplies the memory allocation and calls in periodically. Signed-off-by:
-
to integrate debug printf/abort, vulkan drivers need to implement a device status. we would need to thicken the runtime to do that entirely in common code, but we can at least add a helper to make it easier for vk drivers to wire. Signed-off-by:
-
these can happen depending on pass order, otherwise we crash on the null pointer. Signed-off-by:
-
Part-of: <!32564>
-
stsc was using don't care bits in a position position that is significant for stib.b. Signed-off-by:
Job Noorman <jnoorman@igalia.com> Fixes: 11b2c54a ("ir3/a7xx: Add STSC definition") Part-of: <!32575>
-
This will allow executor to show proper inline errors. Reviewed-by:
Ian Romanick <ian.d.romanick@intel.com> Part-of: <!32490>
-
Cc: mesa-stable Reviewed-by:
-
Foz-DB Navi21: Totals from 649 (0.82% of 79395) affected shaders: CodeSize: 2330592 -> 2314112 (-0.71%) Latency: 2068161 -> 2053370 (-0.72%) InvThroughput: 346583 -> 329425 (-4.95%) Reviewed-by:
-
Foz-DB Navi21: Totals from 89 (0.11% of 79395) affected shaders: Instrs: 97018 -> 96995 (-0.02%) CodeSize: 492996 -> 492488 (-0.10%) Latency: 504649 -> 504555 (-0.02%) InvThroughput: 121968 -> 121875 (-0.08%) VALU: 67427 -> 67404 (-0.03%) Reviewed-by:
-
Closes: #12150 Fixes: 2548471c ("vl/vl_win32_screen_create_from_d3d12_device: Allow winsys to be injected") Reviewed-by:
Jesse Natalie <jenatali@microsoft.com> Part-of: <!32559>
-
Simon Ser authored
llvmpipe_resource_map() may fail, e.g. when the DMA-BUF cannot be mmap'ed. Handle the error, either by returning NULL or by asserting. Asserting is done in places where there is no good way to bubble up the error (and is done in other places already, e.g. in init_scene_texture). Signed-off-by:
Simon Ser <contact@emersion.fr> Part-of: <!32537>
-
Right now the driver doesn't support multi-slice encodes, so report the correct value. Acked-by:
Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl> Acked-by: Autumn Ashton Cc: mesa-stable Part-of: <!32580>
-
Signed-off-by:
David Heidelberg <david@ixit.cz>
Part-of: <!32541> -
Signed-off-by:
David Heidelberg <david@ixit.cz>
Part-of: <!32541> -
Signed-off-by:
Martin Roukala (né Peres) <martin.roukala@mupuf.org> Part-of: <!32541>
-
Signed-off-by:
-
Signed-off-by:
-
This fixes spurious fails due to exceeding the timeout seconds ahead of finishing the job :s Signed-off-by:
-
This will hopefully allow the whole test suite to run. Signed-off-by:
-
Signed-off-by:
Mary Guillemard <mary.guillemard@collabora.com> Part-of: <!32541>
-
Signed-off-by:
-
Signed-off-by:
-
Signed-off-by:
-
Signed-off-by:
-
Signed-off-by:
-
It's just completely broken if alpha-to-coverage is also used. Given this is a requirement for Zink and no known GL apps are affected, let's disable for everything except Zink. This is going to be fixed but the fixes aren't small enough for backporting. This fixes a rendering issue with XPlane 12. Cc: mesa-stable Signed-off-by:
-
When alpha-to-coverage and alpha-to-one are both enabled in the fragment shader, the alpha value should be exported through MRTZ and one to MRT0.a. Otherwise, alpha-to-one will be performed before alpha-to-coverage. Signed-off-by:
-
For FS epilogs. Signed-off-by:
-
On AMD hardware, it's possible to export a separate alpha channel for applying alpha-to-one after alpha-to-coverage and not before. On GFX11+, it's already mostly supported but alpha needs to be exported to MRTZ.a and one to MRT0.a. The hw always uses alpha for alpha-to-coverage from MRTZ.a. On older generations, the driver needs the same separate alpha export but it also needs to configure the hardware with COVERAGE_TO_MASK_ENABLE which selects alpha from MRTZ.a. This should fix alpha-to-coverage with alpha-to-one when either depth, stencil or samplemask are exported but it still needs a slightly different solution without MRTZ. I will fix that later. Signed-off-by:
-
Comming timing is meaningless when we cannot receive timing feedback. Signed-off-by:
Hans-Kristian Arntzen <post@arntzen-software.no> Fixes: c26ab1ae ("vulkan/wsi/wayland: Pace frames with commit-timing-v1") Reviewed-by:
Autumn Ashton <misyl@froggi.es> Reviewed-by:
Derek Foreman <derek.foreman@collabora.com> Part-of: <!32556>
-
When commit-timing was not supported, but FIFO was we would end up in a situation with throttling on FIFO barrier and legacy fence. At that point, the entire point of FIFO falls flat. There are some caveats with this approach, but it's not expected that compositors will only support FIFO, and not commit-timing long term. Signed-off-by:
-
When transitioning from FIFO to MAILBOX with swapchain_maintenance1, we must make sure that the first MAILBOX after FIFO observes the wait barrier. This was done implicitly in the timestamp path, but not for the non-commit-timing path. Signed-off-by:
-
We use chain->base.present_mode instead. Signed-off-by:
-
When a timestamped present is not used (MAILBOX or the very first present), it's possible that the very last queued present ID won't complete in finite time. Similar to frame callback based workaround, apply a timeout to present waits when they target the very last submitted presentID. Only apply the workaround when we're not guaranteed forward progress. Signed-off-by:
-
Reviewed-by:
-
ttmp sgprs are readonly outside of trap handlers, so the instructions were probably skipped. RA should also never create additional exec writes. Fixes: e0677328 ("aco/ra: Optimize some SOP2 instructions with literal to SOPK.") Reviewed-by:
-
Fixes: 2d6b0a41 ("aco/optimizer: Optimize SOPC with literal to SOPK.") Reviewed-by:
-
Fixes: 4bd229ac ("aco/gfx11.5: select SOP2 float instructions") Reviewed-by:
-
This just works on Mali, nothing fancy needed. Unfortunately, this triggers a lot of timeouts, presumably due to uncached CPU access to memory. So lots of extra skips here. Reviewed-by:
Boris Brezillon <boris.brezillon@collabora.com> Part-of: <!32562>
-
This can't be moved to after demote, so it's not reorderable. Signed-off-by:
Georg Lehmann <dadschoorse@gmail.com> Part-of: <!32512>
-
This missed dpp16_shift_amd, lane_permute_16_amd, last_invocation and ballot_relaxed. Instead, list the non-reorderable intrinsics which are allowed to be moved after discards. Signed-off-by:
-
These can be lowered to ALU and load_subgroup_invocation, all of which are reorderable. Signed-off-by:
-
This is the format that drivers will want to use for NV16 without YUV conversion (if they support this natively). Previously we had NV16 working but it was always emulated with R8 + GR88. Fixes: 440b6921 ("dri, mesa: fix NV16 texture format") Reviewed-by:
Erik Faye-Lund <erik.faye-lund@collabora.com> Part-of: <!32524>
-
The override used for the immed encoding in #cat3-src-const-or-immed used a pattern which isn't supported in overrides by isaspec. The pattern in the base bitset (10) was too strict for immediates since it didn't allow the most significant bit to be 1. Fix this by making the base pattern 1 and adding an assert for the next bit to be 0 in the non-immed case. Signed-off-by:
-
FULL should be true here. Also tested in computerator and the comment about uncertainty can be removed. Signed-off-by:
-
It only supports (neg) in its 2nd src but other than that has the same properties as mad. Signed-off-by:
-
Turns out that sad is just iadd3. I assume it's an acronym for "Sum of Absolute Differences" which may make sense since its 2nd src supports (neg) which would allow SAD to be implemented using this instruction. NIR already supports algebraic patterns for selecting iadd3 so adding codegen support in ir3 is trivial. However, sad seems to have the same hardware limitation as mad and doesn't support the scalar ALU so we have to make sure to disable it when emitting iadd3. Signed-off-by:
-
We would mark mad srcs as swapped once we tried swapping them, even if it would not succeed. However, it might happen (especially after running ir3_shared_folding) that a new opportunity for swapping comes up later. Therefore, we should only mark the srcs as swapped when it actually succeeded. Signed-off-by:
-
In preparation for supporting sad (which like mad may benefit from swapping some of it srcs), extract the swapping from try_swap_mad_two_srcs so that it can be reused for sad. This is necessary since, unlike mad, sad might also benefit from swapping srcs 1->2 (instead of only 2->1) or 3->2. Signed-off-by:
-
In preparation for supporting sad, rename to try_swap_cat3_two_srcs and add argument for src n. Signed-off-by:
-
Like mad, it's sometimes useful to swap the srcs of sad since not all flags are allowed on all srcs. However, unlike mad, sad is 3-src commutative so more srcs can be swapped. Signed-off-by:
-
Turn on `imageCubeArray` and `fragmentStoresAndAtomics`, which we already support (the latter only on v10 and later). Reviewed-by:
-
We were using the same routine to find the device and instance version numbers. This isn't correct; the device version may vary based on the physical hardware we are using, but the instance version should always be the same. Reviewed-by:
-
We know we have a broken Vulkan driver, so it's debatable whether it's a broken Vulkan 1.0 or broken 1.1. Advertising 1.1 lets us run more tests, and this patch does this. We also bump the instance version id to 1.4, which seems appropriate since the overall Vulkan infrastructure within Mesa is at that level. Reviewed-by:
-
This updates entry for 14017823839 which fixes issues on BMG with: dEQP-VK.compute.pipeline.zero_initialize_workgroup_memory.max_workgroup_memory.1 Signed-off-by:
-
This is the default but the option wasn't completely removed. Signed-off-by:
-
While the nr_channels is defined with 3 bits, which allows up to 7 channels, actually the number of channels is less or equal to 4. This adds an assertion that helps static analyzers to avoid several false positives related with this. Reviewed-by:
Juan A. Suarez Romero <jasuarez@igalia.com> Part-of: <!32589>
-
This enables support for GFX version 11.5.3. Signed-off-by:
Tim Huang <tim.huang@amd.com> Reviewed-by:
-
Acked-by:
Matt Turner <mattst88@gmail.com> Part-of: <!32534>
-
Acked-by:
Daniel Stone <daniels@collabora.com> Part-of: <!32591>
-
Acked-by:
-
On a single runner, this job currently times out due to taking over 5 hours. The estimate from dEQP runner itself suggests a full run might take over 8 hours with the current configuration. We can't really work with that long runs, even if they are manual. We currently have 7 vim3 runners, so we can actually afford to parallelize the run a bit, to make this a bit more manageable. If we choose 4, we take up a bit more than half of the runners, but we leave two runners (plus a spare) for the pre-merge CI. With this, a each job takes about 2.5 hours. We leave the timeout at 3 hours for now, to have some headroom for new tests being enabled. Acked-by:
-
Showing
- docs/features.txt 1 addition, 1 deletiondocs/features.txt
- src/amd/addrlib/src/amdgpu_asic_addr.h 2 additions, 0 deletionssrc/amd/addrlib/src/amdgpu_asic_addr.h
- src/amd/ci/radv-tahiti-aco-flakes.txt 5 additions, 0 deletionssrc/amd/ci/radv-tahiti-aco-flakes.txt
- src/amd/ci/radv-vangogh-aco-flakes.txt 2 additions, 0 deletionssrc/amd/ci/radv-vangogh-aco-flakes.txt
- src/amd/common/ac_gpu_info.c 1 addition, 0 deletionssrc/amd/common/ac_gpu_info.c
- src/amd/common/ac_nir_lower_ps.c 8 additions, 4 deletionssrc/amd/common/ac_nir_lower_ps.c
- src/amd/common/amd_family.c 3 additions, 0 deletionssrc/amd/common/amd_family.c
- src/amd/common/amd_family.h 1 addition, 0 deletionssrc/amd/common/amd_family.h
- src/amd/compiler/aco_assembler.cpp 1 addition, 1 deletionsrc/amd/compiler/aco_assembler.cpp
- src/amd/compiler/aco_insert_waitcnt.cpp 2 additions, 2 deletionssrc/amd/compiler/aco_insert_waitcnt.cpp
- src/amd/compiler/aco_instruction_selection.cpp 24 additions, 12 deletionssrc/amd/compiler/aco_instruction_selection.cpp
- src/amd/compiler/aco_register_allocation.cpp 21 additions, 1 deletionsrc/amd/compiler/aco_register_allocation.cpp
- src/amd/vulkan/meta/radv_meta.c 9 additions, 0 deletionssrc/amd/vulkan/meta/radv_meta.c
- src/amd/vulkan/radv_acceleration_structure.c 0 additions, 6 deletionssrc/amd/vulkan/radv_acceleration_structure.c
- src/amd/vulkan/radv_cmd_buffer.c 11 additions, 4 deletionssrc/amd/vulkan/radv_cmd_buffer.c
- src/amd/vulkan/radv_debug.h 38 additions, 39 deletionssrc/amd/vulkan/radv_debug.h
- src/amd/vulkan/radv_physical_device.c 7 additions, 3 deletionssrc/amd/vulkan/radv_physical_device.c
- src/amd/vulkan/radv_physical_device.h 0 additions, 1 deletionsrc/amd/vulkan/radv_physical_device.h
- src/amd/vulkan/radv_pipeline_graphics.c 38 additions, 12 deletionssrc/amd/vulkan/radv_pipeline_graphics.c
- src/amd/vulkan/radv_shader_info.c 15 additions, 15 deletionssrc/amd/vulkan/radv_shader_info.c