ralloc is not thread-safe, so we can't use dev->memctx for allocating
context-specific things without locking. On top of that, we always
need to explicitly clean up pools anyway since we need to unref the BOs,
so there is no point to using a memctx.
And since pools need to be explicitly cleaned up, the meta cache code
needs explicit cleanup, so add that and drop memctx from there too.
Signed-off-by: Asahi Lina <lina@asahilina.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21348>
We call agx_get_shader_variant through with casted inner shader key
types, so it has to make sure to only copy as much of the union as is
actually valid.
Signed-off-by: Asahi Lina <lina@asahilina.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21348>
We can just add the flags to the kopper interface, since it's private to
Mesa. This gets us depth/stencil invalidation on swapbuffers, which is
critical for tiler performance.
glmark2-es2 -b texture (windowed) goes from 1650 to 1930 fps on
zink+turnip with ZINK_DEBUG=rp.
Part of #7321 (we're still a little behind freedreno's 2180 fps)
Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21317>
Only code that cares about Vulkan WSI should get the corresponding
arguments passed. Otherwise, the Vulkan headers might end up including
other headers that we don't have the correct dependencies passed for.
So let's give those a dedicated variable, and only pass that where it's
actually needed.
Fixes: b39958a3a1 ("anv,nir: Move the ANV YCbCr lowering pass to common code")
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/8193
Reviewed-by: Yonggang Luo <luoyonggang@gmail.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21185>
VAEncCodedBufferType is used for reading back encoded data.
Mapping it for read instead of write speeds up reading
the data on CPU.
On radeonsi this will result in VRAM copy to staging buffer
in cached GTT, making the CPU read much faster.
Signed-off-by: David Rosca <nowrep@gmail.com>
Reviewed-by: Ruijing Dong <ruijing.dong@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20376>
llvm::None was deprecated and builds started failing with
error: ‘None’ is not a member of ‘llvm’
Instead of using the temporarily available include in ADT which would
add a deprecation warning to the build, directly replace llvm::None with
the recommended std::nullopt
This change takes only effect with LLVM 17 or newer.
Reference: d4f38ef288/llvm/include/llvm/ADT/None.h
Reviewed-by: Karol Herbst <kherbst@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21125>
Before dropping this function, handle the two callers of this function:
* The call in iris_blorp.c is redundant. The required cache flushes are
already handled by the callers of blorp functions. Delete this.
* The call in iris_resolve.c is still providing a benefit because it
calls iris_emit_buffer_barrier_for internally. Inline the needed
barrier.
Cc: 23.0 <mesa-stable>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21303>
Memory accesses can get corrupted when there's a disagreement between:
* the aux-mode of existing cache lines for a surface and
* the aux-usage in that surface's RENDER_SURFACE_STATE object
We have already prevented hardware from seeing this conflict for
rendering operations, but due to how the L3 is shared among multiple
clients in gfx12 (e.g., sampler engine, render engine, etc.), we need to
expand the scope of the existing solution. Now, before any access of a
compressible resource, we make sure to flush the prior aux-mode from the
caches.
The majority of changes here refactor things for use in a new function,
flush_previous_aux_mode. The remaining change calls that function from
within iris_resource_prepare_access.
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/6558
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/7625
Cc: 23.0 <mesa-stable>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21303>
"Use 3DSTATE_CONST command for individual shaders instead of
3DSTATE_CONST_ALL COMMAND"
On gen 12.0 platforms, 3DSTATE_CONSTANT_ALL command is not processed
correctly in certain cases.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21301>
This reverts commit 2dfebf3487.
It causes GPU hangs in piglit tests like
spec@glsl-1.20@execution@clipping@vs-clip-vertex-enables, for reasons I'm
totally unclear on. The commit was not necessary, because the frontend
lowering already handles disabled clip planes by storing 0.0 to the
corresponding clipdist array element in that shader variant. Add a note
to that effect.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21298>
The shader key structure is quite large and memsetting it to zero to be
able to create or often simply find an existing shader is responsible
for a large portion of CPU usage during benchmarks.
This change is more surgical about what, when, and how things get
cleared.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21247>
Passes the ext_external_objects-memory-object-api-errors piglit:
./bin/ext_external_objects-memory-object-api-errors
Mesa: User error: GL_INVALID_VALUE in glTexStorageMem1DEXT(memory=0)
PIGLIT: {"subtest": {"1D texture" : "pass"}}
Mesa: User error: GL_INVALID_VALUE in glTexStorageMem2DEXT(memory=0)
PIGLIT: {"subtest": {"2D texture" : "pass"}}
Mesa: User error: GL_INVALID_VALUE in glTexStorageMem3DEXT(memory=0)
PIGLIT: {"subtest": {"3D texture" : "pass"}}
Mesa: User error: GL_INVALID_VALUE in glTextureStorageMem1DEXT(memory=0)
PIGLIT: {"subtest": {"1D texture direct state access" : "pass"}}
Mesa: User error: GL_INVALID_VALUE in glTexureStorageMem2DEXT(memory=0)
PIGLIT: {"subtest": {"2D texture direct state access" : "pass"}}
Mesa: User error: GL_INVALID_VALUE in glTextureStorageMem3DEXT(memory=0)
PIGLIT: {"subtest": {"3D texture direct state access" : "pass"}}
Mesa: User error: GL_INVALID_VALUE in glTexStorageMem2DMultisampleEXT(memory=0)
PIGLIT: {"subtest": {"2D texture ms" : "pass"}}
Mesa: User error: GL_INVALID_VALUE in glTexStorageMem3DMultisampleEXT(memory=0)
PIGLIT: {"subtest": {"3D texture ms" : "pass"}}
Mesa: User error: GL_INVALID_VALUE in glTextureStorageMem2DMultisampleEXT(memory=0)
PIGLIT: {"subtest": {"2D texture ms direct state access" : "pass"}}
Mesa: User error: GL_INVALID_VALUE in glTextureStorageMem3DMultisampleEXT(memory=0)
PIGLIT: {"subtest": {"3D texture ms direct state access" : "pass"}}
Mesa: User error: GL_INVALID_VALUE in glBufferStorageMemEXT(memory == 0)
PIGLIT: {"subtest": {"buffer storage" : "pass"}}
Mesa: User error: GL_INVALID_VALUE in glNamedBufferStorageMemEXT(memory == 0)
PIGLIT: {"subtest": {"buffer storage direct state access" : "pass"}}
Mesa: User error: GL_INVALID_ENUM in glGetUnsignedBytevEXT(pname=0xffffffff)
PIGLIT: {"subtest": {"unsigned-byte-v-bad-enum" : "pass"}}
Mesa: User error: GL_INVALID_ENUM in glGetUnsignedBytei_vEXT(pname=0xffffffff)
PIGLIT: {"subtest": {"unsigned-byte-i-v-bad-enum" : "pass"}}
Mesa: User error: GL_INVALID_VALUE in glGetUnsignedBytei_vEXT(pname=GL_DEVICE_UUID_EXT)
PIGLIT: {"subtest": {"unsigned-byte-i-v-bad-value" : "pass"}}
Signed-off-by: Yusuf Khan <yusisamerican@gmail.com>
Reviewed-by: Karol Herbst <kherbst@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19405>
If there is any draw, we should submit in case there are active queries,
fragment shader side effects, etc. Together with previous commit fixes
no_attachment framebuffers.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21267>
previously descriptor buffers were sized to allow for 25,000 descriptors
this is a great number.
but in some scenarios it's overkill, and it's theoretically possible that
it might be underkill in others (citation needed), so add some handling
for both cases to save small amounts of vram on average and not crash
in the distant future when hypercomputers try running drawoverhead
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21246>
