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>
