<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Apr 7, 2015 at 5:01 PM, Lucas Stach <span dir="ltr"><<a href="mailto:l.stach@pengutronix.de" target="_blank">l.stach@pengutronix.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">Am Dienstag, den 07.04.2015, 16:51 +0200 schrieb Jon Nettleton:<br>
><br>
><br>
> On Tue, Apr 7, 2015 at 4:38 PM, Alex Deucher <<a href="mailto:alexdeucher@gmail.com">alexdeucher@gmail.com</a>><br>
> wrote:<br>
>         On Tue, Apr 7, 2015 at 3:46 AM, Lucas Stach<br>
>         <<a href="mailto:l.stach@pengutronix.de">l.stach@pengutronix.de</a>> wrote:<br>
>         > Am Sonntag, den 05.04.2015, 21:41 +0200 schrieb Christian<br>
>         Gmeiner:<br>
>         >> 2015-04-02 18:37 GMT+02:00 Russell King - ARM Linux<br>
>         <<a href="mailto:linux@arm.linux.org.uk">linux@arm.linux.org.uk</a>>:<br>
>         >> > On Thu, Apr 02, 2015 at 05:30:44PM +0200, Lucas Stach<br>
>         wrote:<br>
>         >> >> While this isn't the case on i.MX6 a single GPU pipe can<br>
>         have<br>
>         >> >> multiple rendering backend states, which can be selected<br>
>         by the<br>
>         >> >> pipe switch command, so there is no strict mapping<br>
>         between the<br>
>         >> >> user "pipes" and the PIPE_2D/PIPE_3D execution states.<br>
>         >> ><br>
>         >> > This is good, because on Dove we have a single Vivante<br>
>         core which<br>
>         >> > supports both 2D and 3D together.  It's always bugged me<br>
>         that<br>
>         >> > etnadrm has not treated cores separately from their<br>
>         capabilities.<br>
>         >> ><br>
>         >><br>
>         >> Today I finally got the idea how this multiple pipe stuff<br>
>         should be<br>
>         >> done the right way - thanks Russell.<br>
>         >> So maybe you/we need to rework how the driver is designed<br>
>         regarding<br>
>         >> cores and pipes.<br>
>         >><br>
>         >> On the imx6 we should get 3 device nodes each only<br>
>         supporting one pipe<br>
>         >> type. On the dove we<br>
>         >> should get only one device node supporting 2 pipes types.<br>
>         What do you think?<br>
>         >><br>
>         > Sorry, but I strongly object against the idea of having<br>
>         multiple DRM<br>
>         > device nodes for the different pipes.<br>
>         ><br>
>         > If we need the GPU2D and GPU3D to work together (and I can<br>
>         already see<br>
>         > use-cases where we need to use the GPU2D in MESA to do<br>
>         things the GPU3D<br>
>         > is incapable of) we would then need a lot more DMA-BUFs to<br>
>         get buffers<br>
>         > across the devices. This is a waste of resources and<br>
>         complicates things<br>
>         > a lot as we would then have to deal with DMA-BUF fences just<br>
>         to get the<br>
>         > synchronization right, which is a no-brainer if we are on<br>
>         the same DRM<br>
>         > device.<br>
>         ><br>
>         > Also it does not allow us to make any simplifications to the<br>
>         userspace<br>
>         > API, so I can't really see any benefit.<br>
>         ><br>
>         > Also on Dove I think one would expect to get a single pipe<br>
>         capable of<br>
>         > executing in both 2D and 3D state. If userspace takes<br>
>         advantage of that<br>
>         > one could leave the sync between both engines to the FE,<br>
>         which is a good<br>
>         > thing as this allows the kernel to do less work. I don't see<br>
>         why we<br>
>         > should throw this away.<br>
><br>
>         Just about all modern GPUs support varying combinations of<br>
>         independent<br>
>         pipelines and we currently support this just fine via a single<br>
>         device<br>
>         node in other drm drivers.  E.g., modern radeons support one<br>
>         or more<br>
>         gfx, compute, dma, video decode and video encode engines.<br>
>         What<br>
>         combination is present depends on the asic.<br>
><br>
><br>
><br>
><br>
> That reminds me.  We should also have in the back of our heads that<br>
> compute is supported by the newer Vivante chips.  We will also need to<br>
> support multiple independent 3d cores as that support has shown up in<br>
> the V5 galcore drivers.<br>
><br>
</div></div>AFAIK compute is just another state of the 3D pipe where instead of<br>
issuing a draw command you would kick the thread walker.<br></blockquote><div><br></div><div>I believe this is true, but I don't believe anyone has RE'd anything yet.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Multicore with a single FE is just a single pipe with chip selects set<br>
to the available backends and mirrored pagetables for the MMUs. With<br>
more than one FE you get more than one pipe which is more like a SLI<br>
setup on the desktop, where userspace has to deal with splitting the<br>
render targets into portions for each GPU.</blockquote><div><br></div><div>Yes, the galcore makes this a configuration option at build time supporting both configs.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
One more reason to keep things in one DRM device, as I think no one<br>
wants to deal with syncing pagetables across different devices.<br>
<div class="HOEnZb"><div class="h5"><br>
Regards,<br>
Lucas<br>
<br>
--<br>
Pengutronix e.K.             | Lucas Stach                 |<br>
Industrial Linux Solutions   | <a href="http://www.pengutronix.de/" target="_blank">http://www.pengutronix.de/</a>  |<br>
<br>
</div></div></blockquote></div><br></div></div>