<div dir="ltr">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?</div><div class="gmail_extra"> <div class="gmail_quote">On Mon, May 2, 2016 at 11:07 AM, Greg Hackmann <<a href="mailto:ghackmann@google.com" target="_blank">ghackmann@google.com</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 05/01/2016 11:58 PM, Daniel Vetter wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> 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" 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"> On Sat, Apr 30, 2016 at 8:26 AM, Marek Olšák <<a href="mailto:maraeo@gmail.com" target="_blank">maraeo@gmail.com</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> On Sat, Apr 30, 2016 at 1:55 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"> On Sat, Apr 30, 2016 at 5:39 AM, Michel Dänzer <<a href="mailto:michel@daenzer.net" target="_blank">michel@daenzer.net</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> On <a href="tel:26.04.2016%2003" value="+12604201603" target="_blank">26.04.2016 03</a>:51, Rob Herring wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> On Mon, Apr 25, 2016 at 9:25 AM, Emil Velikov <<a href="mailto:emil.l.velikov@gmail.com" target="_blank">emil.l.velikov@gmail.com</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> On 25 April 2016 at 13:46, Daniel Stone <<a href="mailto:daniel@fooishbar.org" target="_blank">daniel@fooishbar.org</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> On 23 April 2016 at 03:08, Rob Herring <<a href="mailto:robh@kernel.org" target="_blank">robh@kernel.org</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> On Fri, Apr 22, 2016 at 6:32 PM, Emil Velikov <<a href="mailto:emil.l.velikov@gmail.com" target="_blank">emil.l.velikov@gmail.com</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> 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. </blockquote> 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: </blockquote> Right, I wouldn't take GBM_BO_USE_WRITE to have much of an effect on mappings, as it pessimises allocation like you say. </blockquote> 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. </blockquote> 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? </blockquote> 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. </blockquote> *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.) </blockquote> 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. </blockquote> 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. </blockquote> 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 </blockquote> Adding Dan Stoza from our graphics team. </blockquote></div> </div>