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. BR, -R _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev