oldNum was incorrect. oldValNum is the correct number of elements
to copy inside realloc. (oldNum is for Parameters, not ParameterValues)
Reviewed-by: Zoltán Böszörményi <zboszor@gmail.com>
Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9360>
The problem was that I assumed that deleted zombie buffers can't have any
references in the context, so buffers were released sooner than they should
have been.
The fix is to count the non-atomic references in the new field
gl_buffer_object::CtxRefCount. When we detach the context from the buffer,
we can just add CtxRefCount to RefCount to re-enable atomic reference
counting. This also allows removing code that was doing a similar thing.
Fixes: e014e3b6be "mesa: don't count buffer references for the context that created them"
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/4259
Reviewed-by: Zoltán Böszörményi <zboszor@gmail.com>
Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9360>
When the hw_binary is not put in the in-memory
cache it must be freed.
Fixes: 8283ed65cf ("radeonsi: Limit the size of the in-memory shader cache")
Signed-off-by: Axel Davy <davyaxel0@gmail.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9587>
The current check only accomodates for a list with a single INVALID
item. However the driver won't be able to pick any modifier if the
list only contains INVALID. This includes the following cases:
- The modifier list is empty (count == 0)
- The modifier list contains more than a single item, but all items
are INVALID
In these cases, also fail early.
Signed-off-by: Simon Ser <contact@emersion.fr>
References: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7601#note_778845
Reviewed-by: Daniel Stone <daniel@fooishbar.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8715>
There's a few changes in the expected results. First of all, there's a
few failures that are now interpreted as crashes. These test are:
- glx@glx-visuals-depth
- glx@glx-visuals-depth -pixmap
- glx@glx-visuals-stencil
- glx@glx-visuals-stencil -pixmap
Secondly, and more surprisingly, there's three tests that were
previously passing, but are now failing. These are all EGL-related, so
it's likely that there's some EGL interaction that is different with the
new runner. These tests are:
- spec@egl 1.4@eglterminate then unbind context
- spec@egl_khr_surfaceless_context@viewport
- spec@egl_mesa_configless_context@basic
commit log and skiplist by Erik Faye-Lund <erik.faye-lund@collabora.com>
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9630>
This makes UBO loads in the variable pointers or bindless case work just
like SSBO loads in the sense that they use A64 messages and 64-bit
global addresses. The primary difference is that we have an
optimization in anv_nir_lower_ubo_loads which uses a (possibly
predicated) block load message when the offset is constant so we get
roughly the same performance as we would from plumbing load_ubo all the
way to the back-end.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Caio Marcelo de Oliveira Filho <caio.oliveira@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8635>
Instead of load_global_constant_offset/bounded, we want to use the
Intel-specific block load intrinsic whenever we can. This way we get
the same wide block loads that we usually use for constant offset UBO
pulls with a binding table.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Caio Marcelo de Oliveira Filho <caio.oliveira@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8635>
For nir_address_format_64bit_global_32bit_offset and
nir_address_format_64bit_bounded_global, we use a new intrinsics which
take the base address and offset as separate parameters. For bounds-
checked access, the bound is also included in the intrinsic. This gives
the drive more control over the bounds checking so that UBOs don't
suddenly become massively more expensive.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Caio Marcelo de Oliveira Filho <caio.oliveira@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8635>
This also means that some of the newly added helpers need to grow a bit
to support VK_DESCRIPTOR_TYPE_INLINE_UNIFORM_DATA_EXT.
Reviewed-by: Caio Marcelo de Oliveira Filho <caio.oliveira@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8635>
This function has exactly two call sites. The first is where we had
these calculations before. The second only cares about the size of the
SSBO so all the extra code we emit will be dead. However, NIR should
easily clean that up and this lets us consolidate things a bit better.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Caio Marcelo de Oliveira Filho <caio.oliveira@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8635>
Instead of packing the descriptor offset into the packed portion, use
that unused channel we have lying around. This potentially allows for
larger descriptor sets. We also re-arrange the components a bit to make
it more like the 64bit_bounded_global memory address format.
Reviewed-by: Caio Marcelo de Oliveira Filho <caio.oliveira@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8635>
This has the advantage of giving us cheaper address calculations because
we can calculate in 32 bits first and then do a single 64x32 add. It
also lets us delete a bunch of code for dealing with descriptor
dereferences (vulkan_resource_reindex, and friends) because our bindless
SSBO pointers are now vec4s regardless of whether or not we're doing
bounds checking. This also unifies UBOs and SSBOs. The one down-side
is that, in certain variable pointers cases, it may end up burning more
memory and/or increasing register pressure. This seems like a worth-
while trade-off.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Caio Marcelo de Oliveira Filho <caio.oliveira@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8635>
This is a global address format where you have a 64-bit base pointer and
a 32-bit offset. It's intentionally identical to 64bit_bounded_global
except nir_lower_explicit_io does no bounds checking with it.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Caio Marcelo de Oliveira Filho <caio.oliveira@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8635>
Instead of doing the array check at the load_vulkan_resource_index
intrinsic, stuff it in the vec2 and handle it at load_vulkan_descriptor
time. This allows the bounds check to take any re-index intrinsics into
account. This only affects variablePointers + SSBOs + Gen7.
Reviewed-by: Caio Marcelo de Oliveira Filho <caio.oliveira@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8635>
We're about to enable bindless UBOs via A64 memory access like we do for
SSBOs. In order to prevent 100% of UBOs from hitting that path, we
enable them in the early lowering. This way we'll still get binding
table-based UBO access for any non-bindless ones. In particular, we
need this for UBO pushing to work.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Caio Marcelo de Oliveira Filho <caio.oliveira@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8635>
Rewrite them all to work on an index/offset vec2 instead of some only
returning the index. This means SSBO size handling is a tiny bit more
complicated but it will also mean we can use them for descriptor buffers
properly.
This also fixes a bug where we weren't bounds-checking re-index
intrinsics because we applied the bounds check at the tail of the
recursion and not at the beginning.
Fixes: 3cf78ec2bd "anv: Lower some SSBO operations in..."
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Caio Marcelo de Oliveira Filho <caio.oliveira@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8635>
This makes things a bit more generic for use in the next commit.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Caio Marcelo de Oliveira Filho <caio.oliveira@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8635>
NIR can do a bit better job optimizing this version.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Caio Marcelo de Oliveira Filho <caio.oliveira@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8635>
This allows us to do bounds checked A64 block load without the it being
counted as control-flow by NIR. This means that NIR optimizations like
CSE will be able to work on these the same as a regular load.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Caio Marcelo de Oliveira Filho <caio.oliveira@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8635>
Saw a flood of "waiting on invalid fence" with a completely bogus
looking fence # in a log of a rather strange low-memory crash. Not
sure if it is coming from memory corruption in userspace, but if a
submit ioctl is failing due to failed allocation (or other reason)
we would get left with random stack garbage as the fence #. Let's
not have that as a potential problem.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9638>
It ignored non-harvested chips with a non-power-of-two memory bus.
Fixes: abed921ce7 - amd: add support for Navy Flounder
Acked-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9568>
When we alloc with ralloc, we also need to free with it.
But let's take a step back here; we don't just need to use ralloc, we
also need to destroy all other screen-resources. So let's call the
destructor here instead.
Fixes: 2643f9ed28 ("zink: ralloc screen objects")
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9647>
