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

[Daniel Stone]

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.

>> 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 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.

>> 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.

Cheers,
Daniel