* immediately terminate renderpass after flushing
this otherwise could persist and trigger a bad state where the
zsbuf is eliminated
* no-op if already in renderpass
this function can be called from within a renderpass, at which time
it should do nothing because clears will be flushed automatically
Fixes: 5de34e47ad6 ("zink: unify/fix clear flushing")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37052>
Wine uses vkGetRandROutputDisplayEXT to query some GPU details on start
of a prefix that have to be exposed on the PE side.
Currently this causes minimum of 2 connector reprobes via
DRM_IOCTL_MODE_GETCONNECTOR. This can stall vblanks when timed just
right. In cases where prefixes are started over and over again (e.g.
Steam doing background processing) this causes periodic noticable
stutter.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37026>
Remove the cfg variables and use the shader pointers directly. Reset
the variant pointer if a shader failed or will not be used.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33541>
The brw_shader::uniforms now is derived from the nir_shader. The
only exception is compute shaders for older Gfx versions, so we
move the adjust logic for that.
The benefit here is untangling the code for compilation variants,
that before needed to keep track of the first that compiled to,
in most cases, copy an integer.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33541>
As we set prog_data->nr_params, allocate the array like elsewhere.
Current code is getting by because the logic for adding a new element
will realloc it. But later changes will make the array be accessed
before this reallocation.
This will make sure later patches won't cause tests like
dEQP-VK.query_pool.statistics_query.compute_shader_invocations.32bits_cmdcopyquerypoolresults_secondary
to fail in gfxver < 125. Note the bug appears when DRI option
to tweak the thresold to use these shaders is set to 0. This is
done by the GitLab CI, which allowed testing later patches to find
this issue.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33541>
And unify the initialization code for brw_shader. Avoid passing
brw_compile_params since for a single compilation we might have
multiple shaders (the case for BS stage).
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33541>
The problem with the current code is that there is a disconnect between :
- the virtual register size allocated
- the dispatch size
- the size_written value
Only the last 2 are in sync and this confuses the spiller that only
looks at the destination register allocation & dispatch size to figure
out how much to spill.
The solution in this change is to make BROADCAST more like
MOV_INDIRECT, so that you can do a BROADCAST(8) that actually reads a
SIMD32 register. We put the size of the register read into src2.
Now the spiller sees correct read/write sizes just looking at the
destination register & dispatch size.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Fixes: 662339a2ff ("brw/build: Use SIMD8 temporaries in emit_uniformize")
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/13614
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36564>
vk dispatch in mesa provides the redirection for this. Also, other
recent changes have increment the minimium host requirement for
gfxstream-vk to VK_VERSION_1_1, anyways.
Reviewed-by: Gurchetan Singh <gurchetansingh@google.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36942>
Instead of causing a +7000000% estimated cycles across a fossil-db run,
this reduses that increase down to roughly +730%.
With this a 6 level deep loop get's an estimated block weight of 385.
The worst impacted shader gets its static cycle count increased by 240x,
whish is 6 level deep and a huge loop body.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36528>
Advertise format support for 8 samples.
Extend tri rasteriser to operate on fb_max_samples samples, rather than hardcoded 4.
Since we have run out of space for input mask in fragment shaders, add a second 64-bit input mask to handle samples 4 to 7.
Add sample positions for 8xMSAA.
Reviewed-by: Brian Paul brian.paul@broadcom.com
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37001>
Instead of allocating constants to the FAU entries on a
first-come-first-serve basis, it would be more efficient to put the most
frequently used constants in the FAU so we save the most amount of ADD_IMM
to push constants into registers.
This commit does so using a simple pass before the main constant lowering
pass.
Reviewed-by: Mary Guillemard <mary.guillemard@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36872>
Following on the previous commit, this commit adds support for selecting
and reporting constants to pull from the FAU instead of loading them
into registers first with ADD_IMM. This is beneficial because we can then
use them as a source directly and save ourselves one instruction to move
them into the register first.
Reviewed-by: Mary Guillemard <mary.guillemard@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36872>
This commit sets up support for constants that should be pushed into
FAU entries after the ones we already push (sysvals, push constants).
The next commit will make the compiler actually find and report the
constants that should be pushed.
Reviewed-by: Mary Guillemard <mary.guillemard@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36872>
