On platforms with an indirect clear color BO, the clear color used when
sampling is in the form of a pixel. The sampler can interpret the pixel
correctly regardless of the format, so allow fast clears in more cases
within iris_resource_prepare_texture.
On gfx12, this completely removes partial resolves in a couple game
traces I tested:
- 72 partial resolves in a 500 frame trace of CS:GO.
- 1207 partial resolves in a 500 frame trace of Dota 2.
The resolves were triggered when ISL_FORMAT_A8_UNORM surfaces were
sampled as ISL_FORMAT_R8_UNORM.
Reviewed-by: Jianxun Zhang <jianxun.zhang@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24323>
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.
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>
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>
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>
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>
Alyssa Rosenzweig