On Sat, Mar 26, 2016 at 6:42 PM, Stéphane Marchesin <[email protected]> wrote: > > On Mar 26, 2016 3:09 PM, "Rob Clark" <[email protected]> wrote: >> >> On Fri, Mar 25, 2016 at 9:38 PM, Stéphane Marchesin <[email protected]> >> wrote: >> > On Wed, Mar 23, 2016 at 5:22 PM, Rob Herring <[email protected]> wrote: >> >> On Fri, Mar 4, 2016 at 12:07 PM, Rob Clark <[email protected]> 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.. >> >> >> >> 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? >> > >> > gbm as it is misses some bits, for example lock/unlock, and more fine >> > grained usage flags. >> > >> > I'm also planning to look into something similar with minigbm, i.e. >> > have one backend and expose a minigbm and a gralloc frontend on top. >> > But I'm not sure if it's possible/sensible yet. >> >> I haven't thought about the details, but in principle I wouldn't be >> opposed to extending gbm to add whatever is needed... > > Yeah that's what I want to do: extend the api and the drivers as needed (I > might just expose a new internal api but no new gbm api...). But one place > where things are fundamentally different is that gbm in mesa only knows > about 3d while gralloc knows about system wide stuff like video etc. >
hmm, presumably that problem goes away once fence + syncpt stuff is wired up through all the drivers? BR, -R >> >> it certainly would be convenient to not have to care about both gbm >> and gralloc from driver standpoint. > > Absolutely. > > Stéphane > >> >> BR, >> -R >> >> >> > Stéphane >> > >> >> >> >> 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? >> >> >> >> Rob >> _______________________________________________ >> 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
