Am 02.11.22 um 13:50 schrieb Pekka Paalanen:
On Wed, 2 Nov 2022 13:27:18 +0100
Christian König <ckoenig.leichtzumerken@xxxxxxxxx> wrote:
Am 02.11.22 um 13:19 schrieb Pekka Paalanen:
On Wed, 2 Nov 2022 12:18:01 +0100
Christian König <ckoenig.leichtzumerken@xxxxxxxxx> wrote:
Am 01.11.22 um 22:09 schrieb Nicolas Dufresne:
[SNIP]
But the client is just a video player. It doesn't understand how to
allocate BOs for Panfrost or AMD or etnaviv. So without a universal
allocator (again ...), 'just allocate on the GPU' isn't a useful
response to the client.
Well exactly that's the point I'm raising: The client *must* understand
that!
See we need to be able to handle all restrictions here, coherency of the
data is just one of them.
For example the much more important question is the location of the data
and for this allocating from the V4L2 device is in most cases just not
going to fly.
It feels like this is a generic statement and there is no reason it could not be
the other way around.
And exactly that's my point. You always need to look at both ways to
share the buffer and can't assume that one will always work.
As far as I can see it you guys just allocate a buffer from a V4L2
device, fill it with data and send it to Wayland for displaying.
To be honest I'm really surprised that the Wayland guys hasn't pushed
back on this practice already.
What should we Wayland people be pushing back on exactly? And where is
our authority and opportunity to do so?
The Wayland protocol dmabuf extension allows a graceful failure if the
Wayland compositor cannot use the given dmabuf at all, giving the
client an opportunity to try something else.
That's exactly what I meant with pushing back :)
I wasn't aware that this handling is already implemented.
Well... it's "optional". The Wayland dmabuf protocol has two cases for
a client/app:
a) you do the right thing and wait for the compositor to ack that the
dmabuf works (the reply should come pretty much immediately, not
needing the compositor to actually composite), or
b) you just send the dmabuf and continue as if it always worked. If it
doesn't, you might get a protocol error later and be disconnected.
Guess which one Mesa uses?
I've been told Mesa has no way to handle a failure there, so it
doesn't. I would not be surprised if others just copy that behaviour.
I recall personally being against adding option b) to begin with, but
there it is, added for Mesa IIRC.
Well I'm not sure if those projects actually used X or Wayland, but we
did had cases where this was really used.
IIRC in the case of Prime offloading we now allocate a buffer from the
displaying device in Mesa and do the copy from the rendering GPU to the
displaying GPU on the client side.
The background is that this gave us much better control which engine and
parameters where used for the copy resulting in a nice performance
improvement.
Regards,
Christian.
