This is an internal state, so does not need to be made available in the
string itself (same as the wpos_y_transform). But it needs to be listed
to avoid the mesa_problem.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Alyssa Rosenzweig <alyssa@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13073>
fma32 only round once so has 0.5UP accuracy. mad32 round twice so
has 1UP accuracy. This accuracy difference sometimes make the result
different at the last bit.
Applications like META need more accuracy for display right result.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Signed-off-by: Qiang Yu <yuq825@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13686>
This makes a4xx look more like a3xx for these settings. Most importantly
it adds the workaround for allowing the hw to decide between min and mag
filtering. This fixes a number of dEQP texture filtering tests.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13763>
When force-flushing after every draw, this would otherwise hit a NULL
batch in fd_blitter_clear.
Tested on a4xx.
Suggested-by: Rob Clark <robdclark@chromium.org>
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13761>
We need to guarantee that when vkQueueSubmit() returns the application
can actually wait on a signaled semaphore/syncobj.
When using a thread to do the submission to i915, this gets a bit
tricky in the following case :
A syncobj is used both as a wait & signal semaphore and has been
signaled once already. It contains a fence before entering
vkQueueSubmit().
This means we need to reset the syncobj to ensure when we return
from vkQueueSubmit(), the syncobj contains no stale fence.
Currently in the Anv, the submission thread is in charge of putting
the new fence in the syncobj and also picks up the wait fence
directly from the syncobj. This means we can't reset the syncobj
from vkQueueSubmit().
The solution to this has been pointed by Bas & Jason :
In vkQueueSubmit(), clone the wait syncobj fence into a new
temporary syncobj that will be destroy after submission and use
this temporary syncobj as a wait fence for i915. This allows us to
reset the original syncobj in vkQueueSubmit().
For this to work with wait_before_signal behavior, we also need to
do a wait-on-materialize on binary semaphores from vkQueueSubmit().
Otherwise the application thread calling vkQueueSubmit() could race
the submission thread and pick up the wrong fence when cloing.
v2: Use copy semantic for clone_syncobj_dma_fence() (Jason)
Do the cloning prior to adding the syncobj to anv_queue_submit so
that if the cloning fails don't have an invalid syncobj in
anv_queue_submit (Jason)
v3: Fix another syncobj leak (Jason)
v4: Fix invalid argument order (Lionel)
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Cc: mesa-stable
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/4945
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11474>
From VUID-VkAttachmentReference2-attachment-04755:
"If attachment is not VK_ATTACHMENT_UNUSED, and the format of the
referenced attachment is a depth/stencil format which includes both
depth and stencil aspects, and layout is
VK_IMAGE_LAYOUT_DEPTH_ATTACHMENT_OPTIMAL or
VK_IMAGE_LAYOUT_DEPTH_READ_ONLY_OPTIMAL, the pNext chain must include
a VkAttachmentReferenceStencilLayout structure."
We did not check that there even could be a stencil layout
before fetching it.
Fixes a few tests from:
dEQP-VK.image.depth_stencil_descriptor.depth_read_only_optimal.*
Fixes: 979ea394e5 "vulkan/util: Move
helper functions for depth/stencil images to vk_iamge"
Signed-off-by: Danylo Piliaiev <dpiliaiev@igalia.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13740>
GLES2.0 spec allows parts of wide lines and points to be drawn even if
their center is outside the viewport.
Therefore 0x2000 in PLBU_CMD_PRIMITIVE_SETUP has to be set for points.
This is already our default setting as it seems to have no negative
effect when this bit is always set. Points work as expected but lines
don't. It's hard to RE it, because the affected deqp tests also fail
with the blob.
To respect this behaviour for lines and solve another 2 tests, we need
to do a workaround and temporarily extend the viewport by half of the
line width. The scissor rectangle is still equal with the initial
viewport.
Reviewed-by: Vasily Khoruzhick <anarsoul@gmail.com>
Signed-off-by: Andreas Baierl <ichgeh@imkreisrum.de>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12971>
SPM is hardware feature that allows us to dump performance counters
at a sampling interval to a buffer. It is used by RGP to report cache
counters.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13704>
In order to implement GL_PRIMITIVES_GENERATED, v3d allocates a small
resource and adds a command to the job to store the prim counts to it.
However it was only doing this when TF was enabled which meant that if
the query was used with a geometry shader but no TF then the query would
always be zero. This patch makes the driver keep track of how many
PRIMITIVES_GENERATED queries are in flight and then enable writing the
prim count if its more than zero.
Fix dEQP-GLES31.functional.geometry_shading.query.primitives_generated_*
v2: Update CI expectations and references to fixed tests in commit log.
v3: - Add comment that GL_PRIMITIVES_GENERATED query is included because
OES_geometry_shader, but it is not part of OpenGL ES 3.1. (Iago)
- Update Fixes to commit introducing geometry shaders. (Iago)
Fixes: a1b7c084 ("v3d: fix primitive queries for geometry shaders")
Signed-off-by: Neil Roberts <nroberts@igalia.com>
Signed-off-by: Jose Maria Casanova Crespo <jmcasanova@igalia.com>
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13712>
Fix defect reported by Coverity Scan.
Resource leak (RESOURCE_LEAK)
leaked_storage: Variable qdws going out of scope leaks the storage it
points to.
Fixes: 9a7d6a110e ("virgl/drm: explicit context initialization")
Suggested-by: Gert Wollny <gert.wollny@collabora.com>
Signed-off-by: Vinson Lee <vlee@freedesktop.org>
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13609>
../src/microsoft/spirv_to_dxil/dxil_validation.cpp: In function ‘bool validate_dxil(dxil_spirv_object*)’:
../src/microsoft/spirv_to_dxil/dxil_validation.cpp:129:12: error: ‘stderr’ was not declared in this scope
129 | fprintf(stderr, "DXIL validation only available in Windows.\n");
| ^~~~~~
Fixes: 37c366e283 ("microsoft/spirv_to_dxil: Add DXIL validation to spirv2dxil")
Signed-off-by: Vinson Lee <vlee@freedesktop.org>
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13736>
This deletes a whole lot of code, but there's a modest drawoverhead perf
loss:
drawoverhead 1-image change -6.48856% +/- 4.28269% (n=50)
drawoverhead 8-image change -5.29195% +/- 2.62549% (n=90)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13443>
Having checked the deltas between fdl6_view and what we did before, switch
over to fdl6_view now.
No statistically significant difference on no-hw drawoverhead 8-texture
change (n=50) with the texture cache disabled from this and the previous
commit.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13443>
turnip was playing fast and loose with the name, using the R8_G8B8 format
name but actually setting the descriptors up to read G8_B8R8 like Vulkan
(sensibly) wants. This caused trouble when trying to make freedreno and
turnip share code. By having both orderings as format names, we can share
the descriptor code and also confuse readers less.
Reviewed-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13443>
The only user, turnip, was actually treating it as this layout, matching
vulkan's specification of how the planes map to RGB values. (Y=G means
that Cb=B and Cr=R).
Reviewed-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13443>
We can see from the dynamically_uniform (compiler doesn't know if you're
uniform or not) vs uniform (compiler can see it's uniform) case in the
blob which is which. Now that we have the right names, also use the
nonunif flag for encoding the actual non-uniform mode (previously, we were
always setting it always in a way that meant uniform).
I verified this behavior back to a418 with samplers. The a3xx blob I have
only does GLES3, so we don't have the opaque_type_indexing tests to see.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13601>
Ilia Mirkin
Iago Toral Quiroga
James Park
Qiang Yu
Christian Gmeiner
Mike Blumenkrantz
Lionel Landwerlin
Caio Oliveira
Danylo Piliaiev
Emma Anholt
Alejandro Piñeiro
Andreas Baierl
Samuel Pitoiset
Neil Roberts
Vinson Lee
Eric Engestrom
Jesse Natalie