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

[Rob Clark]

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.

BR,
-R