[Mesa-dev] [PATCH 4/4] gbm: Add map/unmap functions

[Daniel Vetter]

Adding Greg Hackmann from the Android side. Greg, please add anyone
else who might be relevant.

On Sat, Apr 30, 2016 at 2:54 PM, Rob Clark <robdclark at gmail.com> wrote:
> On Sat, Apr 30, 2016 at 8:26 AM, Marek Olšák <maraeo at gmail.com> wrote:
>> On Sat, Apr 30, 2016 at 1:55 PM, Rob Clark <robdclark at gmail.com> wrote:
>>> On Sat, Apr 30, 2016 at 5:39 AM, Michel Dänzer <michel at daenzer.net> wrote:
>>>> On 26.04.2016 03:51, Rob Herring wrote:
>>>>> On Mon, Apr 25, 2016 at 9:25 AM, Emil Velikov <emil.l.velikov at gmail.com> wrote:
>>>>>> On 25 April 2016 at 13:46, Daniel Stone <daniel at fooishbar.org> wrote:
>>>>>>> On 23 April 2016 at 03:08, Rob Herring <robh at kernel.org> wrote:
>>>>>>>> On Fri, Apr 22, 2016 at 6:32 PM, Emil Velikov <emil.l.velikov at gmail.com> wrote:
>>>>>>>>> Can we take a look at the GBM gralloc as well. One thing that worries
>>>>>>>>> me is that (most likely) you are requesting/creating a bo without
>>>>>>>>> GBM_BO_USE_WRITE whist using MAP + CPU write UNMAP. If you do set the
>>>>>>>>> USE_WRITE flag, you're getting a dumb buffer, which I'm not sure how
>>>>>>>>> well is going to work.
>>>>>>>>
>>>>>>>> I'm not using GBM_BO_USE_WRITE and that is not a condition for mapping
>>>>>>>> given that flag is tied to cursors (according to comments) and gives
>>>>>>>> dumb buffers. Also of note, if gralloc flags are set for r/w often,
>>>>>>>> then I request a linear buffer. Here's the gralloc side:
>>>>>>>
>>>>>>> Right, I wouldn't take GBM_BO_USE_WRITE to have much of an effect on
>>>>>>> mappings, as it pessimises allocation like you say.
>>>>>>>
>>>>>> Ftr, I'm not objecting as to how things are done. Just saying that
>>>>>> things should be blindly obvious as one reads the documentation alone.
>>>>>> I'm assuming that most people involved are "tainted" (the know to a
>>>>>> level how things are implemented) thus things are clearer for them.
>>>>>
>>>>> I'm not sure what to document here other than the use flags have no
>>>>> impact or restrictions on mapping. If that's not true, then that is a
>>>>> limitation within the gallium drivers of which I have little knowledge
>>>>> about and need someone tainted to spell out. I suppose documenting
>>>>> that buffers with frequent cpu access should use a linear buffer would
>>>>> be universally true?
>>>>
>>>> It's actually stricter than that with the radeonsi driver: It sets the
>>>> RADEON_GEM_NO_CPU_ACCESS/AMDGPU_GEM_CREATE_NO_CPU_ACCESS flag when
>>>> allocating non-linear buffers, signalling to the kernel driver that CPU
>>>> access to the buffer doesn't need to work. At least the amdgpu kernel
>>>> driver actually enforces this and returns an error if userspace tries
>>>> mapping such a buffer.
>>>>
>>>
>>> *But*, the cpu access is going via pipe_transfer so it could work
>>> exactly the same way as (for example) glReadPixels() (ie. copies to
>>> and/or from a staging bo, rather than direct mmap access to the
>>> original bo).
>>>
>>> (The one slight problem is that android/gralloc doesn't know how to
>>> deal when pitch of the staging buffer returned differers from the
>>> pitch of the actual buffer.. but that kinda somehow needs to be fixed
>>> in android.  Maybe for the time being we need a
>>> PIPE_TRANSFER_GRALLOC_HACK type flag to tell drivers to allocate an
>>> unnecessarily large staging bo to preserve the pitch.)
>>
>> Well, you can transfer_map the whole layer, but that's not enough to
>> get the original pitch, because tiled textures can be aligned to 8x8,
>> but linear textures can be aligned to 64x1.
>
> At any rate, this is a limitation of gralloc API (which we don't
> control), rather than proposed gbm interface.  Maybe it is better to
> push google to fix gralloc rather than trying to work-around it.

Any chance we could fix that part of gralloc? For most UMA/SoC gpus
you just map the underlying buffer (and then flush), but even on some
SoC gpus and definitely on anything discrete you want staging buffers.
And those shouldn't need to be oversized like that ...

Thanks, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch