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. And each Core(/FE) has its own device node. Does this make any sense? greets -- Christian Gmeiner, MSc https://soundcloud.com/christian-gmeiner _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
