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

[Greg Hackmann]

On 05/01/2016 11:58 PM, Daniel Vetter wrote:
> 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
>

Adding Dan Stoza from our graphics team.