This change forces image->buffer->image copy path for pretty much
all the cases now.
Metal's image to image copy only allows same format and sample
count. Previously we were only taking the image->buffer->image
path for compressed formats. This just seemed to work, but we may
run into issues in the future. Metal does not report any
validation layer error.
Acked-by: Arcady Goldmints-Orlov <arcady@lunarg.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38459>
This fixes an issue a bunch of different components were all working
around themselves where sometimes we don't have a workgroup size but
workgroup_size_variable is false. This also fixes asahi_clc, which
didn't have the workaround and was assuming zero (but not variable!)
workgroup sizes everywhere.
LoLed-by: Alyssa Rosenzweig <alyssa.rosenzweig@intel.com>
Acked-by: Mel Henning <mhenning@darkrefraction.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38538>
vkQueueBeginDebugUtilsLabelEXT and vkQueueEndDebugUtilsLabelEXT
require queue to be externally synchronized, which means these functions
require the lock. Unfortunately, there's no guarantee that the debug
markers will be matched in the multithreaded case, but I suppose this is
better than crashing.
Fixes: 015eda4a41 ("zink: deduplicate VkDevice and VkInstance")
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38414>
We currently only create one queue per queue family on the device. The
device can be shared between multiple zink_screens, so having one lock
per screen can still lead to multiple locks per queue. Fix this by
allocating queue_lock along with the device.
This fixes an issue that was causing crashes with nvk+zink and
QtWebEngine with QTWEBENGINE_FORCE_USE_GBM=1 This can be reproduced by
resizing the window in either:
* anki - https://apps.ankiweb.net/ or
* Qt's simplebrowser example
https://doc.qt.io/qt-6/qtwebengine-webenginewidgets-simplebrowser-example.html
which would then cause this dmesg error:
nouveau 0000:01:00.0: anki[92007]: Failed to find syncobj (-> in): handle=40
along with a context loss.
With VK_LOADER_LAYERS_ENABLE=VK_LAYER_KHRONOS_validation we would additionally
get warnings like:
Validation Error: [ UNASSIGNED-Threading-MultipleThreads-Write ] | MessageID = 0xa05b236e
vkQueueSubmit(): THREADING ERROR : object of type VkQueue is simultaneously used in current thread 139824449189568 and thread 139823901816512
Objects: 1
[0] VkQueue 0x557a666783e0
Fixes: 015eda4a41 ("zink: deduplicate VkDevice and VkInstance")
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38414>
For geometry shaders, we're going to need to compile various graphics
shaders down to compute shaders. This means that they'll look like
compute shaders to much of the compile pipeline but ultimately get
executed as graphics shaders. Most of the time, the compiler will just
happily take whatever offset you give and try to load the sysval from
there so you can load a graphics sysval from a compute shader just fine.
However, for the common ones, we switch on the shader stage and load
from a different offset for 3D vs. compute. This breaks the moment you
have a compute shader that's going to actually load from a 3D sysval
space.
The solution here is to ensure that any common sysvals (currently just
the push uniforms address and the printf buffer) are at exactly the same
offset in both. This is done by adding a panvk_common_sysvals struct,
some static asserts, and a bit of macro magic to keep things eurgonamic.
This also changes push uniform upload to just swap in the push uniform
address instead of writing it to the command buffer on every iteration.
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38508>
Our backend compiler explains the limits as :
32 bytes for the patch header (tessellation factors)
480 bytes for per-patch varyings (a varying component is 4 bytes and
gl_MaxTessPatchComponents = 120)
16384 bytes for per-vertex varyings (a varying component is 4 bytes,
gl_MaxPatchVertices = 32 and
gl_MaxTessControlOutputComponents = 128)
In all that's :
* 32 patches * 128 components (counting tessellation factors)
* 32 vertices * 128 components
8192 total components.
I'm not sure why the limit was set so low, maybe leftover from older platforms?
Bump the limit to something like competition.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38523>
We were overflowing an array during bifrost disassembly. This was
only a problem if the user explicitly set an environment variable,
so unlikely to occur in casual use, and also only could be triggered
in very specific, dense code. But we still should get this right!
The specific CTS test that caused the assert is:
'dEQP-VK.graphicsfuzz.stable-quicksort-for-loop-with-injection'
with environment variable `BIFROST_MESA_DEBUG=shaders`. One of the
shaders has a clause with 6 constants (the maximum) and this overflowed
the array because we assume we always have an extra slot (used for
modifier processing).
Cc: mesa-stable
Reviewed-by: Christoph Pillmayer <christoph.pillmayer@arm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38501>
Having file names and dates in the generated file affects
reproducibility. Build systems (like OE) error out on the gen_header.py
output, because it can contain full paths. Drop file list from the
generated file.
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38528>
Having file names and dates in the generated file affects
reproducibility. Build systems (like OE) error out on the gen_header.py
output, because it can contain full paths. Drop file list from the
generated file.
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38528>
Skip TU_CMD_FLAG_WAIT_FOR_BR wait whenever concurrent binning is disabled.
Without CB there is nothing to wait for, so the sync only adds overhead,
and in workloads with thousands of tiny renderpasses the cumulative overhead
becomes too big.
In one real-world workload I saw the following timings:
- 99.20 ms without disabling TU_CMD_FLAG_WAIT_FOR_BR
- 65.15 ms with TU_CMD_FLAG_WAIT_FOR_BR disabled
- 64.92 ms with TU_DEBUG=nocb
Signed-off-by: Danylo Piliaiev <dpiliaiev@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38378>
Disable concurrent binning by default so regular renderpasses have access
to all vertex fetch resources. When a renderpass can actually enable CB,
walk back to the CB barrier at submission time and re-enable CB for all
patchpoints between CB barrier and the renderpass.
Because we expect at most one or two renderpasses with CB per frame,
the number of patches stays small.
The reduced vertex fetch resources resulted in up to 10% performance loss
seen in targeted benchmark and in a few game captures.
Signed-off-by: Danylo Piliaiev <dpiliaiev@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38378>
The sync emitted on TU_CMD_FLAG_WAIT_FOR_BR didn't disable CB
when CB was previously disabled for the renderpass, this resulted
in less resources vertex processing resources available for BR.
We can just not emit the sync instead, since next time CB is enabled
it will force the sync.
Signed-off-by: Danylo Piliaiev <dpiliaiev@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38378>
We have to disable CB when lrz fast-clear is disabled, but if there
is no depth image at all, we can keep it enabled. This means that
RP without depth won't effectively be a CB barrier.
Signed-off-by: Danylo Piliaiev <dpiliaiev@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38378>
ALU instructions typically have a maximum of 3 operands, and even when combining
instructions, the peak count will not go above 4.
Reviewed-by: Daniel Schürmann <daniel@schuermann.dev>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38150>
Still a bit more aggresive than the classic is_used_once,
but it should still prevent most regressions for patterns
that use min/max/mul as outer instruction.
Reviewed-by: Daniel Schürmann <daniel@schuermann.dev>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38150>
Trying to cut down apply_pipeline_layout a bit and also allowing some
reuse for a new extension.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Acked-by: Ivan Briano <ivan.briano@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38495>
This reduces some code-repetition, and makes it a bit easier to reason
about what this actually tests for.
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38162>
Unlike textures, we can't easily do format-conversion of the data
before, because the source is a buffer object and not a texture object.
But we already have a hammer for this in Mesa, which means we'll drop
the ARB_texture_buffer_object extension support, but only for the OpenGL
compatibility profile. We still get GL 4.6, both core and compatibility.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38162>
Unlike textures, we can't easily do format-conversion of the data
before, because the source is a buffer object and not a texture object.
But we already have a hammer for this in Mesa, which means we'll drop
the ARB_texture_buffer_object extension support, but only for the OpenGL
compatibility profile. We still get GL 3.1 exposed.
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38162>
Unlike textures, we can't easily do format-conversion of the data
before, because the source is a buffer object and not a texture object.
But we already have a hammer for this in Mesa, which means we'll drop
the ARB_texture_buffer_object extension support, but only for the OpenGL
compatibility profile. We still get GL 3.2 exposed.
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38162>
While OpenGL 3.1 does require texture buffer objects, the ARB spec for
this requires support for texture buffers with alpha, luminance,
luminance-alpha and intensity formats in addition to RGBA formats. The
version of texture buffer objects that ended up in the OpenGL spec (even
in the compatibility spec) does not require these formats.
But, we don't even need to check this, because this is already included
in the GLSL 1.40 requirement that's also checked. So this shouldn't make
us expose GL 3.1 in cases where it isn't supported in the first place.
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38162>
This code-path hasn't been solely about ARB_texture_buffer_object for a
long time, let's make the error message more generic to not confuse
people. While we're at it, remove the comment that brings the same
confusion.
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38162>
GL_EXT_texture_buffer_object requires support for alpha, luminance,
luminance-alpha and intensity formats. If we can't support those, we
can't enable the extension.
Fixes: 45ca7798dc ("glsl: handle interactions between EXT_gpu_shader4 and texture extensions")
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38162>
Most of the time, we remember to check for both extensions. But in one
case, it seems we forgot the GLES extension. Whoops.
Let's switch to a helper here, so we don't have to repeat the logic over
and over again.
Fixes: b4c0c514b1 ("mesa: add OES_texture_buffer and EXT_texture_buffer support")
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38162>
