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.
/Thomas >> Thoughts? >> >> BR, >> -R > _______________________________________________ > mesa-dev mailing list > [email protected] > https://lists.freedesktop.org/mailman/listinfo/mesa-dev _______________________________________________ mesa-dev mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/mesa-dev
