The GFX12 ISA doc describes other layouts for A/B, but they are identical
to the C layout with the exception of the order of the rows (columns for A).
And as long as these are swapped in the same way for both A and B, the muladd
result will be the same. So we use the C layout for all uses.
This will simplify conversions between uses, and allows A/B to use a single
memory access for load/store in wave32.
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35570>
The intel-adl-cl job was previously running on two DUTs, but the
runtime reported by deqp-runner was only about 3 minutes.
Signed-off-by: Valentine Burley <valentine.burley@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35574>
Introduce a new, pre-merge vkd3d-proton job on Alder Lake, and move the
VK_DRIVER variables to the .anv-test template.
Signed-off-by: Valentine Burley <valentine.burley@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35574>
This matches up with the native gl drivers as well as the media stack.
- VK_SAMPLER_YCBCR_RANGE_ITU_NARROW <=> EGL_YUV_NARROW_RANGE_EXT
Cc: mesa-stable
Acked-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35597>
This matches up with the native gl drivers as well as the media stack.
- VK_SAMPLER_YCBCR_RANGE_ITU_NARROW <=> EGL_YUV_NARROW_RANGE_EXT
Cc: mesa-stable
Acked-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35597>
This shouldn't matter if FDM is actually enabled, because in that case
the pipeline must enable the bit and we dirty FDM state at the
beginning, but pipelines can enable FDM even if the renderpass they're
used in doesn't use FDM and in that case we still need to use the FDM
path to duplicate the viewports. Fix the case where a different pipeline
is bound that enables FDM without actually using FDM.
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35581>
Will be used by Cuttlefish CI/CD, but also commonly used by
gfxstream developers.
meson setup gfxstream-build -Dvulkan-drivers="gfxstream" -Dgallium-drivers="" -Dvirtgpu_kumquat=true -Dopengl=false -Drust_std=2021
In distros, virtgpu_kumquat is not expected to be packaged since
it is a CI/CD tool.
Reviewed-by: Aaron Ruby <aruby@qnx.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35210>
This crate is intended to house zerocopy-based protocols
and utilites for them. This is useful for paravirtualization
and microkernel-like systems.
Currently, the only supported protocol is the Kumquat GPU protocol.
https://crosvm.dev/book/appendix/rutabaga_gfx.html#kumquat-media-server
And there is a concept of a "KumquatStream". In the future, there
would be more protocols, like a "MagmaStream". In fact, this crate
would house more generic streams in the future, a gfxstream crate
(* hears minds getting blown *) if you would like.
Reviewed-by: Aaron Ruby <aruby@qnx.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35210>
This is intended to a Rust analog to "src/util", which has
many utilities used by Mesa developers. This is mostly
a copy of ${crosvm} rutabaga_gfx/src/rutabaga_os (which will
be deleted in favor of this crate).
Key constructs include:
- SharedMemory
- MemoryMapping
- Tube (sockets, essentially)
- OwnedDescriptor (HANDLE or fd-based)
- WaitContext (epoll, ..)
As one would expect, Linux implementations are the most complete.
Acked-by: Aaron Ruby <aruby@qnx.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35210>
- formatting clean-ups, remove tabs, trailing whitespace.
- move var decls into loops or closer to where they're used.
- add const qualifiers.
No functional changes.
Signed-off-by: Brian Paul <brian.paul@broadcom.com>
Reviewed-by: Neha Bhende <neha.bhende@broadcom.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35579>
the logic for incrementing this in recorder/executor threads was far
too complex, which meant there were unlimited bugs which could trigger
in subtle corner cases
rework this to be simpler to ensure that the executor info always matches
up with the recorder info
Acked-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35477>
