[Mesa-dev] [android-x86-devel] Re: gralloc_drm_pipe

Daniel Stone daniel at fooishbar.org
Tue Mar 29 17:51:04 UTC 2016


On 29 March 2016 at 15:44, Rob Clark <robdclark at gmail.com> wrote:
> On Tue, Mar 29, 2016 at 10:30 AM, Rob Herring <robh at kernel.org> wrote:
>> On Tue, Mar 29, 2016 at 8:43 AM, Rob Clark <robdclark at gmail.com> wrote:
>>> On Mon, Mar 28, 2016 at 12:29 PM, Rob Herring <robh at kernel.org> wrote:
>>>> 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..

Yep, you got it right: in the original intention, the only mappable
GBM BOs were cursor BOs. This is mostly because we lacked modifiers,
so it was assumed that they would be in a magic undiscoverable tiling

Now we have modifiers, whilst adding those to the API (both allocation
and gbm_bo_get_*() for legacy allocations), you could then do a
gbm_bo_{,un}map_range(). I'm assuming these mostly wouldn't actually
map and unmap in a VMA sense, but rather primarily perform cache


More information about the mesa-dev mailing list