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

Rob Clark robdclark at gmail.com
Mon May 2 19:51:08 UTC 2016

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


More information about the mesa-dev mailing list