On Sun, Mar 6, 2016 at 9:29 PM, Chih-Wei Huang <[email protected]> wrote: > 2016-03-05 3:53 GMT+08:00 Rob Clark <[email protected]>: >> On Fri, Mar 4, 2016 at 2:43 PM, Thomas Hellstrom <[email protected]> >> wrote: >>> On 03/04/2016 07:07 PM, Rob Clark wrote: >>>> On Fri, Mar 4, 2016 at 12:59 PM, Rob Clark <[email protected]> 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. BR, -R > Do I understand your words correctly? > _______________________________________________ mesa-dev mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/mesa-dev
