<div dir="ltr">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.</div><div class="gmail_extra"> <div class="gmail_quote">On Mon, May 2, 2016 at 12:05 PM, Rob Clark <<a href="mailto:robdclark@gmail.com" target="_blank">robdclark@gmail.com</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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 <div class="HOEnZb"><div class="h5"> On Mon, May 2, 2016 at 2:16 PM, Dan Stoza <<a href="mailto:stoza@google.com">stoza@google.com</a>> 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 <<a href="mailto:ghackmann@google.com">ghackmann@google.com</a>> 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 <<a href="mailto:robdclark@gmail.com">robdclark@gmail.com</a>> wrote: >>>> >>>> On Sat, Apr 30, 2016 at 8:26 AM, Marek Olšák <<a href="mailto:maraeo@gmail.com">maraeo@gmail.com</a>> wrote: >>>>> >>>>> On Sat, Apr 30, 2016 at 1:55 PM, Rob Clark <<a href="mailto:robdclark@gmail.com">robdclark@gmail.com</a>> wrote: >>>>>> >>>>>> On Sat, Apr 30, 2016 at 5:39 AM, Michel Dänzer <<a href="mailto:michel@daenzer.net">michel@daenzer.net</a>> >>>>>> wrote: >>>>>>> >>>>>>> On <a href="tel:26.04.2016%2003" value="+12604201603">26.04.2016 03</a>:51, Rob Herring wrote: >>>>>>>> >>>>>>>> On Mon, Apr 25, 2016 at 9:25 AM, Emil Velikov >>>>>>>> <<a href="mailto:emil.l.velikov@gmail.com">emil.l.velikov@gmail.com</a>> wrote: >>>>>>>>> >>>>>>>>> On 25 April 2016 at 13:46, Daniel Stone <<a href="mailto:daniel@fooishbar.org">daniel@fooishbar.org</a>> >>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> On 23 April 2016 at 03:08, Rob Herring <<a href="mailto:robh@kernel.org">robh@kernel.org</a>> wrote: >>>>>>>>>>> >>>>>>>>>>> On Fri, Apr 22, 2016 at 6:32 PM, Emil Velikov >>>>>>>>>>> <<a href="mailto:emil.l.velikov@gmail.com">emil.l.velikov@gmail.com</a>> 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. > > </div></div></blockquote></div> </div>