can help a lot for scratchy shaders. affected shader is a compute shader in
graphics bench.
total instructions in shared programs: 2751334 -> 2750950 (-0.01%)
instructions in affected programs: 4308 -> 3924 (-8.91%)
helped: 2
HURT: 0
total bytes in shared programs: 21482512 -> 21480592 (<.01%)
bytes in affected programs: 27448 -> 25528 (-7.00%)
helped: 2
HURT: 0
total fills in shared programs: 732 -> 540 (-26.23%)
fills in affected programs: 396 -> 204 (-48.48%)
helped: 2
HURT: 0
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32320>
The new location is pci_ids/r600_pci_ids.h
Fixes: 1299f5c50a ("gallium/radeon: import libdrm_radeon source code, drop the dependency")
Signed-off-by: Mike Lothian <mike@fireburn.co.uk>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32298>
This is a small command line utility to generate NIR bindings for a SPIR-V
library, using vtn's infrastructure for this. This is split out from asahi_clc
in an effort to make clc more modular. Notably, this tool does not depend on:
* LLVM, SPIRV-LLVM, CLC, etc (important for Android, and gets us closer to the
clang spir-v future)
* Driver details other than addressing modes (which are already largely
hardcoded, setting them to anything else doesn't make a ton of sense for CL C)
* The driver itself, or its backend compiler. That means that the backend
compiler can depend on the generated bindings header, even if the compiler is
also used for internal shader precompiling. This breaks the dep loop.
So in short term, this solves the dependency problem for asahi, and in the long
term helps more drivers use clc infrastructure without re-rolling things
themselves.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Reviewed-by: Konstantin Seurer <konstantin.seurer@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32226>
See comment in the pass for motivation. To be used for asahi clc.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Reviewed-by: Konstantin Seurer <konstantin.seurer@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32226>
These fields are only valid in certain formats, so set them accordingly.
Note the check if !is_send is used because FORMAT_BASIC is reused for
SEND/SENDS in some platforms. If we start to see more cases like that,
we can create a new FORMAT for it.
The cond_modifier is trickier because on top of that, it is not valid
for 64-bit immediates in some platforms. Found when EU validation
complained about moving 64-bit immediates with higher bits.
Fixes: e4440df2d8 ("intel/brw: Add pred/cmod/sat to brw_hw_decoded_inst")
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32287>
According to HSD 1406738321, full resolves and fast-clears don't work
properly on 3D textures. Up until now, we've disabled CCS for this case.
Instead, redescribe the surface as 2-dimensional to perform auxiliary
surface operations.
Reviewed-by: Rohan Garg <rohan.garg@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31880>
Use vk_expand_src_stage_flags2 and vk_expand_dst_stage_flags2, instead
of vk_expand_pipeline_stage_flags2, to expand bottom-of-pipe and
top-of-pipe respectively.
Fixes: 5544d39f44 ("panvk: Add a CSF backend for panvk_queue/cmd_buffer")
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32289>
When we create a new swapchain to replace the one currently presenting on
a surface, we need to reset all these timing variables. Otherwise we can
lose track of corrections that were made for the old swapchain when we
delete undelivered presentation feedback results.
Also, we use these variables when queuing a presentation, but we also use
them in the dispatch code that can be called by WaitForPresent from another
thread. We need to protect these variables against concurrent usage.
This is all much easier to do when they're stored as part of the swapchain
instead of the surface, so just move them there and adjust the locking.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
Fixes: c26ab1aee1 ("vulkan/wsi/wayland: Pace frames with commit-timing-v1")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32121>
When we start using timestamps, the current code will generate an event
stream like:
feedback
set barrier
wait barrier
commit
feedback
set timestamp
set barrier
commit
wait barrier
commit
The second content update can cause the feedback request from the first to
send a discarded event if the timestamp is in the past.
Be less clever and just put waits in both our content updates.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
Fixes: c26ab1aee1 ("vulkan/wsi/wayland: Pace frames with commit-timing-v1")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32121>
When occluded, the current math always rounds down to 0 cycles and leads
to improperly throttled frame delivery.
Improve the comment, and use a formula that leads to generating future
times even when occluded.
Also remove some dead code, as we can never get here with a period of 0.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
Fixes: c26ab1aee1 ("vulkan/wsi/wayland: Pace frames with commit-timing-v1")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32121>
Update just enough of the fail list to have a green CI. I'm sure a
no-fraction run would uncover other improvements/failures/flakes, but
the goal here is to detect improvements/regressions introduced by new
MRs, not to make the list accurate. This will be tackled in a follow-up
MR.
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32302>
We assume everywhere that RGB is not planar, so sampling
and color space conversions will not work correctly with RGBP.
Drivers can still support RGBP, but processing entrypoint with
shaders doesn't support it.
Fixes: bdb7f36aa8 ("frontends/va: add support for RGBP rt_format")
Reviewed-by: Ruijing Dong <ruijing.dong@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32252>
This matches the supported formats we query for in config attributes.
Also prefer YUY2 over YUYV (identical formats), as YUY2 has a VA_FOURCC_YUY2
definition and some applications will only try to use this fourcc code.
Reviewed-by: Ruijing Dong <ruijing.dong@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32252>
I did half the job in that commit: I split the two apis into two
invocations, but I didn't fix the binary used for the gles one...
Fixes: 14279087fb ("ci/deqp-runner: split gl & gles groups to use the correct binary")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32250>
