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