Re: [PATCH 02/12] drm/etnaviv: add devicetree bindings

From: "Michel Dänzer" <michel@daenzer.net>
To: Daniel Vetter <daniel@ffwll.ch>, Ilia Mirkin <imirkin@alum.mit.edu>
Cc: "devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	Russell King - ARM Linux <linux@arm.linux.org.uk>,
	dri-devel <dri-devel@lists.freedesktop.org>,
	patchwork-lst@pengutronix.de,
	"kernel@pengutronix.de" <kernel@pengutronix.de>,
	Shawn Guo <shawnguo@kernel.org>
Subject: Re: [PATCH 02/12] drm/etnaviv: add devicetree bindings
Date: Mon, 7 Dec 2015 17:41:04 +0900	[thread overview]
Message-ID: <56654620.1040208@daenzer.net> (raw)
In-Reply-To: <20151205101208.GP10243@phenom.ffwll.local>

On 05.12.2015 19:12, Daniel Vetter wrote:
> On Fri, Dec 04, 2015 at 05:43:33PM -0500, Ilia Mirkin wrote:
>> On Fri, Dec 4, 2015 at 5:05 PM, Russell King - ARM Linux
>> <linux@arm.linux.org.uk> wrote:
>>> On Fri, Dec 04, 2015 at 03:42:47PM -0500, Ilia Mirkin wrote:
>>>> On Fri, Dec 4, 2015 at 3:31 PM, Russell King - ARM Linux
>>>> <linux@arm.linux.org.uk> wrote:
>>>>> Moreover, DRI3 is not yet available for Gallium, so if we're talking
>>>>> about Xorg, then functional DRI2 is a requirement, and that _needs_
>>>>> to have a single device for the rendering instances.  Xorg has no way
>>>>> to pass multiple render nodes to client over DRI2.
>>>>
>>>> Just to correct... DRI3 has been available on gallium [at least in the
>>>> context of st/mesa] basically since DRI3 was introduced. Not sure what
>>>> issue you're fighting with, but it's definitely not a gallium
>>>> limitation... could be something related to platform devices.
>>>
>>> Well, my statement is based on the fact that there's nothing in
>>> src/gallium/state-tracker/dri which hints at being DRI3.  Maybe it's
>>> implemented differently, I don't know.

The DRI state tracker code in src/gallium/state_trackers/dri/ supports
DRI1-3. There's almost no explicit mention of DRI3 in it because DRI3
and DRI2 work mostly the same as far as this code is concerned.

>>> I think it's a DRI3 limitation.  The issue with the DRI3 design is that:
>>>
>>> * The client has access to the GPU render nodes only, but not the
>>>   corresponding KMS node.
>>> * Buffers in DRI3 are allocated from the GPU render nodes.
>>> * The Xorg Present protocol is then used to manage the vblank
>>>   synchonisation and page flips.
>>>
>>> Now, the KMS scanout hardware typically does not support any kind of
>>> scatter-gather: the buffers it has must be contiguous.  These can be
>>> allocated from the KMS DRM device.
>>>
>>> However, the DRI3 client has no access to the KMS DRM device to allocate
>>> linear buffers from, and GPUs typically don't have dumb buffer support.
>>> Hence, the client can't pass a suitable buffer to the present layer.
> 
> Oh right, buffer alloc if you have special constraints won't work with
> DRI3 as-is. For that we probably need something like DRI2 for buffer alloc
> + Present (like DRI3 does) for flipping them.

FWIW, that's basically possible already. E.g. the Gallium nine state
tracker can use Present even with DRI2.

-- 
Earthling Michel Dänzer               |               http://www.amd.com
Libre software enthusiast             |             Mesa and X developer
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel