Otherwise this leads to a use-after-free
dEQP-VK.synchronization.op.single_queue.fence.write_fill_buffer_read_ssbo_vertex.buffer_16384
when run after any test using a ubo in the fragment shader.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8912>
item->base will be freed for the NULL reference write
so just use a temporary to avoid it.
This was found with asan and lavapipe:
dEQP-VK.api.copy_and_blit.core.blit_image*
Reviewed-by: Adam Jackson <ajax@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8912>
The debug resource tracking triggers an asan warning, add a mutex
around it to avoid multi-thread failures with vulkan CTS test:
dEQP-VK.api.object_management.multithreaded_per_thread_device.buffer_uniform_small
Reviewed-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8912>
Starting with GL 3.0 it's legal to have no drawable bound to the current
context. GLX_SGI_video_sync doesn't take a drawable for an argument so
it implicitly operates on... something. NVIDIA's driver throws
GLX_BAD_CONTEXT for GetVideoSync, but WaitVideoSync seems to actually
wait for the next MSC on the context's screen. We could work around this
by internally creating/destroying a GLXWindow for the root window, but
for Xwayland there's not necessarily a good answer it can return.
Just throw GLX_BAD_CONTEXT for both.
Fixes: mesa/mesa#1207
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8334>
Instead of calling iris_sample_with_depth_aux right before a sample
operation, call it at resource creation time. Unifies the code which
ensures that it's okay to sample with HiZ.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8853>
Instead of storing a bitfield of which resource levels will be accessed
with HiZ, compute this information on-demand. Makes the iris_resource
struct more generic.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8853>
Before this commit, various functions avoided calling
iris_resource_get_aux_state and iris_resource_set_aux_state for depth
buffers which lacked full HiZ support at certain levels. This was
because:
1. Some callers of prepare/finish neglected to use ISL_AUX_USAGE_NONE
for the levels which lacked full HiZ support.
2. The assertions within the getter and setter were too strict.
Now that both of these issues have been resolved, there's no obvious
reason to try to avoid these function calls. Delete the code for
avoiding them.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8853>
The aux state getter and setter currently assert
iris_resource_level_has_hiz() for depth surfaces.
This assertion is too strict however. In some cases where the assert
would fail, we can still correctly describe the aux state with the ISL
enums (using ISL_AUX_STATE_AUX_INVALID, for example).
When HiZ is enabled on a resource but disabled for a given level, allow
the getter to be called and allow the setter to set aux states that lack
compression. Enables code simplifications later on.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8853>
Prepare/finish a framebuffer's depth buffer with the aux usage that's
appropriate for the given miplevel instead of wrongly assuming that
compression is always enabled. Enables code simplifications later on.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8853>
Set dst_aux_usage to ISL_AUX_USAGE_NONE for the depth buffer blit if the
level doesn't fully support HiZ. Enables removing the code that masked
this issue later on.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8853>
There's an iris_resource_level_has_hiz assert at the top of the
function. Also, aux surfaces are allocated in the same BO as main
surfaces.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8853>
One comment seems to suggest that MCS (which is needed for compressed
multisampling) can be used to sample from a multisampled depth buffer.
This is not the case. Multisampled depth buffers are sampled without an
auxiliary surface.
Another comment seems to suggest that some depth buffers don't have
corresponding levels in their HiZ buffers. Each main slice *should* have
a corresponding aux slice, but not all of these slices have equal
support for HiZ ops (e.g. ambiguates aren't really supported on
non-8x4-aligned slices).
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8853>
On BDW and SKL, assert that render target dimensions are 8x4-aligned
when performing HiZ ambiguates on LOD1+. Testing indicates that the
assertion should hold in order to achieve consistent/correct ambiguate
operations on gen9.
v2. Account for the relaxed restrictions on ICL+. (Ken)
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/3788
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8853>
The VkInstance is really display state not screen state, as is the
loader version. Factor this out a bit further so that
zink_create_instance fills in a zink_instance_info. The latter struct
still lives in the zink_screen for now but that'll move soon.
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8968>
this needs to be unconditionally supported in some way, and it also
needs to use a more compatible fallback format if the base format is unavailable
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8959>
The vulkan spec says the following about vkMapMemory:
"ppData is a pointer to a void * variable in which is returned a
host-accessible pointer to the beginning of the mapped range. This
pointer minus offset must be aligned to at least
VkPhysicalDeviceLimits::minMemoryMapAlignment."
So let's report the same value as the gallium-driver reports, otherwise
we'll fail to adhere to the alignment requirement.
This fixes a few Piglit failures for Zink.
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/4267
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8965>
These cannot schedule to the last tuple, there needs to be other work in
the last clause, or a tuple of NOP's failing that. Can occur depending
on scheduling of CUBEFACE instructions, and will apply to computational
atomics in the near future.
Fixes: 77933d16d8 ("pan/bi: Switch to new scheduler")
Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8962>
This incorrectly assumed the last tuple was nontrivial, an invariant
that holds by accident on the current scheduler but will break
momentarily. Fix this, and document the invariants.
Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8962>
In the next commit, we'll start building Zink in the meson-testing step,
and because mega-drivers end up stuffing all dependencies in the same
shared-object, we end up requiring libvulkan for other drivers as well.
So let's no longer track separately who needs vulkan and who doesn't,
and just always install it.
Reviewed-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8879>
ARB_enhanced_layouts allows specifying explicit locations for xfb buffers,
which means we get arrays of buffers with gaps in the middle sometimes and
have to throw in a null handle
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8943>
This warning is bothering a number of people and rightfully so.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8955>
The QPU scheduler allows to move certain TMU instructions around and
since we enabled pipelining, we need to protect against the case where
doing this might break a TMU sequence. For example, this test:
dEQP-VK.rasterization.line_continuity.line-strip
Was generating this VIR:
mov tmud, t187
mov.pushz null, t176
mov.ifa tmua, t9
nop null; wrtmuc (img[0].p0 | 0x0)
mov tmut, t185
mov tmud, t180
mov.ifa tmusf, t183
nop null; thrsw
where we have a general TMU access (tmud,tmua) followed by an image
access (wrtmuc, tmut, tmud, tmusf), which the QPU scheduler was turning
into:
nop ; nop ; ldunifrf.rf22 (0xffffff00 / -nan)
nop ; nop ; wrtmuc (img[0].p0 | 0x0)
nop ; nop ; ldtmu.r2
add r0, r2, 1 ; nop ; ldtmu.r3
nop ; nop ; ldtmu.r4
nop ; mov tmud, r0
nop ; mov.ifa tmua, rf15
nop ; mov tmut, r4 ; thrsw
nop ; mov tmud, rf22
nop ; mov.ifa tmusf, r3
where it allowed the wrtmuc to move up and before the general TMU access,
leading to an incorrect TMU sequence.
Fix this by flagging TMUA writes (which are the sequence terminators for
general TMU accessess) as writing new TMU configuration, like we do for all
other TMU sequence terminators for textures and images.
Fixes: 197090a3fc ('broadcom/compiler: implement pipelining for general TMU operations')
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8954>
this just flushes all the pending batches, which is enough since we
do our batch work synchronously and everything is awful
will be reworked when this is no longer the case
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8948>
viewport can be transformed at draw time based on clip_halfz, so we actually
want to do the conversion from gallium->vulkan at that time
as a nice bonus, we get to delete a struct member
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8946>
If the device isn't lost, the application might want to re-submit.
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/8931>
Fixes the documentation preview link on the MR Overview tab. Found by
comparing with the same thing in weston.
(It still appears only after all jobs in the pipeline have at least
started once though)
Fixes: ae8f9584f4 "CI: always expose docs artifacts"
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8927>
These offsets were wrong and didn't match the old behaviour.
Signed-off-by: Rhys Perry <pendingchaos02@gmail.com>
Reviewed-by: Daniel Schürmann <daniel@schuermann.dev>
Fixes: e8220e106b ("aco: optimize AC_FETCH_FORMAT_SNORM alpha adjust")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8935>
On GFX10+, the ESGS ring is allocated in LDS. This saves one BO
when geometry shaders are used, and possibly two BOs if nothing
else (tess, scratch, etc) is used.
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/8926>
Dave Airlie
Adam Jackson
Nanley Chery
Mike Blumenkrantz
Erik Faye-Lund
Michel Zou
Alyssa Rosenzweig
Pierre-Eric Pelloux-Prayer
Lionel Landwerlin
Iago Toral Quiroga
Danylo Piliaiev
Samuel Pitoiset
Michel Dänzer
Alejandro Piñeiro
Rhys Perry