On Tue, Mar 29, 2016 at 10:30 AM, Rob Herring <[email protected]> wrote: > On Tue, Mar 29, 2016 at 8:43 AM, Rob Clark <[email protected]> wrote: >> On Mon, Mar 28, 2016 at 12:29 PM, Rob Herring <[email protected]> wrote: >>> On Fri, Mar 25, 2016 at 8: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 think this can be implemented on top within gralloc as it is today >>> with drm_gralloc. >>> >>> However, I found a bigger mismatch is there are no explicit map/unmap >>> calls in GBM. A writeable buffer will be a dumb buffer and is >>> implicitly mapped. Maybe that is enough in reality? >>> >> >> I think originally this was probably just used for uploading mouse >> cursor, or something along those lines, rather than any serious use of >> sw rendering. But if android needs to mix hw and sw access to the >> buffer, I think we do need something that maps to transfer_map/unmap, >> so gl driver can (if needed) flush pending rendering and sync. >> >> Not sure how others feel, but I wouldn't be opposed to extending gbm.. >> anything that can sit on top of transfer_map/unmap should coexist well >> with a gpu driver. > > Looks like it was tried already[1]. Interestingly, the gralloc lock > interface already does some of what is discussed being needed > (specifying the region).
yeah, as does pipe->transfer_map/unmap (which is ofc supported by vmwgfx gallium driver). So I think the issue is to just make the API look more like transfer_map/unmap (ie. specify a region.. and probably usage flags.. I don't think it would be applicable for cube/array/3d textures so 'level' probably not required.), rather than blind 'give me a void * for the whole buffer' sort of thing.. BR, -R > Rob > > [1] https://lists.freedesktop.org/archives/mesa-dev/2014-April/058484.html > _______________________________________________ > 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
