[Mesa-dev] [PATCH] egl: android: add dma-buf fd support
Rob Herring
robh at kernel.org
Wed Apr 20 03:02:47 UTC 2016
On Tue, Apr 19, 2016 at 8:43 PM, Rob Clark <robdclark at gmail.com> wrote:
> On Tue, Apr 19, 2016 at 9:03 PM, Emil Velikov <emil.l.velikov at gmail.com> wrote:
>> Hi Rob,
>>
>> Please bear in mind that there's a fair bit of comments, but before
>> all don't mix refactoring and new code. Please ?
>>
>> On 15 April 2016 at 17:03, Rob Herring <robh at kernel.org> wrote:
>>> Add support for creating images from Android native buffers with dma-buf
>>> fd. As dma-buf support also requires DRI image loader extension, add
>>> that as well.
>>>
>>> This is based on several originally patches written by Varad Gautam.
>>> I've collapsed them down to one and done a bit of reformatting. dma-bufs
>>> and GEM handles are now both supported instead of being compile time
>>> selection.
>> How did you test this ? Afaict making this (at least in current shape)
>> isn't possible to be a runtime decision.
>
> Just a drive-by comment, but seems like most of the main drivers (x86
> and arm, minus perhaps the x86 server gpus, which are probably not
> interesting in this context) support DRIVER_PRIME + DRIVER_RENDER..
>
> So possibly we don't need to keep support for a runtime decision.. and
> almost certainly all the drivers that support atomic (which I think is
> required for what Rob is working on) support prime+render, so in the
> worst case we could have a compile time decision between "old world"
> and "new world"?
It was I guess. But we could have a mixture on android-x86. In theory,
Intel should work with new world (though there are issues to debug).
Radeon/Nouveau/vmwgfx are not there yet due to no atomic support.
> It would ofc be good to make sure we don't break things for
> android-x86, but I think they would stick on dri2 + pre-atomic state
> w/ compile time build decisions until enough of the desktop gpu's
> support atomic.. although maybe it helps to switch them over to
> prime+render without switching to gbm_gralloc and kms hwc stuff yet?
I'm not sure that will work without a lot of work to drm_gralloc to
support using both the render and card nodes and prime support for
each gpu.
gbm_gralloc and non-atomic kms in hwc seems like the quickest path to
me, but I may be missing something.
Rob
More information about the mesa-dev
mailing list