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

[Marek Olšák]

On Mon, May 2, 2016 at 9:51 PM, Rob Clark <robdclark at gmail.com> wrote:
> On Mon, May 2, 2016 at 3:21 PM, Marek Olšák <maraeo at gmail.com> wrote:
>> On Mon, May 2, 2016 at 9:05 PM, Rob Clark <robdclark at gmail.com> wrote:
>>> 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.
>>
>> It's much more complicated than that.
>>
>> Every texture (or image) can have multiple pitches depending on how
>> it's used. When being accessed by the GPU, the texture is tiled, so
>> the alignment is e.g. 8x8 (the pitch is a multiple of 8). When you map
>> the same texture for CPU access, it must be linearized by the driver,
>> however, linear textures use a completely different alignment, e.g.
>> 64x1 (the pitch is a multiple of 64). Any API dealing with (at least
>> desktop) GPUs should take this difference into account.
>>
>> As an optimization, some drivers only want to linearize the part of
>> the texture that is being mapped. This is where you get a smaller
>> window. For example, if you map a 4x4 pixel window, you will get a
>> pitch of 64 with the 64x1 linear alignment.
>>
>> In a nutshell, there are different pitches for GPU access, CPU access,
>> and sub-window CPU access (it depends on the sub-window size).
>>
>
> This could be sort of dealt with by only advertising the pitch of the
> (entire) linearized buffer (with some ugly enough hacks), although it
> comes back to the same issue as the rest of the cases.. you'd prefer
> the staging buffer to just match the requested sub-window.  The way
> pipe_transfer works is perfect, since it gives enough info to the
> driver (read and/or write flags, and discard flags, plus bounding box)
> to work with either zero-copy or staging-copy with the least overhead
> possible.

BTW, on the previous topic, the "tiled" pitch can be queried by
calling pipe_context::resource_get_handle, while the "linear" pitch
can be obtained from pipe_context::transfer_map. It just shows that
the Gallium design is aware that they might not be equal (with
transfer_map having many possible values depending on the sub-window).

Marek