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
