[Mesa-dev] [PATCH RFC 0/2] GBM API extension to support fusing KMS and render devices

[Emil Velikov]

On 7 March 2016 at 10:35, Daniel Stone <daniel at fooishbar.org> wrote:
> Hi,
>
> On 7 March 2016 at 10:19, Thierry Reding <thierry.reding at gmail.com> wrote:
>> On Mon, Mar 07, 2016 at 10:46:52AM +0100, Lucas Stach wrote:
>>> Am Freitag, den 04.03.2016, 18:34 +0000 schrieb Emil Velikov:
>>> > While I'm more inclined to Daniel's suggestion, I wonder why people
>>> > moved away from Thierry's approach - creating a composite/wrapped dri
>>> > module ? Is there anything wrong with it - be that from technical or
>>> > conceptual POV ?
>>> >
>>> The wrapped driver takes away the ability of the application to decide
>>> which GPUs to bind together - at least if you want to keep things
>>> tightly coupled at that level.
>>
>> That was actually the prime objective of the patches I posted back at
>> the time. =)
>
> Which, for the single-GPU/single-scanout case, is perfect. But it's
> completely backwards for the multi-GPU case, and they _are_ the exact
> same problem, so I'd rather not encourage separate solutions for both.
> I really, really, really want to get rid of $DRI_PRIME.
>
Nuking DRI_PRIME and straightening things out is a very worthy goal
imho. Although... how are these two new approaches likely to work with
X11. Afaics there is no GBM/EGL in xserver, outside of glamor that is.
Even if we add the bits, how are thing going to work in GLX ?

>>> The point of the explicit application control is that we not only solve
>>> the "SoCs have split render/scanout devices" issue, but gain an API for
>>> compositors to work properly on PRIME laptop configurations with
>>> render/render/scanout. We don't want any autodetection to happen there,
>>> a compositor may well decide to use the Intel GPU as scanout only and do
>>> all composition on the discreet GPU. Having a tightly coupled wrapped
>>> driver for every device combination is not really where we want to go,
>>> right?
>>
>> To be honest, I don't think we have much of a choice. Most bare-metal
>> applications don't make a distinction between render and scanout. They
>> will simply assume that you can do both on the same device, because
>> that's what their development machine happens to have. So unless we
>> make a deliberate decision not to support most applications out there,
>> what other options do we have?
>>
>> While I agree it's good to have an API to allow explicit control over
>> association of render to scanout nodes, I think that we really want
>> both. In addition to giving users the flexibility if they request it,
>> I think we want to give them a sensible default if they don't care.
>>
>> Especially on systems where there usually isn't a reason to care. Most
>> modern SoCs would never want explicit control over the association
>> because there usually is only a single render node and a single scanout
>> node in the system.
>
> I don't think anyone's arguing otherwise! If there's only one scanout
> node, then the application cannot possibly discover any other DRM
> device to give to GBM. If there's only one render node, then the EGL
> implementation cannot possibly discover anything with EGLDevice. And
> there'll always have to be a default render node selection for apps
> who don't use EGLDevice (currently all of them), so, no problem.
>
I believe that the series is inspired by device(s) where both parts of
the GPU/SoC are closely coupled. Even if I recall correctly, the
display engine cannot scanout from the tiled format, and the GPU
should be used prior to that. This information can be communicated
easier via the wrapped approach, otherwise we will need an API to pass
it through the layers. Which in itself is a great although I'd imagine
we won't get it right the first (X?) time(s). Meanwhile the original
approach will just work ;-)

> I think the only disagreement is how to implement the API internally.
> Lucas is heading in a more generic direction, whereas the
> wrapper-driver approach requires you to write one driver for literally
> every possible combination of render/scanout. Again, fine for
> platforms like Tegra and i.MX where there will only ever be one
> combination ever, but it doesn't scale.
>
Indeed there would be some duplication/boilerplate. The render-only
idea by Christian Gmeiner mitigates it. I believe Thierry was unhappy
with it, due to the possible permutation as new users come along.

Personally, I would use it for now, and worry/re-design thing as we
get (m)any other users. No offence but it seems like we're trying to
tackle a problem which does not exist, yet ?

>>> As said above: if you you want to bind arbitrary combinations of drivers
>>> together you need to move away from tight coupling to a shared interface
>>> anyway. I don't see how having this interface inside a wrapped driver
>>> instead of GBM help in any way, it's a MESA internal interface anyways.
>>>
>>> We don't need any of this for GLX. Etnaviv is working fine with GLX on
>>> both imx-drm and armada-drm, as the DDX does all the work when binding
>>> devices together in that case.
>>
>> In this case DDX will take the role of the wrapped driver. So you'd end
>> up with duplication of the "glue" in both Mesa and the DDX, don't you?
>
> The DDX doesn't exist outside X11, thankfully.
>
Indeed. Shame that not everyone is on the wayland/mir boat yet. We're
getting close though :-)

At the end of the day: the idea is that wrapped driver works now
(modulo bugs) with any user space. As we get the explicit control
interface in place (mesa and users) we'll still be able to reuse those
drivers and we can migrate smoothly.

Thanks
Emil