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

[Daniel Stone]

Hi,

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
format.

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
maintenance.

Cheers,
Daniel