On Tue, Mar 29, 2016 at 4:41 AM, Daniel Vetter <dan...@ffwll.ch> wrote: > 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.
fwiw, I think on msm actually v4l is the most restrictive and display is the least restrictive ;-) At least none need contig memory (well, not sure about secure playback, but for upstream+AOSP I guess we can ignore that), so it is mostly about pitch requirements for various formats. I suppose we could chicken out and have a platform specific config file or quirks table? BR, -R > 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
