On Wed, Mar 23, 2016 at 8:22 PM, Rob Herring <r...@kernel.org> wrote: > On Fri, Mar 4, 2016 at 12:07 PM, Rob Clark <robdcl...@gmail.com> 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.. > > Rob and I discussed this a bit more F2F recently. An alternative we > discussed would be using GBM instead. GBM seems more inline with > gralloc needs. This would also have the advantage of working with > minigbm as well for non-mesa cases. Any thoughts on GBM vs. XA?
oh, I meant to send out an email about that but forgot.. but yeah, I think gbm should be able to do everything we need, so seems pretty sensible. Plus a way to handle intel/i965 and other non-mesa drivers. So we could basically replace all of drm_gralloc with one smaller thing[*].. [*] the caveat there is vmwgfx stuff which seems to want to do blits.. although I'm not entirely sure why or if that is even still requires w/ newer vmware players. But if vmwgfx still really needs the blit path, I guess they could still keep using gralloc_drm instead of switching to gralloc_gbm ;-) > I spent a bit of time and dug into GBM some more. It appears to me > that GBM would have the same screen sharing issue. AFAICT, it depends > on whether multiple __DRIscreen's are okay as long as the pipe_screen > is shared? Yeah, I think that shouldn't be a problem.. in the end, no matter how many __DRIscreen's we should end up w/ a single (ref-cnt'd) pipe_screen per process, so it should all just work out BR, -R _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
