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

[Rob Clark]

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.)

BR,
-R