[WHY & How]
Ensures type-safe comparison for the sys_event callback assignment by
casting the NULL constant to the appropriate function pointer type.
Acked-by: Chuanyu Tseng <Chuanyu.Tseng@amd.com>
Signed-off-by: Muhammad Ansari <Muhammad.Ansari@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37504>
[HOW]
Created check_blending_support function and condition to check for
readable purpose
Acked-by: Chuanyu Tseng <Chuanyu.Tseng@amd.com>
Signed-off-by: Zhao, Jiali <Jiali.Zhao@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37504>
Mesh shader output block is always in array type, need
to validate if the mesh shader output array element type
match the fragment shader input type.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Acked-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36405>
Some applications are not ready to handle multi plane
modifiers.
User who want this feature can use AMD_DEBUG=export_modifier
to enable it again.
Fixes: 0a266f0256 ("radeonsi: really support eglExportDMABUFImageQueryMESA")
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/13917
Reviewed-by: Timothy Arceri <tarceri@itsqueeze.com>
Tested-by: Mikhail Gavrilov <mikhail.v.gavrilov@gmail.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37433>
Needing the positions both in the scene for rasterization (in fixed point)
and in the fs (as floats) is a bit awkward, for now just put it in fs key.
Otherwise pretty straight forward.
Reviewed-by: Michal Krol <michal.krol@broadcom.com>
Reviewed-by: Brian Paul <brian.paul@broadcom.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37181>
mesa/st flips y coordinates if fbo orientation is Y_0_BOTTOM (essentially
user fbos), and all 3 gallium drivers supporting the feature then
unconditionally reverse this flip. llvmpipe wants to support this as well,
and it would have to do the flip too, and it's actually problematic for
lavapipe, since then lavapipe would have to flip as well, which means that
we'd lose the ability to set y positions to 0 (as the flip with the 4 bit
values does 16-val), and vulkan requires the minimum to be 0.
Hence, reverse this and flip when fbo orientation is Y_0_TOP. I don't actually
pretend to know if this is correct or if just no flipping should occur, but at
least this is consistent with how default sample locations are reported by mesa
via glGetMultisamplefv (which does y flip with the values it gets via
pipe->get_sample_position() if it's a winsys fb).
Reviewed-by: Michal Krol <michal.krol@broadcom.com>
Reviewed-by: Brian Paul <brian.paul@broadcom.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37181>
There's nothing to be done in lavapipe, all handled by llvmpipe.
There's a couple new failures in zink with 6/8 samples, but they are all the
same as already happening with 2/4 samples, so nothing specific to 8 samples.
Reviewed-by: Michal Krol <michal.krol@broadcom.com>
Reviewed-by: Brian Paul <brian.paul@broadcom.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37181>
The scissor planes we were setting up did not actually correspond to scissor
with widths / heights being a multiple of full pixels, rather they had an
excess width / height of (nearly) half a pixel (at the x0 and y0 edges).
(Note it's not an actual scissor as in graphics APIs terms, it's the
intersection of fb/viewport/scissor.)
Without multisampling that was still fine (since we always test at pixel
center) however vk cts complained (for some reason only when using 8 samples
(not announced by lavapipe yet) - no idea why it doesn't fail when using 4
samples), in tests such as
dEQP-VK.renderpass2.depth_stencil_resolve.image_2d_17_1.samples_8.s8_uint.depth_zero_stencil_zero_testing_stencil_samplemask,
which uses scissor and noted that the result for some pixels which are outside
the rendering area don't contain the clear color. And actually a llvmpipe
test was failing as well.
There is in fact no need for separate adjustments for msaa at all, as long
as we ensure that x0, y0, x1, y1 all are exactly on their respective plane
edges (inclusive for x0/y0, exclusive for x1/y1). So the logic is mostly
reverted to what it was before this was adjusted for msaa (albeit the original
code then had an excess adjustment of nearly a full pixel at the x0 and y0
edges which is probably why it didn't work for msaa).
Fixes a couple cases of clip-and-scissor-blit tests in llvmpipe and various
other drivers hitting this indirectly. Interestingly though not quite all cases
are fixed and even more odd is that not exactly the same cases are fixed for
all drivers, so maybe there's more to it (need to respect bottom_edge_rule or
something similar?)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37181>
The temporary resource created for render_to_single_sampled was never freed,
hence asan complaining.
Let's fix this before announcing support for msaa 8x in lavapipe, which
otehrwise causes more failures there.
(As a side note, no matter what I try I can't get asan complaining about
this locally, so just relying on ci here.)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37181>
