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

[Michel Dänzer]

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 at 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 at 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