Only genX_cmd_buffer.c makes use of READ_ONCE() but that file also
defines it so it can be removed from anv_batch_chain.c.
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24411>
Preferring interlaced results in all surfaces being allocated
as interlaced for H264 decode regardless of whether the decoded
pic is interlaced or progressive, which makes VA postproc
apply deinterlacing even for progressive pics.
Deinterlacing interlaced pics still works because VA frontend
will now reallocate surface as interlaced when decoding interlaced
pics.
Reviewed-by: Ruijing Dong <ruijing.dong@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24361>
When decoding interlaced pics, the output surface should
also be allocated as interlaced to make the deinterlace
postproc filter work correctly.
Reviewed-by: Ruijing Dong <ruijing.dong@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24361>
When decoding interlaced pics, the output surface should
also be allocated as interlaced to make the deinterlace
postproc filter work correctly.
This makes deinterlacing work for drivers that supports, but
not prefers, interlaced surfaces.
Use extra buffer instead of reallocating as non-interlaced
when exporting interlaced surfaces.
v2: Avoid reallocating in vlVaExportSurfaceHandle
Reviewed-by: Ruijing Dong <ruijing.dong@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24361>
The GL_EXT_multisampled_render_to_texture spec explicitly allow reading
from these FBOs.
"Similarly, for ReadPixels:
'An INVALID_OPERATION error is generated if the value of READ_-
FRAMEBUFFER_BINDING (see section 9) is non-zero, the read framebuffer is
framebuffer complete, and the value of SAMPLE_BUFFERS for the read
framebuffer is one.'
These errors do not apply to textures and renderbuffers that have
associated multisample data specified by the mechanisms described in
this extension, i.e., the above operations are allowed even when
SAMPLE_BUFFERS is non-zero for renderbuffers created via Renderbuffer-
StorageMultisampleEXT or textures attached via FramebufferTexture2D-
MultisampleEXT."
Signed-off-by: Italo Nicola <italonicola@collabora.com>
Reviewed-by: Emma Anholt <emma@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10747>
For EXT_multisampled_render_to_texture, we store the number of samples
in Attachment->NumSamples instead of Renderbuffer->NumSamples. This
meant that the previous code ignored that the framebuffer was
multisampled. Because of this, pipe_rasterizer_state::multisample is set
incorrectly, leading to visual artifacts on drivers that support MS-RTT
extension, such as panfrost.
Signed-off-by: Italo Nicola <italonicola@collabora.com>
Reviewed-by: Rob Clark <robclark@freedesktop.org>
Reviewed-by: Emma Anholt <emma@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10747>
All MOCS tables have 0 as a invalid value, so this will asssert
in case some place misset to set MI_MATH MOCS field.
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22508>
MOCS = 0 is a invalid MOCS index on MTL, so it is necessary get a
valid value and set to MI_MATH instructions.
So here the mocs index is set with mi_builder_set_mocs(), it can be
always set but it is required when mi_build will emit MI_MATH
instructions.
The mocs index will only be stored and used in gfx12.5+ platforms
so no changes were are required in crocus or hasvk.
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22508>
MOCS = 0 is a invalid MOCS index, so it is necessary get a valid value
and set to MI_MATH instructions.
So here the mocs index is set with mi_builder_set_mocs(), it can be
always set but it is required when mi_build will emit MI_MATH
instructions.
The mocs index will only be stored and used in gfx12.5+ platforms
so no changes were are required in crocus or hasvk.
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22508>
MOCS = 0 is a invalid MOCS index on MTL, so it is necessary get a
valid value and set to MI_MATH instructions.
So here the mocs index is set with mi_builder_set_mocs(), it can be
always set but it is required when mi_build will emit MI_MATH
instructions.
The mocs index will only be stored and used in gfx12.5+ platforms
so no changes were are required in crocus or hasvk.
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22508>
Passes most of dEQP-VK.spirv_assembly.instruction.graphics.opquantize.* but
not the too_small_* tests for some reason. (Tested on kepler.)
Reviewed-by: Faith Ekstrand <faith.ekstrand@collabora.com>
Reviewed-by: Karol Herbst <kherbst@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24327>
We don't actually use or need this information but it gets generated by
nir_opt_non_uniform_access() and stale divergence information can cause
out-of-SSA to assert in parallel copy lowering.
Reviewed-by: M Henning <drawoc@darkrefraction.com>
Reviewed-by: Karol Herbst <kherbst@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24327>
In the case of SPIRV tessellation shaders, the execution mode can be
specified in the tessellation control shader. So we need a way to know the domain
when compiling the tessellation evaluation shader.
Acked-by: M Henning <drawoc@darkrefraction.com>
Reviewed-by: Karol Herbst <kherbst@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24327>
Get rid of our own FMT_NONE and just use a NULL format in that case.
We're already checking su->tex.format != NULL in a bunch of cases but
none of those NULL checks are doing anything right now execpt detecting
when its an actual texture op and not an image op. We'd like them to
start also applying for image load/store with an unspecified format.
Reviewed-by: M Henning <drawoc@darkrefraction.com>
Reviewed-by: Karol Herbst <kherbst@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24327>
This came from CTS clipping tests with geometry shaders. Maybe can be
done as a lowering operation instead.
Reviewed-by: M Henning <drawoc@darkrefraction.com>
Reviewed-by: Karol Herbst <kherbst@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24327>
This instructs NIR to lower DeviceIndex to zero, which is needed
for a no-op implementation of VK_KHR_device_group.
Signed-off-by: Rebecca Mckeever <rebecca.mckeever@collabora.com>
Reviewed-by: M Henning <drawoc@darkrefraction.com>
Reviewed-by: Karol Herbst <kherbst@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24327>
gp has explicit load and store reg instructions so it can implement
the new nir_intrinsic_{decl,load,store}_reg intrinsics.
The implementation reuses the gpir_node_find and register_node functions
instead of just emitting load and store instructions in order to
preserve the behavior that there will never be a store_reg followed by
a load_reg of the same register in the same block.
Signed-off-by: Erico Nunes <nunes.erico@gmail.com>
Reviewed-by: Vasily Khoruzhick <anarsoul@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24246>
With the upcoming transition away from nir_register and modifiers in
nir, ppir needs to prepare for those features to be removed.
The most straightforward way for ppir without major reworks at this time
is to use the new nir_legacy helpers so that most of the backend can be
kept untouched (particularly due to use of abs/neg/sat modifiers).
Do this for now to unblock the transition with little impact; ppir can
be optimized at a later moment to have its own passes which will allow
it to drop the nir_legacy use and use just the chasing helpers.
Signed-off-by: Erico Nunes <nunes.erico@gmail.com>
Reviewed-by: Vasily Khoruzhick <anarsoul@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24246>
Even if loads are initially duplicated for each user, with new
optimizations such as folding modifiers, it may happen that loads
end up with only users in different blocks.
Handle that and don't delete or pipeline those nodes.
Signed-off-by: Erico Nunes <nunes.erico@gmail.com>
Reviewed-by: Vasily Khoruzhick <anarsoul@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24246>
This is the GLES3 sampler object API trivially backported to GLES2,
because it allows for simpler/better support in glamor and mutter.
The only code change we need is adding these to the generated dispatch
tables for ES2 contexts. The interactions with EXT_shadow_samplers,
EXT_texture_filter_anisotropic and EXT_texture_sRGB_decode are already
in place before this change, and OES_texture_border_clamp is always
supported in Mesa.
Reviewed-by: Zoltán Böszörményi <zboszor@gmail.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Signed-off-by: Adam Jackson <ajax@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/2440>
ffloor(f2i(x)) can't be optimized to f2i(x) due to differing behaviour for
negative x, but u_blitter only uses this with nonnegative x so we can instead
use ftrunc(f2i(x)) which NIR will optimize to f2i(x) for us. This gets rid of
the silly ffloor instructions in blit shaders.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24319>
True for all users. I intentionally didn't add is_ssa asserts because they're
pointless and will be deleted, like, next week and will just make that churn
even more annoying.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Reviewed-by: Faith Ekstrand <faith.ekstrand@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24319>
This dri config is no longer necessary since the case where it was
required is being handled in the previous commit.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Igor Torrente <igor.torrente@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24222>