git://anongit.freedesktop.org/drm/drm 2222dcb0775d36de28992f56455ab3967b30d380
The motivation for this change in to get the uapi changes from:
commit 81b1b599dfd71c958418dad586fa72c8d30d1065
Author: Fei Yang <fei.yang@intel.com>
Date: Tue Jun 6 12:00:42 2023 +0200
drm/i915: Allow user to set cache at BO creation
Specifically, the I915_GEM_CREATE_EXT_SET_PAT extension.
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22878>
NOTE: skipped AMD header update due to build error.
From drm-next at the following commit:
commit 2e1492835e439fceba57a5b0f9b17da8e78ffa3d
Merge: 85d712f033d2 43049f17b526
Author: Dave Airlie <airlied@redhat.com>
Date: Fri Jun 2 13:38:48 2023 +1000
Merge tag 'drm-misc-next-2023-06-01' of git://anongit.freedesktop.org/drm/drm-misc into drm-next
Signed-off-by: Alan Previn <alan.previn.teres.alexis@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23382>
My second attempt at a minimally invasive reshuffle of the uAPI,
this time only forcibly aligning structures to 32-bits or 64-bits
depending on the members which follow, so that 64-bit userspace
is identical to the current unmerged kernel module, and the 32-bit
compat userspace aligns with that, and functions rather than
crashing.
Should work just fine with the current drm-xe-next Git tree, which
is rebased on 6.3.0-1, with a few extra changes, as of this commit.
Based on commit 2cd469458fcc24c5f345ad39721a1aedaf70ec0f ("drm/xe: Add explicit padding to uAPI definition")
Signed-off-by: Christopher Snowhill <kode54@gmail.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22652>
For testing, the conformant behavior can be enabled by setting
conformant_trunc_coord to true manually and running this to enable
the conformant behavior in hw:
umr -w *.*.regTA_CNTL2 0x40000
The layer index rounding and TRUNC_COORD resetting workarounds can disabled
in the shader compiler.
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21525>
If supported by host virglrenderer and host kernel, use userspace
allocated GPU virtual addresses. This lets us avoid stalling on
waiting for response from host kernel until we need to know the
host handle (which is usually not until submit time).
Handling the async response from host to get host_handle is done
thru the submit_queue, so that in the submit path (hot) we do not
need any additional synchronization to know that the host_handle
is valid.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16086>
Add a new backend to enable using native driver in a VM guest, via a new
virtgpu context type which (indirectly) makes host kernel interface
available in guest and handles the details of mapping buffers to guest,
etc.
Note that fence-fd's are currently a bit awkward, in that they get
signaled by the guest kernel driver (drm/virtio) once virglrenderer in
the host has processed the execbuf, not when host kernel has signaled
the submit fence. For passing buffers to the host (virtio-wl) the egl
context in virglrenderer is used to create a fence on the host side.
But use of out-fence-fd's in guest could have slightly unexpected
results. For this reason we limit all submitqueues to default priority
(so they cannot be preepmted by host egl context). AFAICT virgl and
venus have a similar problem, which will eventually be solveable once we
have RESOURCE_CREATE_SYNC.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14900>
Extends command submission ioctls to support multiple semaphores through
generic ioctl extension design. In this approach, a multisync extension
subclasses a generic ioctl extension struct (base) and enables more than
one wait and signal semaphores. Multisync extension also uses v3d_queue
to specify the wait_stage, i.e. which job should sync before start (wait
semaphores).
Signed-off-by: Melissa Wen <mwen@igalia.com>
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13178>
This change allows creating contexts of depending on set of
context parameters. The meaning of each of the parameters
is listed below:
1) VIRTGPU_CONTEXT_PARAM_CAPSET_ID
This determines the type of a context based on the capability set
ID. For example, the current capsets:
VIRTIO_GPU_CAPSET_VIRGL
VIRTIO_GPU_CAPSET_VIRGL2
define a Gallium, TGSI based "virgl" context. We only need 1 capset
ID per context type, though virgl has two due a bug that has since
been fixed.
The use case is the "gfxstream" rendering library and "venus"
renderer.
gfxstream doesn't do Gallium/TGSI translation and mostly relies on
auto-generated API streaming. Certain users prefer gfxstream over
virgl for GLES on GLES emulation. {gfxstream vk}/{venus} are also
required for Vulkan emulation.
The goal is for guest userspace to choose the optimal context type
depending on the situation/hardware.
2) VIRTGPU_CONTEXT_PARAM_NUM_RINGS
This tells the number of independent command rings that the context
will use. This value may be zero and is inferred to be zero if
VIRTGPU_CONTEXT_PARAM_NUM_RINGS is not passed in. This is backwards
compatibility for virgl, which has one big giant command ring for all
commands.
The maxiumum number of rings is 32. In practice, multi-queue or
multi-ring submission is used for powerful dGPUs and virtio-gpu
may not be the best option in that case (see PCI passthrough or
rendernode forwarding).
3) VIRTGPU_CONTEXT_PARAM_POLL_RING_IDX_MASK
This is a mask of ring indices for which the DRM fd is pollable.
For example, if VIRTGPU_CONTEXT_PARAM_NUM_RINGS is 2, then the mask
may be:
[ring idx] | [1 << ring_idx] | final mask
-------------------------------------------
0 1 1
1 2 3
The "Sommelier" guest Wayland proxy uses this to poll for events
from the host compositor.
Reviewed-by: Anthoine Bourgeois <anthoine.bourgeois@gmail.com>
Tested-by: Anthoine Bourgeois <anthoine.bourgeois@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7712>
This adds modifiers for GFX9+ AMD GPUs.
As the modifiers need a lot of parameters I split things out in
getters and setters.
- Advantage: simplifies the code a lot
- Disadvantage: Makes it harder to check that you're setting all
the required fields.
The tiling modes seem to change every generatio, but the structure
of what each tiling mode is good for stays really similar. As such
the core of the modifier is
- the tiling mode
- a version. Not explicitly a GPU generation, but splitting out
a new set of tiling equations.
Sometimes one or two tiling modes stay the same and for those we
specify a canonical version.
Then we have a bunch of parameters on how the compression works.
Different HW units have different requirements for these and we
actually have some conflicts here.
e.g. the render backends need a specific alignment but the display
unit only works with unaligned compression surfaces. To work around
that we have a DCC_RETILE option where both an aligned and unaligned
compression surface are allocated and a writer has to sync the
aligned surface to the unaligned surface on handoff.
Finally there are some GPU parameters that participate in the tiling
equations. These are constant for each GPU on the rendering/texturing
side. The display unit is very flexible however and supports all
of them :|
Some estimates:
- Single GPU, render+texture: ~10 modifiers
- All possible configs in a gen, display: ~1000 modifiers
- Configs of actually existing GPUs in a gen: ~100 modifiers
For formats with a single plane everything gets put in a separate
DRM plane. However, this doesn't fit for some YUV formats, so if
the format has >1 plane, we let the driver pack the surfaces into
1 DRM plane per format plane.
This way we avoid X11 rendering onto the frontbuffer with DCC, but
still fit into 4 DRM planes.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6176>
