Am Dienstag, den 07.04.2015, 17:13 +0200 schrieb Christian Gmeiner: > 2015-04-07 17:01 GMT+02:00 Lucas Stach <l.stach@xxxxxxxxxxxxxx>: > > Am Dienstag, den 07.04.2015, 16:51 +0200 schrieb Jon Nettleton: > >> > >> > >> On Tue, Apr 7, 2015 at 4:38 PM, Alex Deucher <alexdeucher@xxxxxxxxx> > >> wrote: > >> On Tue, Apr 7, 2015 at 3:46 AM, Lucas Stach > >> <l.stach@xxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxx>: > >> >> > 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. > > > > 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. > > One more reason to keep things in one DRM device, as I think no one > > wants to deal with syncing pagetables across different devices. > > > > 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. > 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. 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. Regards, Lucas -- Pengutronix e.K. | Lucas Stach | Industrial Linux Solutions | http://www.pengutronix.de/ | _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
