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>
previously this only checked to see if dst was bound, but that is not
the only condition in which clears may be flushed, and triggering a clear
flush while blitting will not set image layouts, which means that a renderpass
could be illegally triggered on an UNDEFINED image (even though it wouldn't be used)
instead, do a much more thorough check to determine whether clears can actually be
stored with the expectation that they will otherwise be flushed
cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37467>
Allow users to set an environment variable to influence JM context slot
priorities.
Reviewed-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Ashley Smith <ashley.smith@collabora.com>
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Signed-off-by: Adrián Larumbe <adrian.larumbe@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37075>
A Panfrost JM context can be created by leveraging the new Panfrost 1.5
KM IOCTLs and translating Mesa pipe resource priority levels into
Panfrost-specific ones.
Reviewed-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Ashley Smith <ashley.smith@collabora.com>
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Signed-off-by: Adrián Larumbe <adrian.larumbe@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37075>
When writing to a depth texture the driver is first doing a decompress
blit to a stageing resource. On one hand this blit can be skipped, if
PIPE_MAP_DISCARD_WHOLE_RESOURCE is set, OTOH we need to clear the
PIPE_MAP_UNSYNCHRONIZED flag if a partial write is done, because we have to
wait until the blit is finished.
v2: Update the patch with a more targeted approach.
Fixes: 25b97a3a96 ("mesa/st: mark internal texture map calls as UNSYNCHRONIZED")
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/13916
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37457>
With that we can easily add a restriction to the not + flt -> fge
optimization to handle NaNs like it was done before.
Fixes: 51d8ca2dff ("r600/sfn: optimize comparison results")
v2: use SPDX license identifier (austriancoder)
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37450>
This is all dead code since we weren't even seting the cap in iris/crocus!
Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37447>
I see no point, we allocate for every shader stage anyway. This is a bit
simpler.
I'm not a fan of the brw_compiler singleton at all but torching that is not on
today's agenda. Flattening it a little bit very much is.
Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37447>
The main challenge is handling tile status (TS) correctly. Full clears
simply mark tiles as "cleared" in TS metadata without touching pixels.
Scissored clears must first decompress existing TS tiles using the
current clear color, then apply the new color to the scissor region.
The implementation maintains the original surface clear color for TS
decompression operations while using the new color for actual clearing.
This prevents rendering artifacts when mixing BLT and 3D operations.
BLT engine operates directly with pixel positions and handles all TS
tile complexity automatically.
Signed-off-by: Christian Gmeiner <cgmeiner@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35956>
On r600 ternary operations can't use the fabs source modifier, so
converting "fadd(fabs(fmul(a, b), c)" to "ffma(fabs(a), fabs(b), c)"
adds one more instruction in the backend, hence avoid this.
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37440>
Fixes this error during Shader.cpp build:
..\src\util/format/u_formats.h(33): fatal error C1083: Cannot open include file: 'util/format/u_format_gen.h': No such file or directory
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37316>
