On Mon, May 2, 2016 at 9:51 PM, Rob Clark <robdcl...@gmail.com> wrote: > On Mon, May 2, 2016 at 3:21 PM, Marek Olšák <mar...@gmail.com> wrote: >> On Mon, May 2, 2016 at 9:05 PM, Rob Clark <robdcl...@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 _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev