v2: Instead of fixing unitialized member 'fs_visitor::input_vue_map'
(as reported by Coverity Scan in defect CID 1474559),
remove unused members 'vec4_tcs_visitor::input_vue_map' and
'fs_visitor::input_vue_map'.
Also fixed 'debug_enabled' argument skipped in a fs_visitor constructor
call from brw_compile_tes().
Signed-off-by: Yevhenii Kharchenko <yevhenii.kharchenko@globallogic.com>
Reviewed-by: Caio Marcelo de Oliveira Filho <caio.oliveira@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10040>
Because I want the compiler to eliminate some function calls in
transition_color_buffer() that produce unused return values. Let's hope
the compiler gets the hint.
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/1466>
If VkImageMemoryBarrier acquires ownership of the image on
VK_QUEUE_FAMILY_FOREIGN_EXT or VK_QUEUE_FAMILY_EXTERNAL, and if the
image has a DRM format modifier with an aux surface, then we must ensure
that the image's aux state is consistent with the modifier. In the other
direction, if VkImageMemoryBarrier releases ownership, then we may have
to resolve the image's aux surface.
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/1466>
In VkImagePlaneMemoryRequirementsInfo and VkBindImagePlaneMemoryInfo,
the spec requires the aspect to be
VK_IMAGE_ASPECT_MEMORY_PLANE_i_BIT_EXT for modifier images.
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/1466>
Reduce boilerplate with a helper function, because DRM format modifiers
will soon increase the complexity. In particular, remove the
'prev_range' variable.
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/1466>
At end of image creation, check for incompatibilities that
vkGetPhysicalDeviceImageFormatProperties2() has difficulty predicting.
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/1466>
In vkCreateDmaBufImageINTEL, use VK_IMAGE_TILING_DRM_FORMAT_MODIFIER_EXT.
No intended change in publicly visible behavior.
I really don't want to update this soon-to-be-removed function, but this
change is necessary to avoid upcoming assertion failures. In particular,
we will soon assert that the image has a modifier if and only if it has
modifier tiling.
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/1466>
We incorrectly used VK_IMAGE_TILING_OPTIMAL when the original swapchain
image had VK_IMAGE_TILING_DRM_FORMAT_MODIFIER_EXT. When we soon begin
using a different memory layout for modifier images, this mismatch would
have produced undefined behavior.
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/1466>
The meson.build was unaware of transitive dependencies introduced by
Python imports.
Android still needs fixing. But I did not update the Android files lest
I break the build.
Ideally, we would fix this by using a Python runner that generates
a depfile, similar to how meson creates depfiles for C files by passing
flags -MD -MQ -MF to gcc. But this patch gets the job done, without
stalling on the ideal general solution, by manually tracking the Python
imports in new 'foo_depend_files' variables.
CC: mesa-stable@lists.freedesktop.org
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/1466>
We can only use 16 OW reads/writes on SLM.
v2: Update comment (Curro)
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
BSpec: 47652
Fixes: 369eab9420 ("intel/fs: Emit code for Gen12-HP indirect compute data")
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10082>
We've never done anything with that HW and it was removed in ICL.
There's no point in carrying around the useless field.
Acked-by: Caio Marcelo de Oliveira Filho <caio.oliveira@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10069>
It appears that between preprocess & postprocess some descriptor
lowering introduces 8bit types in the shader, so run the lower bit
size again to make sure we don't have any unsupported types in our
shader.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Fixes: e06144a818 ("anv: Use 64bit_global_32bit_offset for SSBOs")
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/4478
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9705>
As that handles better, and more clear, the case of bindingCount being
zero. For the case of Anvil and Turnip, this avoids allocating a
non-needed binding when bindingCount is zero.
Inspired on radv, that was what it was doing so far.
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/4526
Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Hyunjun Ko <zzoon@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9905>
Earlier, I just tried to copy what iris was doing and, as it turns out,
copied it wrong. Also, Vulkan doesn't have a concept of getting the
conservative coverage in the shader. The spec for SampleMask says:
"Decorating a variable with the SampleMask built-in decoration will
make any variable contain the coverage mask for the current fragment
shader invocation."
And the spec for conservative rasterization says
"When overestimate conservative rasterization is enabled, rather
than evaluating coverage at individual sample locations, a
determination is made of whether any portion of the pixel (including
its edges and corners) is covered by the primitive. If any portion
of the pixel is covered, then all bits of the coverage mask for the
fragment corresponding to that pixel are enabled."
Putting these two together and you get what the Intel HW docs say for
ICMS_NORMAL:
"Input Coverage masks based on inner conservatism and factors in
SAMPLE_MASKs. If Pixel is conservatively fully covered all samples
are enabled."
So I'm pretty sure based on this that the right thing to do here is to
ignore conservative rasterization and leave it set to ICMS_NORMAL
whenever we're not in the post-depth-coverage special case.
While we're here, fix the silly indentation.
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/4565
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Fixes: d5b56debde "anv: Implement VK_EXT_conservative_rasterization"
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10017>
Across every driver...
v2: Add casts to appease -fpermissive used on CI.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9477>
We are missing an additional restriction on CHV & upcoming Xe-Hp.
v2: Quote BSW PRMs (Curro)
Check source is not a scalar (Curro)
Fix comment (Marcin)
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9929>
In some cases we will change the type of the destination register of
an instruction. This is the type we should use to verify that we're
allow to do the replacement.
Otherwise we can hit restrictions on CHV and upcoming Xe-Hp for
instance where the copy propagation transforms this :
send(16) (mlen: 2) vgrf10:UD, 0u, 0u, vgrf35:D, null:UD
mov(16) vgrf11:UW, vgrf10<2>:UW
mov(16) vgrf12:UW, vgrf10+0.2<2>:UW
mov(16) vgrf15:HF, |vgrf11|:HF
mov(16) vgrf16:HF, |vgrf12|:HF
mov(8) vgrf41<2>:UW, vgrf15+0.0:UW group0
mov(8) vgrf42<2>:UW, vgrf15+0.16:UW group8
mov(8) vgrf45<2>:UW, vgrf16+0.0:UW group0
mov(8) vgrf46<2>:UW, vgrf16+0.16:UW group8
into this :
send(16) (mlen: 2) vgrf10:UD, 0u, 0u, vgrf35:D, null:UD
mov(8) vgrf41<2>:HF, |vgrf10+0.0|<2>:HF group0
mov(8) vgrf42<2>:HF, |vgrf10+1.0|<2>:HF group8
mov(8) vgrf45<2>:HF, |vgrf10+0.2|<2>:HF group0
mov(8) vgrf46<2>:HF, |vgrf10+1.2|<2>:HF group8
Because of the floating point use, stride and offets should be the
same.
v2: Fix final destination type selection (Curro)
v3: constify (Curro)
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Cc: <mesa-stable@lists.freedesktop.org>
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9832>
when building with Meson. It requires libexpat that is not available
on Android and we want to avoid it.
Signed-off-by: Tapani Pälli <tapani.palli@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9848>
