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

[Rob Clark]

This is for the non-zero-copy case..  for example pixels live in gl
texture in host (vmwgfx/virtgl), or in vram for discrete gpu perhaps
(or some tiled format, etc).

Since in those cases, you have to copy part of the buffer, as
specified by the bounding box, to and/or from staging buffer (based on
read/write flags)..  You'd prefer that the pitch of the returned ptr
was not required to match the pitch of the original buffer.

BR,
-R

On Mon, May 2, 2016 at 2:16 PM, Dan Stoza <stoza at google.com> wrote:
> Would it be possible for someone to elaborate a bit on the limitation
> gralloc is imposing? Is it a mismatch between reported stride and the actual
> stride of the buffer?
>
> On Mon, May 2, 2016 at 11:07 AM, Greg Hackmann <ghackmann at google.com> wrote:
>>
>> 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.
>
>