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

[Jon Nettleton]

On Tue, Apr 7, 2015 at 5:01 PM, Lucas Stach <l.stach at pengutronix.de> wrote:

> Am Dienstag, den 07.04.2015, 16:51 +0200 schrieb Jon Nettleton:
> >
> >
> > On Tue, Apr 7, 2015 at 4:38 PM, Alex Deucher <alexdeucher at gmail.com>
> > wrote:
> >         On Tue, Apr 7, 2015 at 3:46 AM, Lucas Stach
> >         <l.stach at pengutronix.de> wrote:
> >         > 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.
> >         >
> >         > 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.
> >         >
> >         > Also it does not allow us to make any simplifications to the
> >         userspace
> >         > API, so I can't really see any benefit.
> >         >
> >         > 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.
> >
> >         Just about all modern GPUs support varying combinations of
> >         independent
> >         pipelines and we currently support this just fine via a single
> >         device
> >         node in other drm drivers.  E.g., modern radeons support one
> >         or more
> >         gfx, compute, dma, video decode and video encode engines.
> >         What
> >         combination is present depends on the asic.
> >
> >
> >
> >
> > That reminds me.  We should also have in the back of our heads that
> > compute is supported by the newer Vivante chips.  We will also need to
> > support multiple independent 3d cores as that support has shown up in
> > the V5 galcore drivers.
> >
> AFAIK compute is just another state of the 3D pipe where instead of
> issuing a draw command you would kick the thread walker.
>

I believe this is true, but I don't believe anyone has RE'd anything yet.


>
> Multicore with a single FE is just a single pipe with chip selects set
> to the available backends and mirrored pagetables for the MMUs. With
> more than one FE you get more than one pipe which is more like a SLI
> setup on the desktop, where userspace has to deal with splitting the
> render targets into portions for each GPU.


Yes, the galcore makes this a configuration option at build time supporting
both configs.


> One more reason to keep things in one DRM device, as I think no one
> wants to deal with syncing pagetables across different devices.
>
> Regards,
> Lucas
>
> --
> Pengutronix e.K.             | Lucas Stach                 |
> Industrial Linux Solutions   | http://www.pengutronix.de/  |
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150407/2d286a01/attachment.html>