[Mesa-dev] gralloc_drm_pipe

Thomas Hellstrom thellstrom at vmware.com
Fri Mar 4 19:43:52 UTC 2016


On 03/04/2016 07:07 PM, Rob Clark wrote:
> On Fri, Mar 4, 2016 at 12:59 PM, Rob Clark <robdclark at gmail.com> wrote:
>> So, I've been advocating that for android, gallium drivers use
>> gralloc_drm_pipe, since with android it seems like you end up with
>> both gralloc and libGL in the same process, and having both share the
>> same pipe_screen avoids lots of headaches with multiple gem handles
>> pointing to same underlying buffer.
>>
>> But the awkward thing is that gralloc_drm_pipe is using gallium APIs
>> that aren't particularly intended to be used out-of-tree.  Ie. not
>> really stable APIs.  At the time, the thing that made sense to me was
>> to pull drm_gralloc into mesa.  But at the time, there were no
>> non-mesa users of drm_gralloc, which isn't really true anymore.
>>
>> Maybe what makes more sense now is to implement a gralloc state
>> tracker, which exposes a stable API for drm_gralloc?  It would mostly
>> be a shim to expose gallium import/export/transfer APIs in a stable
>> way, but would also be where the code that figures out which driver to
>> use to create/get the pipe_screen.
> and actually, we might just be able to use XA state tracker for this..
> I think it exposes all the necessary import/export/etc stuff that
> gralloc would need..
>
> BR,
> -R
>
and it was created for a very similar purpose, except that we also
needed some
render functionality, enough to composite surfaces.

/Thomas




>> Thoughts?
>>
>> BR,
>> -R
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev



More information about the mesa-dev mailing list