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

[Marek Olšák]

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

Marek