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>
This reproduces #5254 and seems like a good idea to be checking normally.
I think running some desktop GL would also be useful here, but it turns
out that desktop glcts is pretty leaky/overflowy inside of deqp.
Acked-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12493>
for custom shader replacements enabled by -Dcustom-shader-replacement=path.
process_shaders.py should generate shader_replacement.h, which should
contain shaders and their substitutions.
Loosely based on Pierre-Eric's commit.
Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12492>
Most of these are fixed in recent mesa and virglrenderer versions, but
some might still be flaky. We'll keep an eye on them and if they are
flaky we can disable them.
Signed-off-by: Italo Nicola <italonicola@collabora.com>
Reviewed-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12643>
... before changing the PM settings.
Otherwise, we hit a kernel warning in Qualcomm devices and the device is
left in a non-functional state.
Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Acked-by: Daniel Stone <daniels@collabora.com>
Acked-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12644>
Use the first dpb buffer instead of the NULL pointer sent to hardware.
Signed-off-by: Leo Liu <leo.liu@amd.com>
Reviewed-by: James Zhu <James.Zhu@amd.com>
Reviewed-by: Boyuan Zhang <Boyuan.Zhang@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12610>
