[PATCH RFC 102/111] staging: etnaviv: separate GPU pipes from execution state

[Lucas Stach]

Am Dienstag, den 07.04.2015, 10:03 +0200 schrieb Christian Gmeiner:
> Hi Lucas
> 
> 2015-04-07 9:46 GMT+02:00 Lucas Stach <l.stach at pengutronix.de>:
> > Am Sonntag, den 05.04.2015, 21:41 +0200 schrieb Christian Gmeiner:
> >> 2015-04-02 18:37 GMT+02:00 Russell King - ARM Linux <linux at arm.linux.org.uk>:
> >> > On Thu, Apr 02, 2015 at 05:30:44PM +0200, Lucas Stach wrote:
> >> >> While this isn't the case on i.MX6 a single GPU pipe can have
> >> >> multiple rendering backend states, which can be selected by the
> >> >> pipe switch command, so there is no strict mapping between the
> >> >> user "pipes" and the PIPE_2D/PIPE_3D execution states.
> >> >
> >> > This is good, because on Dove we have a single Vivante core which
> >> > supports both 2D and 3D together.  It's always bugged me that
> >> > etnadrm has not treated cores separately from their capabilities.
> >> >
> >>
> >> Today I finally got the idea how this multiple pipe stuff should be
> >> done the right way - thanks Russell.
> >> So maybe you/we need to rework how the driver is designed regarding
> >> cores and pipes.
> >>
> >> On the imx6 we should get 3 device nodes each only supporting one pipe
> >> type. On the dove we
> >> should get only one device node supporting 2 pipes types. What do you think?
> >>
> > Sorry, but I strongly object against the idea of having multiple DRM
> > device nodes for the different pipes.
> >
> 
> But that would expose the way the hardware is designed.
> 
A single DRM device is equally capable of exposing the cores as separate
entities. I don't see why we should make our lives harder just to have
userspace deal with multiple DRM nodes.

> > If we need the GPU2D and GPU3D to work together (and I can already see
> > use-cases where we need to use the GPU2D in MESA to do things the GPU3D
> > is incapable of) we would then need a lot more DMA-BUFs to get buffers
> > across the devices. This is a waste of resources and complicates things
> > a lot as we would then have to deal with DMA-BUF fences just to get the
> > synchronization right, which is a no-brainer if we are on the same DRM
> > device.
> >
> 
> Welcome to the wonderful world of render-only GPUs.
> 
I object to making things complex for the sake of making things hard. ;)

> > Also it does not allow us to make any simplifications to the userspace
> > API, so I can't really see any benefit.
> >
> 
> About what simplifications are you taking?
> 
There are none. Every bit in the API is still needed, even if we expose
the cores as separate DRM devices.

> > Also on Dove I think one would expect to get a single pipe capable of
> > executing in both 2D and 3D state. If userspace takes advantage of that
> > one could leave the sync between both engines to the FE, which is a good
> > thing as this allows the kernel to do less work. I don't see why we
> > should throw this away.
> >
> 
> That is what I am talking of. On Dove we have one core which has a 2d
> and a 3d pipe.
> On the imx6 we would have up to 3 cores (2d, 3d, vg) with only one pipe.
> 
> --> Dove: 1 drm device node with 2 pipes
> --> imx6: up to 3 drm devices nodes, where each only has one supported pipe.
> 
> So the user space opens the device, checks if the wanted pipe is supported and
> creates a pipe representation where the user space can work with. As the kernel
> has already the pipe concept it should work without to much refactoring.
> 
> Also how should the user space read out supported features in the case
> of Dove? Currently
> the driver is focused on the architecture of the imx6 (which is my fault).
> 
The naming may not be perfect yet, but the same thing is already
possible with the driver as posted. The "pipe" argument in the ioctls is
not the execution state anymore. That is what I think you mean when you
talk about 2d, 3d, vg pipe.

A pipe is now simply a channel to a single GPU core. If a given core is
able to execute 2d, 3d or vg state is a matter of looking at the feature
bits for this pipe. Why would we need a full blown DRM device for that?
On i.MX6 you have 3 pipes where each of them is capable of executing in
exactly one exec state. On Dove you get a single pipe that is able to
switch between 2D and 3D exec state. If userspace is aware of that one
could even interleave 2D with 3D execution on a single submit.

Regards,
Lucas

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