Re: Split render/display SoCs, Mesa's renderonly, and Wayland dmabuf hints
Hi,
On Mon, 19 Apr 2021 at 13:06, Simon Ser wrote:
> I'm working on a Wayland extension [1] that, among other things, allows
> compositors to advertise the preferred device to be used by Wayland
> clients.
>
> In general, compositors will send a render node. However, in the case
> of split render/display SoCs, things get a little bit complicated.
>
> [...]
>
Thanks for the write-up Simon!
> There are a few solutions:
>
> 1. Require compositors to discover the render device by trying to import
>a buffer. For each available render device, the compositor would
>allocate a buffer, export it as a DMA-BUF, import it to the
>display-only device, then try to drmModeAddFB.
>
I don't think this is actually tractable? Assuming that 'allocate a buffer'
means 'obtain a gbm_device for the render node directly and allocate a
gbm_bo from it', even with compatible formats and modifiers this will fail
for more restrictive display hardware. imx-drm and pl111 (combined with vc4
on some Raspberry Pis) will fail this, since they'll take different
allocation paths when they're bound through kmsro vs. directly, accounting
for things like contiguous allocation. So we'd get false negatives on at
least some platforms.
> 2. Allow compositors to query the render device magically opened by
>kmsro. This could be done either via EGL_EXT_device_drm, or via a
>new EGL extension.
>
This would be my strong preference, and I don't entirely understand
anholt's pushback here. The way I see it, GBM is about allocation for
scanout, and EGL is about rendering. If, on a split GPU/display system, we
create a gbm_device from a KMS display-only device node, then creating an
EGLDisplay from that magically binds us to a completely different DRM GPU
node, and anything using that EGLDisplay will use that GPU device to render.
Being able to discover the GPU device node through the device query is
really useful, because it tells us exactly what implicit magic EGL did
under the hood, and about the device that EGL will use. Being able to
discover the display node is much less useful; it does tell us how GBM will
allocate buffers, but the user already knows which device is in use because
they supplied it to GBM. I see the display node as a property of GBM, and
the GPU node as a property of EGL, even if EGL does do (*waves hands*)
stuff under the hood to ensure the two are compatible.
If we had EGL_EXT_explicit_device, things get even more weird, I think;
would the device query on an EGLDisplay created with a combination of a
gbm_device native display handle and an explicit EGLDevice handle return
the scanout device from GBM or the GPU device from EGL? On my reading, I'd
expect it to be the latter; if the queries returned very different things
based on whether GPU device selection was implicit (returning the KMS node)
or explicit (GPU node), that would definitely violate the principle of
least surprise.
> 3. Allow compositors to query the kernel drivers to know which devices
>are compatible with each other. Some uAPI to query a compatible
>display device from a render-only device, or vice-versa, has been
>suggested in the past.
>
What does 'compatible' mean? Would an Intel iGPU and and AMD dGPU be
compatible with each other? Would a Mali GPU bound to system memory through
AMBA be as compatible with the display controller as it would with an AMD
GPU on PCIE? I think a query which only exposed whether or not devices
could share dmabufs with each other is far too generic to be helpful for
the actual usecase we have, as well as not being useful enough for other
usecases ('well you _can_ use dmabufs from your AMD GPU on your Mali GPU,
but only if they were allocated in the right domain').
> (1) has a number of limitations and gotchas. It requires allocating
> real buffers, this has a rather big cost for something done at
> compositor initialization time. It requires to select a buffer format
> and modifier compatible with both devices, so it can't be isolated in
> a simple function (and e.g. shared between all compositors in libdrm).
>
We're already going to have to do throwaway allocations to make Intel's
tiled modes work; I'd rather not extend this out to doing throwaway
allocations across device combinations as well as modifier lists.
> Some drivers will allow to drmModeAddFB buffers that can't be scanned
> out, and will only reject the buffer at atomic commit time.
>
This is 100% a KMS driver bug and should be fixed there. It's not
catastrophic, since commits can fail for any reason or none at all and
compositors are expected to handle this, but they should absolutely be
rejecting buffers which can never be scanned out at all at AddFB time.
> (2) wouldn't work with non-EGL APIs such as Vulkan. Eric Anholt seemed
> pretty opposed to this idea, but I didn't fully understood why.
>
Well, Vulkan doesn't have GBM in the same way, right? In the Vulkan case,
we already know exactly what the GPU is, because it's th
Re: Split render/display SoCs, Mesa's renderonly, and Wayland dmabuf hints
Just 2 comments on the kernel aspects here.
On Tue, Apr 20, 2021 at 12:18 PM Daniel Stone wrote:
>
> Hi,
>
> On Mon, 19 Apr 2021 at 13:06, Simon Ser wrote:
>>
>> I'm working on a Wayland extension [1] that, among other things, allows
>> compositors to advertise the preferred device to be used by Wayland
>> clients.
>>
>> In general, compositors will send a render node. However, in the case
>> of split render/display SoCs, things get a little bit complicated.
>>
>> [...]
>
>
> Thanks for the write-up Simon!
>
>>
>> There are a few solutions:
>>
>> 1. Require compositors to discover the render device by trying to import
>>a buffer. For each available render device, the compositor would
>>allocate a buffer, export it as a DMA-BUF, import it to the
>>display-only device, then try to drmModeAddFB.
>
>
> I don't think this is actually tractable? Assuming that 'allocate a buffer'
> means 'obtain a gbm_device for the render node directly and allocate a gbm_bo
> from it', even with compatible formats and modifiers this will fail for more
> restrictive display hardware. imx-drm and pl111 (combined with vc4 on some
> Raspberry Pis) will fail this, since they'll take different allocation paths
> when they're bound through kmsro vs. directly, accounting for things like
> contiguous allocation. So we'd get false negatives on at least some platforms.
>
>>
>> 2. Allow compositors to query the render device magically opened by
>>kmsro. This could be done either via EGL_EXT_device_drm, or via a
>>new EGL extension.
>
>
> This would be my strong preference, and I don't entirely understand anholt's
> pushback here. The way I see it, GBM is about allocation for scanout, and EGL
> is about rendering. If, on a split GPU/display system, we create a gbm_device
> from a KMS display-only device node, then creating an EGLDisplay from that
> magically binds us to a completely different DRM GPU node, and anything using
> that EGLDisplay will use that GPU device to render.
>
> Being able to discover the GPU device node through the device query is really
> useful, because it tells us exactly what implicit magic EGL did under the
> hood, and about the device that EGL will use. Being able to discover the
> display node is much less useful; it does tell us how GBM will allocate
> buffers, but the user already knows which device is in use because they
> supplied it to GBM. I see the display node as a property of GBM, and the GPU
> node as a property of EGL, even if EGL does do (*waves hands*) stuff under
> the hood to ensure the two are compatible.
>
> If we had EGL_EXT_explicit_device, things get even more weird, I think; would
> the device query on an EGLDisplay created with a combination of a gbm_device
> native display handle and an explicit EGLDevice handle return the scanout
> device from GBM or the GPU device from EGL? On my reading, I'd expect it to
> be the latter; if the queries returned very different things based on whether
> GPU device selection was implicit (returning the KMS node) or explicit (GPU
> node), that would definitely violate the principle of least surprise.
>
>>
>> 3. Allow compositors to query the kernel drivers to know which devices
>>are compatible with each other. Some uAPI to query a compatible
>>display device from a render-only device, or vice-versa, has been
>>suggested in the past.
>
>
> What does 'compatible' mean? Would an Intel iGPU and and AMD dGPU be
> compatible with each other? Would a Mali GPU bound to system memory through
> AMBA be as compatible with the display controller as it would with an AMD GPU
> on PCIE? I think a query which only exposed whether or not devices could
> share dmabufs with each other is far too generic to be helpful for the actual
> usecase we have, as well as not being useful enough for other usecases ('well
> you _can_ use dmabufs from your AMD GPU on your Mali GPU, but only if they
> were allocated in the right domain').
>
>>
>> (1) has a number of limitations and gotchas. It requires allocating
>> real buffers, this has a rather big cost for something done at
>> compositor initialization time. It requires to select a buffer format
>> and modifier compatible with both devices, so it can't be isolated in
>> a simple function (and e.g. shared between all compositors in libdrm).
>
>
> We're already going to have to do throwaway allocations to make Intel's tiled
> modes work; I'd rather not extend this out to doing throwaway allocations
> across device combinations as well as modifier lists.
>
>>
>> Some drivers will allow to drmModeAddFB buffers that can't be scanned
>> out, and will only reject the buffer at atomic commit time.
>
>
> This is 100% a KMS driver bug and should be fixed there. It's not
> catastrophic, since commits can fail for any reason or none at all and
> compositors are expected to handle this, but they should absolutely be
> rejecting buffers which can never be scanned out at all at Add
Re: Drag & Drop - multiple wl_data_device/wl_seat interfaces
Hi, On Tuesday, April 20th, 2021 at 2:51 PM, Martin Stransky wrote: > with Drag & Drop sometimes only one device gets the D&D events This sounds like a compositor bug. The events should be broadcast to all objects of the client that has focus for the wl_seat I think. Simon ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Split render/display SoCs, Mesa's renderonly, and Wayland dmabuf hints
On Tue, Apr 20, 2021 at 3:18 AM Daniel Stone wrote: > > Hi, > > On Mon, 19 Apr 2021 at 13:06, Simon Ser wrote: >> >> I'm working on a Wayland extension [1] that, among other things, allows >> compositors to advertise the preferred device to be used by Wayland >> clients. >> >> In general, compositors will send a render node. However, in the case >> of split render/display SoCs, things get a little bit complicated. >> >> [...] > > > Thanks for the write-up Simon! > >> >> There are a few solutions: >> >> 1. Require compositors to discover the render device by trying to import >>a buffer. For each available render device, the compositor would >>allocate a buffer, export it as a DMA-BUF, import it to the >>display-only device, then try to drmModeAddFB. > > > I don't think this is actually tractable? Assuming that 'allocate a buffer' > means 'obtain a gbm_device for the render node directly and allocate a gbm_bo > from it', even with compatible formats and modifiers this will fail for more > restrictive display hardware. imx-drm and pl111 (combined with vc4 on some > Raspberry Pis) will fail this, since they'll take different allocation paths > when they're bound through kmsro vs. directly, accounting for things like > contiguous allocation. So we'd get false negatives on at least some platforms. > >> >> 2. Allow compositors to query the render device magically opened by >>kmsro. This could be done either via EGL_EXT_device_drm, or via a >>new EGL extension. > > > This would be my strong preference, and I don't entirely understand anholt's > pushback here. The way I see it, GBM is about allocation for scanout, and EGL > is about rendering. If, on a split GPU/display system, we create a gbm_device > from a KMS display-only device node, then creating an EGLDisplay from that > magically binds us to a completely different DRM GPU node, and anything using > that EGLDisplay will use that GPU device to render. > > Being able to discover the GPU device node through the device query is really > useful, because it tells us exactly what implicit magic EGL did under the > hood, and about the device that EGL will use. Being able to discover the > display node is much less useful; it does tell us how GBM will allocate > buffers, but the user already knows which device is in use because they > supplied it to GBM. I see the display node as a property of GBM, and the GPU > node as a property of EGL, even if EGL does do (*waves hands*) stuff under > the hood to ensure the two are compatible. I guess if we're assuming that the caller definitely knows about the display device and is asking EGL for the render node in order to do smarter buffer sharing between display and render, I can see it. My objection was that getting the render node in that discussion was apparently some workaround for other brokenness, and was going to result in software that didn't work on pl111 and vc4 displays because it was trying to dodge kmsro. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
