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

[Lucas Stach]

Am Dienstag, den 07.04.2015, 18:59 +0200 schrieb Christian Gmeiner:
> Hi Lucas.
[...]
> >> I don't get you naming scheme - sorry.
> >>
> >> For me one Core has a single FE. This single FE can have one pipe or
> >> multiple pipes. A pipe is the execution unit select via SELECT_PIPE
> >> command (2d, 3d, ..).
> >>
> >> In the Dove use case we have:
> >> - 1 Core with one FE
> >> - 2 pipelines
> >>
> >> In the imx6 case we have:
> >> - 3 Cores (each has only one FE)
> >> - every FE only support one type of pipeline.
> >>
> > Okay let's keep it at this: a core is an entity with a FE at the front.
> > A pipe is the backend fed by the FE selected by the SELECT_PIPE command.
> >
> > This is currently confusing as I didn't change the naming in the API,
> > but really the "pipe" parameter in the IOCTLs means core. I'll rename
> > this for the next round.
> >
> 
> The current driver was written only for the imx6 use case. So it
> combines one pipe
> of the 3 GPU cores into one device node. And yes the pipe
> parameter could be seen as core. But I think that this design is wrong. I did
> not know it better at the time I started working on it. I think that I
> would not be
> that hard to change the driver in that way that every core has its own
> device node
> and the pipe parameter really is a pipe of that core.
> 
> >> And each Core(/FE) has its own device node. Does this make any sense?
> >>
> > And I don't get why each core needs to have a single device node. IMHO
> > this is purely an implementation decision weather to have one device
> > node for all cores or one device node per core.
> >
> 
> It is an important decision. And I think that one device node per core
> reflects the
> hardware design to 100%.
> 
I'll refer to Russells mail for this.

> > For now I could only see that one device node per core makes things
> > harder to get right, while I don't see a single benefit.
> >
> 
> What makes harder to get it right? The needed changes to the kernel
> driver are not that
> hard. The user space is an other story but thats because of the
> render-only thing, where we
> need to pass (prime) buffers around and do fence syncs etc. In the end
> I do not see a
> showstopper in the user space.
> 

DMA-BUFs and fences on them are no showstopper, but are a burden on
userspace that we don't _need_ to impose. So why should we do this?

> What would you do if - I know/hope that this will never happen - there is a SoC,
> which integrates two 3d cores?
> 
Please go back and read the patch at the top of this thread. Having
multiple cores with the same pipe caps is entirely possible with the
current driver. Each core gets assigned a simple integer index and
userspace is responsible to look at the feature bits of each core/index,
so having multiple 3D cores is not a problem at all.

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