[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>
We are using different llvm type depending on the cpu supporting f16c
instructions or not.
The reasoning behind this was that we really couldn't do anything with f16
values and had to cast them to some int type anyway, plus IIRC originally
this actually predates llvm even supporting a half type in the first place
(or if it did, at the very least it was not able to do anything useful with
it).
There are now bugs with lavapipe when the cpu doesn't support f16c, since while
we don't expose f16 capabilities in this case, we can still hit f16 conversion
functions for the likes of unpack2x16float and quantizeToF16, and we're just
straight calling fpext/fptrunc functions, not touching our own code for half
conversion (I believe our own code might still be faster as llvm de-vectorizes
it if it's not supported by the cpu, but don't quote me on that - could depend
on llvm version, and also for trunc the rounding is actually different since
our own functions implement rounding according to d3d10 requirements (mostly
used for f16 render targets)).
This only seems to be a problem for vulkan, not GL, since glsl has its own
lowering pass if the half float packing instructions aren't supported by the
driver.
Ideally we'd fix this by just always using llvm half type for f16, however
still not all llvm backends can handle it.
So instead do some hacky bitcasts around the fpext/fptrunc calls with f16,
which works on x86 even when not supporting f16c. Other llvm backends not
really supporting halfs will still crash there as before (albeit it should
be a "cleaner" crash as the IR is now correct...), but at least keeps them
running for more ordinary things such as f16 texture sampling / render
targets (which they wouldn't if we'd use llvm half type everywhere).
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/13807
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/13865
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37344>
