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 <st...@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 <ghackm...@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 <robdcl...@gmail.com> wrote: >>>> >>>> On Sat, Apr 30, 2016 at 8:26 AM, Marek Olšák <mar...@gmail.com> wrote: >>>>> >>>>> On Sat, Apr 30, 2016 at 1:55 PM, Rob Clark <robdcl...@gmail.com> wrote: >>>>>> >>>>>> On Sat, Apr 30, 2016 at 5:39 AM, Michel Dänzer <mic...@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.veli...@gmail.com> wrote: >>>>>>>>> >>>>>>>>> On 25 April 2016 at 13:46, Daniel Stone <dan...@fooishbar.org> >>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> On 23 April 2016 at 03:08, Rob Herring <r...@kernel.org> wrote: >>>>>>>>>>> >>>>>>>>>>> On Fri, Apr 22, 2016 at 6:32 PM, Emil Velikov >>>>>>>>>>> <emil.l.veli...@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. > > _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev