If the state tracker chooses to implement one format with a more
general one (e.g. GL_ALPHA implemented with GL_RGBA) we end up
in a situation where some components should be ignored. Readpix
handles this correctly, but blit does not, which means that if
we blit between different formats we can end up writing garbage
into some components. Work around this by adding an explicit
swizzle to the pipe_blit_info struct, which can re-arrange elements
and/or put 0 or 1 into appropriate channels, and use this to
set the appropriate values into unused channels via the sampler
view.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Faith Ekstrand <faith.ekstrand@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31378>
Ended up deciding to drop C++ collections and use instead C pointers
because the template use was starting to get ridiculous.
Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32485>
In panfrost_query_compression_modifiers we need to ignore AFBC
modifiers if the device does not support AFBC. In order to avoid
duplicating code, we do this by calling panfrost_walk_dmabuf_modifiers
with a flag that indicates we do not want AFRC modifiers.
Reviewed-by: Louis-Francis Ratté-Boulianne <lfrb@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32406>
We need to start treating flakes as fails and they are likely different
between chips.
I removed the gfx9 flakes file and renamed the original flakes file
to gfx6-tahiti-flakes.csv, but it would be better to add a new flakes
file for each generation we test.
Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32288>
The culling code always computes the determinant for culling zero-area
triangles, so passing the state via user SGPRs doesn't really add much
shader code to justify having shader variants for front/back face
culling that uses the same determinant.
Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32288>
We have a helper function to iterate only on intrinsics, so let's use it.
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Reviewed-by: Mary Guillemard <mary.guillemard@collabora.com>
Reviewed-by: Chia-I Wu <olvaffe@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32480>
Move away from NIR_PASS_V() like other drivers have done long ago.
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Reviewed-by: Mary Guillemard <mary.guillemard@collabora.com>
Reviewed-by: Chia-I Wu <olvaffe@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32480>
The spec mandates that if the program object isn't created from IL, it
should not touch the buffer. Passing an empty slice would achieve that,
but it's better to be explicit here.
Reviewed-by: @LingMan
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32268>
The old way was quite annoying as it required to create a Vec to even get
the size of the result causing needless computations.
This also meant that copying into the result buffer always required to go
through a byte Vec even though we could just do the copy directly.
The main idea here is that instead of returning the result, we simply call
into a write function giving us more flexibility here.
Potentially this will also allow us to add overloads for Iterators or to
even use closures in case the size calculation is cheaper than creating
the value just to get the size.
Reviewed-by: @LingMan
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32268>
They are a maintainenance burden since they would need changes to
support more instruction types that nir_opt_varyings will be able to
move between shaders, and they are almost identical to
default_varying_estimate_instr_cost, so just use that.
The cost threshold is adjusted for AMD because
default_varying_estimate_instr_cost is slightly different.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32424>
The fast implementation can be off by a lot for small values.
Fixes:
dEQP-VK.spirv_assembly.instruction.compute.compute_shader_derivatives.compute.lod_op.query.linear.16_1_1.mip_0
dEQP-VK.spirv_assembly.instruction.compute.compute_shader_derivatives.compute.lod_op.query.linear.16_1_1.mip_1
dEQP-VK.spirv_assembly.instruction.compute.compute_shader_derivatives.compute.lod_op.query.linear.4_4_1.mip_0
dEQP-VK.spirv_assembly.instruction.compute.compute_shader_derivatives.compute.lod_op.query.linear.4_4_1.mip_1
dEQP-VK.spirv_assembly.instruction.compute.compute_shader_derivatives.mesh.lod_op.query.linear.16_1_1.mip_0
dEQP-VK.spirv_assembly.instruction.compute.compute_shader_derivatives.mesh.lod_op.query.linear.16_1_1.mip_1
dEQP-VK.spirv_assembly.instruction.compute.compute_shader_derivatives.mesh.lod_op.query.linear.4_4_1.mip_0
dEQP-VK.spirv_assembly.instruction.compute.compute_shader_derivatives.mesh.lod_op.query.linear.4_4_1.mip_1
dEQP-VK.spirv_assembly.instruction.compute.compute_shader_derivatives.task.lod_op.query.linear.16_1_1.mip_0
dEQP-VK.spirv_assembly.instruction.compute.compute_shader_derivatives.task.lod_op.query.linear.16_1_1.mip_1
dEQP-VK.spirv_assembly.instruction.compute.compute_shader_derivatives.task.lod_op.query.linear.4_4_1.mip_0
dEQP-VK.spirv_assembly.instruction.compute.compute_shader_derivatives.task.lod_op.query.linear.4_4_1.mip_1
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31056>
Only single g33 as part of r300 ci-tron-based farm.
Signed-off-by: Pavel Ondračka <pavel.ondracka@gmail.com>
Reviewed-by: Eric Engestrom <eric@igalia.com>
Reviewed-by: Martin Roukala (né Peres) <martin.roukala@mupuf.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32376>
Only consider R32 image formats as supporting atomics because we only
expose VK_FORMAT_FEATURE_2_STORAGE_IMAGE_ATOMIC_BIT for those formats.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32192>
