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

[Dan Stoza]

The gralloc stride returned from alloc isn't required to be the actual
stride of the buffer, it only needs to be the stride of the staging buffer
when locked, though I suppose that does mean that it is intended to be
invariant across the life of the buffer.

On Mon, May 2, 2016 at 12: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.
>
> BR,
> -R
>
> On Mon, May 2, 2016 at 2:16 PM, Dan Stoza <stoza at google.com> wrote:
> > Would it be possible for someone to elaborate a bit on the limitation
> > gralloc is imposing? Is it a mismatch between reported stride and the
> actual
> > stride of the buffer?
> >
> > On Mon, May 2, 2016 at 11:07 AM, Greg Hackmann <ghackmann at google.com>
> wrote:
> >>
> >> On 05/01/2016 11:58 PM, Daniel Vetter wrote:
> >>>
> >>> Adding Greg Hackmann from the Android side. Greg, please add anyone
> >>> else who might be relevant.
> >>>
> >>> On Sat, Apr 30, 2016 at 2:54 PM, Rob Clark <robdclark at gmail.com>
> wrote:
> >>>>
> >>>> On Sat, Apr 30, 2016 at 8:26 AM, Marek Olšák <maraeo at gmail.com>
> wrote:
> >>>>>
> >>>>> On Sat, Apr 30, 2016 at 1:55 PM, Rob Clark <robdclark at gmail.com>
> wrote:
> >>>>>>
> >>>>>> 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.)
> >>>>>
> >>>>>
> >>>>> Well, you can transfer_map the whole layer, but that's not enough to
> >>>>> get the original pitch, because tiled textures can be aligned to 8x8,
> >>>>> but linear textures can be aligned to 64x1.
> >>>>
> >>>>
> >>>> At any rate, this is a limitation of gralloc API (which we don't
> >>>> control), rather than proposed gbm interface.  Maybe it is better to
> >>>> push google to fix gralloc rather than trying to work-around it.
> >>>
> >>>
> >>> Any chance we could fix that part of gralloc? For most UMA/SoC gpus
> >>> you just map the underlying buffer (and then flush), but even on some
> >>> SoC gpus and definitely on anything discrete you want staging buffers.
> >>> And those shouldn't need to be oversized like that ...
> >>>
> >>> Thanks, Daniel
> >>>
> >>
> >> Adding Dan Stoza from our graphics team.
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20160502/2da8abd1/attachment-0001.html>