Do it when we bind shaders.
The advantages are:
- no need to memset the fields when any shader variant state is changed
(e.g. culling on/off)
- no need to recompute the fields every time that happens
Acked-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12656>
This simplifies si_update_shaders. It also makes it more obvious that
si_update_shaders could become a C++ template one day.
Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12656>
This just changes the calcs to be cleaner and easier to interpret.
Adjust the inclusive (x0/y0) by -1 like before, and then flip the
sign for the correct direction.
Add full pixel to the exclusive side after scaling, this is do
show that this value is incorrect and the next patch fixes that
taking multisample into account
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12504>
The state wasn't storing the shader depth/stencil outputs
per-sample, so only the last sample emitted was being used
for the late depth test and stencil ref.
Noticed while trying to fix some vulkan depth stencil resolve
issues
Fixes: a0195240c4 ("llvmpipe: handle multisample early depth test/late depth write")
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12504>
According to OES_EGL_image_external_essl3:
On p. 196 in the errors section for BindImageTexture, replace the
last error with the following:
"An INVALID_OPERATION error is generated if <texture> is neither the
name of an immutable texture object, nor the name of an external
texture object."
According to OES_EGL_image_external:
The command
void EGLImageTargetTexture2DOES(enum target, eglImageOES image);
with <target> set to TEXTURE_EXTERNAL_OES defines the currently bound
external texture object to be a target sibling of <image>.
...
If <target> is not TEXTURE_EXTERNAL_OES, the error INVALID_ENUM is
generated. (Note: if GL_OES_EGL_image is supported then <target> may
also be TEXTURE_2D).
Currently, mesa only allows GL_TEXTURE_EXTERNAL_OES textures to be bound
by glBindImageTexture. However, the language of the specification does not
appear to use "external" to refer to GL_TEXTURE_EXTERNAL_OES specifically,
since OES_EGL_image_external allows external eglImageOES to be attached
to GL_TEXTURE_2D in the presence of GL_OES_EGL_image. Thus, it should be
interpreted to refer to all types of external textures, including 2D
textures attached via glEGLImageTargetTexture2DOES.
Fixes: ed43dd62ac ("main: allow external textures for BindImageTexture")
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12383>
The scanout engine is not coherent with rendering, so make sure
scanout buffers are mapped WC. This ensures that CPU rendering as done
by the Xserver gets flushed to the frame buffer immediately instead of
waiting for some future time.
v2:
Also mark shared buffers to be allocated for scanout
in case they are being used for scanout elsewhere.
Signed-off-by: Keith Packard <keithp@keithp.com>
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/5231
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12259>
instance->physical_devices includes only supported devices, not all
devices. One example is that it does not include 1.0 devices. We need
to fix up VkPhysicalDeviceGroupProperties to exclude unsupported
devices.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
Reviewed-by: Ryan Neph <ryanneph@google.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12637>
We don't need to worry about how vkEnumeratePhysicalDeviceGroups is
called (props is NULL, props is non-NULL but count is 0, etc.) this way.
It also allows us to fix up VkPhysicalDeviceGroupProperties easily.
v2: let the for-loop increment (Yiwei)
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org> (v1)
Reviewed-by: Ryan Neph <ryanneph@google.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12637>
a6xx supports shaders with more than 64k dwords, or at least the shader
size register has increased in size, and the matching name is gone so
there's no reason to be clever here. This doesn't fix anything at the
moment.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12487>
This fixes duplicate CB0 declarations, missing interface array
declarations, and too-low sizes of UBOs containing multiple nir_variables.
Closes: #4810
Reviewed-by: Adam Jackson <ajax@redhat.com>
Acked-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12175>
Normal UBOs have explicit strides on them, make our lowered one behave the
same.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Acked-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12175>
Without this, there's no way to match the UBO nir_variable declarations to
the load_ubo intrinsics referencing their data.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Acked-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12175>
For now, only mark the 4x8BitPacked variants as accelerated.
Applications are unlikely to use the "add with saturate" opcodes from
VK_INTEL_shader_integer_functions2, so, technically, all of the
AccumulatingSaturating variants "[provide] a performance advantage over
user-provided code composed from elementary instructions..." on all
Intel platforms. If we encounter an application that cares, we can do
things differently then. Ditto for the non-packed 8Bit, 4-element
vector variants.
v2: Don't memset props as this also zeros sType and pNext. Noticed by
Georg Lehmann in !12617.
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12624>