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

[Dan Stoza]

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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20160502/aca2d491/attachment-0001.html>