Hi,
On 7 March 2016 at 20:45, Emil Velikov <emil.l.veli...@gmail.com> wrote:
> On 7 March 2016 at 10:35, Daniel Stone <dan...@fooishbar.org> wrote:
>> On 7 March 2016 at 10:19, Thierry Reding <thierry.red...@gmail.com> wrote:
>>> On Mon, Mar 07, 2016 at 10:46:52AM +0100, Lucas Stach wrote:
>>>> 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 ?
Axel pointed out privately that I worded this very badly: I don't want
_get rid of_ $DRI_PRIME and drirc overrides for the default device,
but I do want to allow apps to enumerate and select devices through
EGLDevice as an additional API. That it solves our existing (and very
real) GBM problem makes it a nice two-birds-with-one-stone approach.
GLX is pretty much a dead end here, and there's not a lot we can do
about it. But EGL/X11 is a very real thing that works today (given
that you need it for newer GL versions, I believe ... ?), and doesn't
require Glamor/GBM on the other end. So from that end, we fall into
the same solution as Wayland: the server declares the GL device it's
using for composition (through wl_drm or dri2/dri3), and it's
essentially on the client to ensure it renders in a manner compatible
with both the render device and the target. Same as GBM really. :)
>>> 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 ;-)
Indeed; as I said, the combination/wrapped approach is essentially
perfect for these systems (especially Freescale, with its mandatory 2D
blit engine), but I don't think it scales, since you require one
wrapper driver per GPU+KMS combo. Taking the approach I suggested
would allow us to solve multi-GPU with the same approach, whereas with
the wrapper driver ... who volunteers to write the Radeon+Intel
combination driver?
>> 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 ?
In that case, we should just scrap Lucas's series entirely and go back
to individual drivers which are specific to one render+scanout
combination; my suggestion was an incremental improvement on Lucas's
series, which already adds the notion of individual device
enumeration. But I don't think the one-fixed-driver approach scales at
all, especially if you think of multi-GPU in a desktop system. As the
guy who seems to deal most with the build, I thought you'd be the
least amenable towards adding however many new drivers we'd require
... ;)
>>>> 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.
It does work, but given that renderonly didn't really seem to get
anywhere, we'd need a tegra driver, a freescale driver, one driver for
every combination of {r300,r600,radeonsi}+i915 and nouveau+i915, etc.
Not to mention one for every combination of every in-tree driver plus
DisplayLink or similar. I just don't think it's viable as a long-term
solution, and given that Lucas's patches give us the infrastructure to
deal with this (current and very real) set of problems well - what's
the harm?
Cheers,
Daniel
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
