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

Tue Mar 8 12:49:15 UTC 2016

2016-03-08 12:36 GMT+01:00 Daniel Stone <daniel at fooishbar.org>:
> Hi,
>
> On 7 March 2016 at 20:45, Emil Velikov <emil.l.velikov at gmail.com> wrote:
>> On 7 March 2016 at 10:35, Daniel Stone <daniel at fooishbar.org> wrote:
>>> 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:
>>>>> 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

The 'good' is that the specific kms driver is quite short and easy to maintain.
The whole magic lies in the corresponding winsys - e.g.
src/gallium/winsys/tegra/drm/tegra_drm_winsys.c:

static int tegra_tiling(int fd, uint32_t handle)
{
  struct drm_tegra_gem_set_tiling args;

  memset(&args, 0, sizeof(args));
  args.handle = handle;
  args.mode = DRM_TEGRA_GEM_TILING_MODE_BLOCK;
  args.value = 4;

  return drmIoctl(fd, DRM_IOCTL_TEGRA_GEM_SET_TILING, &args);
}

static const struct renderonly_ops ro_ops = {
  .open = nouveau_drm_screen_create,
  .tiling = tegra_tiling,
};

struct pipe_screen *tegra_drm_screen_create(int fd)
{
  return renderonly_screen_create(fd, &ro_ops);
}

So it boils down to write a driver for every supported kms device. This would
make it easy to support different kms IP core block version with different
features. kms IP core v1: does need intermediate flush and v2: does not.

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

Not me :)

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

Correct.. renderonly was written to full fill the one-scanout-one-renderonly GPU
thing.

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

It is/was a good thing to get something working. Without it it would be
quite hard to do some real development on those drivers.

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

In the end I like the idea from Daniel I only wish that it is not
needed to modify
existing SW to be able to use the device enumeration approach as this would
be a real blocker (at least for me).

I really hope to see the one-and-only solution lading this year in mesa.

Greets
--
Christian Gmeiner, MSc

https://soundcloud.com/christian-gmeiner