From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jon Nettleton Subject: Re: [PATCH RFC 102/111] staging: etnaviv: separate GPU pipes from execution state Date: Tue, 7 Apr 2015 16:51:12 +0200 Message-ID: References: <1427988653-754-1-git-send-email-l.stach@pengutronix.de> <1427988653-754-103-git-send-email-l.stach@pengutronix.de> <20150402163706.GT24899@n2100.arm.linux.org.uk> <1428392775.2811.22.camel@pengutronix.de> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1989293196==" Return-path: Received: from mail-wi0-f171.google.com (mail-wi0-f171.google.com [209.85.212.171]) by gabe.freedesktop.org (Postfix) with ESMTP id 8A6E56E582 for ; Tue, 7 Apr 2015 07:51:13 -0700 (PDT) Received: by widjs5 with SMTP id js5so12530146wid.1 for ; Tue, 07 Apr 2015 07:51:12 -0700 (PDT) In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: Alex Deucher Cc: Russell King - ARM Linux , DRI mailing list , Sascha Hauer List-Id: dri-devel@lists.freedesktop.org --===============1989293196== Content-Type: multipart/alternative; boundary=f46d043c7f24bd6c510513238b6e --f46d043c7f24bd6c510513238b6e Content-Type: text/plain; charset=UTF-8 On Tue, Apr 7, 2015 at 4:38 PM, Alex Deucher wrote: > On Tue, Apr 7, 2015 at 3:46 AM, Lucas Stach > 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@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. -Jon --f46d043c7f24bd6c510513238b6e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Apr 7, 2015 at 4:38 PM, Alex Deucher <alexdeucher@gmail.co= m> wrote:
On Tue, Apr 7, 20= 15 at 3:46 AM, Lucas Stach <l.= stach@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@arm.linux.org.uk>:
>> > On Thu, Apr 02, 2015 at 05:30:44PM +0200, Lucas Stach wrote:<= br> >> >> 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 betwee= n the
>> >> user "pipes" and the PIPE_2D/PIPE_3D execution = states.
>> >
>> > This is good, because on Dove we have a single Vivante core w= hich
>> > supports both 2D and 3D together.=C2=A0 It's always bugge= d me that
>> > etnadrm has not treated cores separately from their capabilit= ies.
>> >
>>
>> Today I finally got the idea how this multiple pipe stuff should b= e
>> done the right way - thanks Russell.
>> So maybe you/we need to rework how the driver is designed regardin= g
>> 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 GPU3= D
> 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 thing= s
> a lot as we would then have to deal with DMA-BUF fences just to get th= e
> 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<= br> > executing in both 2D and 3D state. If userspace takes advantage of tha= t
> one could leave the sync between both engines to the FE, which is a go= od
> thing as this allows the kernel to do less work. I don't see why w= e
> 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.=C2=A0 E.g., modern radeons support one or more gfx, compute, dma, video decode and video encode engines.=C2=A0 What
combination is present depends on the asic.


That reminds m= e.=C2=A0 We should also have in the back of our heads that compute is suppo= rted by the newer Vivante chips.=C2=A0 We will also need to support multipl= e independent 3d cores as that support has shown up in the V5 galcore drive= rs.

-Jon=C2=A0

--f46d043c7f24bd6c510513238b6e-- --===============1989293196== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KZHJpLWRldmVs IG1haWxpbmcgbGlzdApkcmktZGV2ZWxAbGlzdHMuZnJlZWRlc2t0b3Aub3JnCmh0dHA6Ly9saXN0 cy5mcmVlZGVza3RvcC5vcmcvbWFpbG1hbi9saXN0aW5mby9kcmktZGV2ZWwK --===============1989293196==--