Users get the deprecation warning but didn't do anything, they left
things to `auto` and we pick the deprecated `swrast`? Hardly seems fair!
(I forgot to do this when I added the deprecation warning to ajax's commit)
Fixes: 010b2f9497 ("gallium/meson: Deconflate swrast/softpipe/llvmpipe")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30366>
`st_context_invalidate_state` call is required when changing buffer attachments.
Including header with BBitmap class definition is required to properly
call C++ destructor.
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30372>
When -fsanitize=shift is used, many instances of the following are
produced:
src/intel/compiler/brw_eu_compact.c:2244:50: runtime error: left shift of negative value -306
v2: Add comment and assertion to explain why the shift is
safe. Suggested by Caio.
Reviewed-by: Caio Oliveira <caio.oliveira@intel.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30333>
When -fsanitize=shift is used, many instances of the following are
produced:
src/intel/compiler/brw_compiler.h:1661:44: runtime error: shift exponent 64 is too large for 64-bit type 'long long unsigned int'
I think this is an actual bug. It should check the sentinel value, but
the sentinel value is 64. The shift by 64 is treated as a shift by
0. The varying 0 is explicitly filtered by the rest of the
if-test. How does this work?
Reviewed-by: Caio Oliveira <caio.oliveira@intel.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30333>
Due the lack of SIMD8 in Xe2 platforms we are not able to compile
a shader for dEQP-VK.protected_memory.stack.stacksize_1024 that fits
into scratch space.
So before this patch when such failure happened it would return
VK_ERROR_OUT_OF_HOST_MEMORY error.
So here when available include the compiler error string to better
inform what the actual failure.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30380>
If the user passes in DRM_FORMAT_MOD_INVALID as an acceptable modifier,
we can progress with implicit modifiers. Add this to a more
comprehensive special case along with linear to make sure that we can
still allocate when users pass in a modifier list to a driver which
doesn't support modifiers.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Fixes: 361f362258 ("dri: Unify createImage and createImageWithModifiers")
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30383>
Honeykrisp is a Vulkan 1.3 driver for Apple GPUs. It currently support M1 and
M2, future hardware support is planned. It passed CTS a few months ago and with
two exceptions[1] should still pass now.
Compared to the May snapshot that passed conformance [1], this adds a bunch of
new features, most notably:
* Geometry shaders
* Tessellation shaders
* Transform feedback
* Pipeline statistics queries
* Robustness2
* Host image copy
Theoretically, we now support everything DXVK requires for D3D11 with full
FL11_1. To quote Rob Herring:
How's performance? Great, because I haven't tested it.
This driver is NOT ready for end users... YET. Stay tuned, it won't be long now
:}
I would like to reiterate: Honeykrisp is not yet ready for end users. Please
read [3].
Regardless, as the kernel UAPI is not yet stable, this driver will refuse to
probe without out-of-tree Mesa patches. This is the same situation as our GL
driver.
On the Mesa side, the biggest todo before the release is improving
performance. Right now, I expect WineD3D with our GL4.6 driver to give better
performance. This isn't fundamental, just needs time ... our GL driver is 3
years old and honeykrisp is 3 months old.
On the non-Mesa side, there's still a lot of movement around krun and FEX
packaging before this becomes broadly useful for x86 games.
At any rate, now that I've finished up geometry and tessellation, I'm hopefully
done rewriting the whole driver every 2 weeks. So I think this is settled enough
that it makes sense to upstream this now instead of building up a gigantic
monster commit in a private branch.
[1] Pipeline robustness and pipeline statistics are included in this tree but
need bug fixes in the CTS to pass. This is being handled internally in
Khronos. These features may be disabled to get a conformant driver.
[2] https://rosenzweig.io/blog/vk13-on-the-m1-in-1-month.html
[3] https://dont-ship.it/
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Acked-by: Faith Ekstrand <faith.ekstrand@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30382>
