On Sat, Mar 26, 2016 at 07:44:58PM -0400, Rob Clark wrote: > On Sat, Mar 26, 2016 at 7:09 PM, Stéphane Marchesin > <stephane.marche...@gmail.com> wrote: > > > > On Mar 26, 2016 16:05, "Rob Clark" <robdcl...@gmail.com> wrote: > >> > >> On Sat, Mar 26, 2016 at 6:42 PM, Stéphane Marchesin > >> <stephane.marche...@gmail.com> wrote: > >> > > >> > On Mar 26, 2016 3:09 PM, "Rob Clark" <robdcl...@gmail.com> wrote: > >> >> > >> >> On Fri, Mar 25, 2016 at 9:38 PM, Stéphane Marchesin > >> >> <marc...@google.com> > >> >> wrote: > >> >> > On Wed, Mar 23, 2016 at 5: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? > >> >> > > >> >> > 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? > > > > Synchronization is just one piece. Your also have to consider things like > > alignment and format restrictions for video decode for example. These can be > > different from 3d so you need some knowledge of the video engine for > > example. Ditto with everything else. > > hmm, admittedly I'm used to think of gpu as the most restrictive thing.. > > But maybe to start with we don't have to solve all the world's > problems.. maybe it is good enough to do a reference gbm_gralloc which > works in the common cases.. SoC vendors can still replace it with > their own thing when the generic one doesn't fit their needs. Going > from "everyone has their own implementation" to "some have their own > implementation" seems like forward progress. > > At least then we can get to something that works for all the mesa > drivers and at least a reasonable subset of everyone else..
At least with video I thought the Grand Android Plan was to switch over to v4l? Maybe we just need to add/query some v4l apis to figure out what's needed for a basic gralloc that works everywhere. There's still the question of where to allocate stuff, but maybe a simple heuristics like assuming that display > v4l > gpu wrt placement constraints (e.g. allocating from cma or not) should be good enough? Maybe with an optional fallback to some ION heap for some shared buffers, there's a todo somewhere about that. Just throwing out my thoughts, I agree that starting out with a gralloc that's good enough for display+gpu sounds like a solid plan. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev