Some jobs failed during the re-enablement of Collabora's LAVA farm.
The trace job radeonsi-stoney-traces:amd64 produced some traces with
almost unnoticeable lighting spread difference, so I updated all the
traces.
Now the test spec@ext_texture_lod_bias@lodbias is failing after running
a couple of times.
Signed-off-by: Guilherme Gallo <guilherme.gallo@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20903>
described as "32 Execution Unit (EU) Super SKU" in:
Intel Atom x6000E Series, and Intel Pentium and Celeron N and
J Series Processors for IoT Applications
Datasheet, Volume 1
Document Number: 636112-1.6
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21129>
according to spec, the maximum number of acquired images can be calculated with
swapchain_size - VkSurfaceCapabilitiesKHR::minImageCount + 1
the previous calculation was both wrong and occurring in the wrong place,
so this corrects both issues
cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21095>
GL Spec says that imageLoad from incomplete images must return 0.
This is not really spec compliant as for proper behavior nullDescriptor
and robustImageAccess2 is needed.
A workaround for lack of either of these requires a shader variant.
Clearing the null surface and hoping the app doesn't write to the image
is closer to spec, while avoiding a shader recompile.
KHR-GL46.shader_image_load_store.incomplete_textures tests this.
cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21135>
simple way to reproduce this is to run these 4 together:
KHR-GL46.gpu_shader5.images_array_indexing
KHR-GL46.shader_image_load_store.advanced-allMips
KHR-GL46.shader_image_load_store.advanced-sso-simple
KHR-GL46.shader_image_load_store.incomplete_textures
cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21134>
Besides being nicer, this also fixes load_sample_positions_amd with LLVM.
Signed-off-by: Rhys Perry <pendingchaos02@gmail.com>
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19202>
Found by inspection. Something probably hangs because of this, but I don't
know what.
Signed-off-by: Rhys Perry <pendingchaos02@gmail.com>
Reviewed-by: Tatsuyuki Ishi <ishitatsuyuki@gmail.com>
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Fixes: c199a5160a ("radv: bind the VS input state for prologs created with GPL")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20913>
We need to pad VkBuffers to ensure we don't read beyond a page boundary.
An alternative to this approach would be to allocate an additional virtual
page when binding memory to the buffer, and to map this to the first
physical address, so both the first and last virtual page point to the same
physical location. This would be less expensive in terms of memory usage,
but more complex and invasive, hence the simpler approach has been taken
for now.
Signed-off-by: Luigi Santivetti <luigi.santivetti@imgtec.com>
Reviewed-by: Frank Binns <frank.binns@imgtec.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21101>
This new helper, do_emit_fb_writes() does the actual walk over all the
render targets to emit each of the different FB writes. We want this in
a helper because we're about to go a bit crazy with coarse.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21094>
This is required by code-gen since it generates a 1-wide OR and it'll
blow up if the register width > 1. It's also way better than the "your
register is the wrong size" assert you get from the more generic
validation check.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21094>
This allows us to communicate to the back-end that we don't actually
know if the framebuffer is multisampled or not. No drivers set anything
but ALWAYS/NEVER and we still have a few ALWAYS/NEVER assumptions but
those should be asserted.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21094>
This allows for the possibility that we may not know at compile time if
sample shading is enabled through the API. While we're here, also
document exactly what this bit means so we don't confuse ourselves.
v2: Fixup coarse pixel values (Lionel)
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21094>
Whenever one of them is BRW_SOMETIMES, we depend on dynamic flag pushed
in as a push constant. In this case, we have to often have to do the
calculation both ways and SEL the result. It's a bit more code but
decouples MSAA from the shader key.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21094>
This is more similar to what we do for single-sample and it should be
more clear going forward once our lowering gets more complex.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21094>
If alpha-to-coverage is exported via mrtz, don't upgrade the mrt0 format
to one with an alpha channel.
Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20967>
If we have multiple clip planes, rather than emit multiple discards we can just
OR together the discard criteria. Then a nir_opt_algebraic rule kicks in to
optimize out the flt/.../flt/ior/.../ior into fmin/.../fmin/flt, generating
much less code at the end.
Written while debugging an unrelated issue with the clip lowering.
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/21103>
this allows drivers to indicate that they support sampling from null
textures instead of using fallback textures
for now, this is only used for depth-based fallback textures
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21072>
