[Mesa-dev] [RFC 1/2] gallium: add renderonly driver

[Lucas Stach]

Hi Christian,

Am Sonntag, den 18.10.2015, 21:41 +0200 schrieb Christian Gmeiner:
> Hi Thierry,
> 
> Thanks for reviewing this patches.
> 
> 2015-10-16 15:31 GMT+02:00 Thierry Reding <thierry.reding at gmail.com>:
> > Hi Christian,
> >
> > First off, thanks for reviving this effort. It's been one of the things
> > that I've had nagging at me for much too long and I think it needs to be
> > solved. So I'm hopeful that the more people we get looking at this the
> > more likely it will be to come up with a solution that works well for
> > everyone.
> >
> 
> Yeah
> 
> > That said, I don't agree with the approach you've chosen here. I'll try
> > to clarify why below.
> >
> > On Sun, Oct 11, 2015 at 05:09:21PM +0200, Christian Gmeiner wrote:
> >> This commit adds a generic renderonly driver library, which fullfille
> >> the requirements for tegra and etnaviv. As a result it is possible to
> >> run unmodified egl software directly (without any compositor) on
> >> supported devices.
> >
> > Technically this isn't a library but rather a midlayer. There's a subtle
> > difference, but the implications are what concerns me.
> >
> 
> Yes the term midlayer fits better.
> 
> > Back when I wrote the original driver for Tegra/Nouveau I also looked
> > into possibilities to make this more generic. Since I know how bad mid-
> > layers can be (from kernel experience) I shied away from something like
> > this early on. What I tried to do next was abstract away enough to make
> > this usable by more than just a single driver. Unfortunately the end
> > result was that not much could be reused, so drivers ended up still
> > having to implement all of the pipe_* objects, only to call generic
> > functions. Most of the code needed in the various callbacks ended up not
> > being much more than just a single line, so the gains from a helper
> > library weren't very big.
> >
> 
> If I am not completely wrong ddebug and trace gallium drivers are using the
> same concept. We can create a chain of gallium drivers, where every
> component can do special stuff and call or call not the next drivers function
> in the chain.
> 
> > Another reason why I think this level of abstraction doesn't gain us
> > much is that we already have a good level of abstraction, which is
> > Gallium. I realize that implementing only the skeleton for a full
> 
> Do you see other ways then the midlayer approach to support renderonly
> gpus better? A more tight integration into Gallium?
> 
> > Gallium driver is rather complicated, but that's due to the fact that
> > graphics drivers are complex beasts.
> >
> > That said, I think for some areas it might be beneficial to have helpers
> > to reduce the amount of duplication. However I think at this point in
> > time we haven't had enough real-world exposure for this kind of driver
> > to know what the requirements are. For that reason I think it is
> > premature to use a generic midlayer such as this. Yes, I know that the
> > alternative is roughly 2000 lines of code per driver, but on one hand
> > that's nothing compared to the amount of code required by a proper GPU
> > driver and on the other hand this will (ideally) be temporary until we
> > get a better picture of where things need to go. At which point it may
> > become more obvious how we can solve the boilerplate problem while at
> > the same time avoiding the restrictions imposed by the midlayer.
> >
> 
> For the moment I have no problem to go that way, but I am not sure how long
> we should wait to collect the needed requirements. Do you know of any other
> renderonly gpu coming in the near future (with opensource drivers)?
> 
> I am really no expert in this area but the most interesting part for a
> renderonly
> GPU midlayer is "how to display the rendering result?".
> So we need to support different tiling formats and if a intermediate buffer is
> needed (for IP combination where GPU or scanout format are not compatible).
> 
> For etnaviv we need to support all this cases (with the GC2000+ coming the next
> months we can render into the scanout buffer directly - same as tegra).
> 
> I know that it is quite hard to design a good api/midlayer/whatever to be future
> proof for the next 1-2 years without (bigger) refactoring work. But at
> some point
> we need to jump into the cold water, start to design it and make use of it.
> I am open to any discussion about software architecture and requirements.

The problems I see with this series are not technical/implementation
issues, but IMHO this whole device fusing is wrong from an architectural
point of view.

This series implements a way to fuse multiple DRM devices into a single
EGL device, solely on the base that current EGL users expect that a
single device is able to render and scanout at the same time. This is a
flawed premise on itself and this series actively tries to keep the
illusion that this is true, even for SoC and prime systems. While doing
so it is putting a lot device specific knowledge into the implementation
of the midlayer/helpers.

IMHO we should not try to keep that illusion, but work out a way for
client applications to deal with the situation of having multiple
scanout/render devices in a easy way.

I mean having render/scanout on different devices isn't exactly news, in
fact we already have to deal with that for the various prime laptops.
Currently all the complexity of those setups is hidden in the X server,
but that one will go away and we have to find a way to make it easy for
the various wayland compositors to deal with that.

My current proposal would be as follows:

1. Implement etnaviv/nouveau on tegra as EGL devices that are only able
to render into offscreen surfaces.

2. Implement an easy way for compositors to discover EGL devices and
their capabilities. (There are already patches for EGL device and
related stuff on the ML)

3. Implement a generic KMS EGL device that is only able to prove
scanout. Have EGL_EXT_stream_consumer_egloutput [1] working on top of
that.

4. Implement EGL_KHR_stream_producer_eglsurface for the render only EGL
devices.

Details of the hardware like the need to detile the render buffer can be
negotiated as part of the EGL stream handshaking.

This will give a generic compositor an easy way to deal with the
situation of multiple render/scanout devices without the need to know
about hardware details. I know that this isn't the easy way to go, but
it solves the problem in a generic way and we don't run into the same
problem again once someone attaches a discreet GPU to one of those SoCs.

I would like to hear what others are thinking about that.

[...]
> > I know that this is a copy of what I had in my original proposal, but I
> > fully admit that it wasn't much more than a proof of concept with quite
> > a few rough edges to work out.
> >
> 
> Mine is also more like a proof-of-concept but I want to get it merged
> in some form :)
> 
I fear that getting a solution merged that gets us the half way, nobody
will bother to do it more generically after that.

Regards,
Lucas

[1]
https://www.khronos.org/registry/egl/extensions/EXT/EGL_EXT_stream_consumer_egloutput.txt

[2]
https://www.khronos.org/registry/egl/extensions/KHR/EGL_KHR_stream_producer_eglsurface.txt




-- 
Pengutronix e.K.             | Lucas Stach                 |
Industrial Linux Solutions   | http://www.pengutronix.de/  |