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

[Lucas Stach]

Am Dienstag, den 07.04.2015, 12:31 +0100 schrieb Russell King - ARM
Linux:
> On Tue, Apr 07, 2015 at 11:05:50AM +0200, Lucas Stach wrote:
> > 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.
> 
> This is another issue which needs nailing down and clearly specified. :)
> 
> In the case of a GPU with multiple execution states, are you intending
> each command buffer submitted should ensure that the appropriate
> execution state is selected (via a SET PIPE command) or are you
> intending the kernel to know about this?
> 
Currently the kernel makes sure that the pipe is in the expected
execution state for each submit if the GPU has been dirtied by anything
other than the current submitting process.

As the pipe switch is a somewhat heavy command I'm not sure if we really
like userspace to prepend it on each submit. On the other hand we also
expect userspace to flush caches on each submit to be able to safely
flush the MMU, so the pipe switch might turn out the be harmless in
contrast.

I agree that there is currently a lack of documentation for those
things.

Regards,
Lucas

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