We tracked this down with the HW teams back in 2020 and there's now a
documented workaround. Comments from the HW team say this applies all
the way through XeHP but we're not sure beyond that.
This is a bug that we hit but the Windows drivers didn't because Jason
decided to allocate our memory structures from the top end of the VMA
range explicitly to catch bugs like this, while Windows allocates from
zero and up, so they would need to allocate more than 2GB of dynamic
state before running into it.
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/4880
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17216>
This lets us avoid the code duplication between BeginRendering and
BeginCommandBuffer and also lets us stop crawling core render pass
structs directly and instead focus on dynamic rendering concepts.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16953>
Instead of making drivers dive into the render pass and framebuffer
themselves, provide a helper that constructs a VkRenderingInfo for a
render pass resume that they can use instead. This should reduce code
duplication between driver implementations of BeginRendering and
BeginCommandBuffer.
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16953>
get_dword_size() is misleading, its name implies it's returning
a size in dwords, but it's actually returning a size in bytes.
This led to a wrong size passed to emit_cbv(). Instead of fixing
get_dword_size(), let's inline the code in emit_ubo_var().
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17230>
The original offset value is overwritten in our first for(i: num_states)
iteration, messing up the compute push constant update if stageFlags
applies to both compute and graphics.
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17233>
If we don't reset ctx.vm_cnt/gpr_map/etc, this will spam a lot of
s_waitcnt instructions.
Signed-off-by: Rhys Perry <pendingchaos02@gmail.com>
Reviewed-by: Timur Kristóf <timur.kristof@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17207>
This commit changes to the physical device limits which were
missed during the 1.17 transition.
Signed-off-by: Karmjit Mahil <Karmjit.Mahil@imgtec.com>
Reviewed-by: Rajnesh Kanwal <rajnesh.kanwal@imgtec.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17206>
This should allow the compiler to optimize this out because it knows that
cmd_buffer is NULL.
Signed-off-by: Georg Lehmann <dadschoorse@gmail.com>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17166>
this should be simpler to read through and maintain while providing
the same results as well as some possible perf and compile time improvements
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17192>
update_barriers has steadily grown more and more complex when the original
idea was for it to be a small function to handle deferred jit barriers and
simplify sync in patterns like bind_ubo -> draw -> buffer_subdata -> draw
instead, track the pending barrier info at bind time so that the stages and
access are already updated by the time draw/compute are reached
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17192>
this avoids the scenario where the full bo size isn't accounted for because
no variable for the block has been created
cc: mesa-stable
affects:
KHR-GL33.shaders.uniform_block.random.all_per_block_buffers.3
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17217>
GL_MAP_UNSYNCHRONIZED_BIT depends on the app having its threading
handled correctly. This allows us to force disable the bit when
they get it wrong.
CC: 22.1 22.0 <mesa-stable>
Acked-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17199>
these values should have all been set during pipeline compositing above,
so reapplying the values is at best, redundant, and at worst, broken
cc: mesa-stable
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17219>
only the viewMask parameter of VkPipelineRenderingCreateInfoKHR can
be accessed in the fragment stage, so for pipeline libraries it should
be assumed that zs attachments exist for the purpose of copying dynamic
state values, and then these dynamic states will naturally be pruned
during final pipeline construction if the attachments turn out to not
be present
cc: mesa-stable
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17219>
[Alyssa: Add a default CPU implementation of pipe->clear_buffer(). This hook is
mandatory for OpenCL support. Even though this implementation isn't optimal by
any means, having a conformant default available in core will lower the barrier
of entry to OpenCL support.]
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Alyssa Rosenzweig <alyssa@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16044>
It is now unused. We cannot yet remove the streamout functionality in u_blitter
as r600g still uses it for clear_buffer on GPUs older than Evergreen.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Acked-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17142>
r600g is the only user of util_blitter_copy_buffer in tree, which implements
buffer copies with streamout. This path for r600g was added in 8ac9801669
("r600g: accelerate buffer copying"), a commit from 2012. At that point there
was no DMA path for buffer copies. Since then, a DMA path has been added,
conditional only on the kernel version -- not the hardware. It appears the
required kernel support has been mainline for at least 4 years now. Mesa 22.2
doesn't need to provide optimal performance on an old kernel -- for performance,
a DMA-capable kernel should be used, and for compatability, the CPU fallback
(used for unaligned buffers as it is) is still available. Remove the streamout
path "in the middle" that appears ~unused today.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Acked-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17142>
Kenneth Graunke
Ryan Neph
Jason Ekstrand
Mike Blumenkrantz
Jason Ekstrand
Jason Ekstrand
Boris Brezillon
Danylo Piliaiev
Rhys Perry
Sviatoslav Peleshko
Karmjit Mahil
Lionel Landwerlin
Georg Lehmann
Andres Gomez
Timothy Arceri
Alyssa Rosenzweig