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

[Emil Velikov]

Hello Dan,

On 14 March 2016 at 16:02, Daniel Stone <daniel at fooishbar.org> wrote:
> Hey Emil,
>
> On 8 March 2016 at 17:04, Emil Velikov <emil.l.velikov at gmail.com> wrote:
>> Summarising and stating some unsaid assumptions.
>>
>> Assumptions:
>>  - The proposed solution is a replacement of the wrapped drivers
>> approach. No, it's meant to introduce an API mostly gears towards
>> DRI_PRIME setups.
>>  - Wrapped drivers will/could/should be done outside the SoC world
>> (i.e. with DRI_PRIME). No, that was never the case.
>>
>> To sum it all up, I believe most/all of us think that tightly coupled
>> devices (such as SoC) should be a wrapped driver. For the rest, an API
>> providing explicit control to the programmer, based on EGLDevice,
>> sounds like a good approach.
>
> My point is mostly that the capabilities needed are very similar, and
> sometimes those lines get very blurred, especially when you look at
> Rockchip display controllers having all of Mali/IMG/Intel GPUs
> attached, that you can attach a DisplayLink or similar controller to
> any GPU at all, etc. At that point it really does just turn into the
> same problem, rather than two similar problems.
>
I'm afraid I don't see how a vast permutation of SoC designs can be
considered the same as separate, distinct, devices such as the
DRI_PRIME managed and/or DisplayLink ones. The only 'issue' that I can
foresee is when (if) we get code for multiple render GPU paired with
the same display controller.

Can you please elaborate how they turn into a single problem ? I'm
afraid I'm short of your diversity when dealing with these
devices/vendors.

-Emil

'The issue' being that we'll either need to fix/enhance our dri
selection/loader logic (which sucks atm) for platform devices to allow
dc_tegra_render_intel_dri.so and alike backends. Otherwise we'll end
up with a bloated binary. Then again we can control it [the bloat] at
configure time.