On Sun, Mar 6, 2016 at 10:32 PM, Rob Clark <robdcl...@gmail.com> wrote: > On Sun, Mar 6, 2016 at 9:29 PM, Chih-Wei Huang <cwhu...@android-x86.org> > wrote: >> 2016-03-05 3:53 GMT+08:00 Rob Clark <robdcl...@gmail.com>: >>> On Fri, Mar 4, 2016 at 2:43 PM, Thomas Hellstrom <thellst...@vmware.com> >>> wrote: >>>> On 03/04/2016 07:07 PM, Rob Clark wrote: >>>>> On Fri, Mar 4, 2016 at 12:59 PM, Rob Clark <robdcl...@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. >>> >>> right, and since we have the ability to import/export dmabuf handles, >>> I think it is a superset of what is needed. (gralloc is using blits >>> instead of flips for vmwgfx, for reasons I don't fully understand.. >>> but XA can do these blits and more, so we are still good there) >> >> Hi Rob, >> Thank you for raising the problem though >> I don't fully understand the technical details. >> >> So you are planning to modify (or re-implement?) >> gralloc_drm_pipe to use the APIs of XA state tracker. > > well, unless I can talk someone else into doing it before I find time ;-) > > But yeah, if no one else does it (or comes up with a better idea > first), I will eventually do it. > > fwiw, the XA API is: > > https://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/state_trackers/xa/xa_tracker.h > https://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/state_trackers/xa/xa_context.h > (ignoring the composite bits which we shouldn't need) > > I think that should provide everything needed for gralloc, but with a > stable API rather than using the gallium pipe screen/context APIs > directly.
This seems reasonable from what I've looked at it. Does supporting XA require any h/w specific bits for gallium drivers and the classic drivers already support XA? One of the problems I've been looking at is dma-buf fds are not exposed by gralloc in any standard way although various implementations happen to be aligned. So mesa EGL has a dependency on drm_gralloc to retrieve the fd from native_handle_t. Would we be able to remove that dependency and retrieve the dma-buf fds directly from XA? Rob _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
