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

[Rob Clark]

On Tue, Mar 29, 2016 at 1:51 PM, Daniel Stone <daniel at fooishbar.org> wrote:
> 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.

right, or let's say whether the entire vma is mapped or not should be
implementation specific.

It would probably be useful if the ptr returned had the offset already
added, since this is how transfer_map works.. and (hopefully?) the
gralloc API lets us return a separate pitch for the mapped ptr (which
might be different from the src buffer)?  That would accommodate
upload/download sanely.  (Fwiw, even some UMA drivers need to do
staging copies for some formats..  although I guess gralloc probably
doesn't care about z32_float_s8x24_uint and that sort of thing ;-))

BR,
-R

> Cheers,
> Daniel