On Tue, Mar 8, 2016 at 2:22 AM, Rob Herring <r...@kernel.org> wrote: > 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?
Any of the gallium drivers should support XA[1].. but not classic (non-gallium) drivers, which really only matters for intel. So basically the intel backend in drm_gralloc would have to remain, but the nouveau/radeon/vmwgfx ones could be dropped[2] [1] maybe at one point I had to make some makefile changes or something like that? Not sure, it was a long time ago when I first started using XA in xf86-video-freedreno. But if that was the case it pre-dated pipe_loader_create_screen().. at least from point of view of what features XA needs from gallium pipe driver, it is very minimal [2] there is still the unrelated issue of how to deal w/ drm drivers which do not (yet?) support atomic.. > 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? Hmm.. not 100% sure.. it is no problem to import/export dma-buf handles (xa_handle_type_fd) from an xa_surface. I guess *somewhere* you need to be able to go from a native_handle_t <-> fd (and then <-> xa_surface). So I'm not sure if that decouples mesa EGL from drm_gralloc.. BR, -R > Rob > _______________________________________________ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/mesa-dev _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
