Buffer Damage

[Pekka Paalanen]

On Mon, 4 Jan 2021 13:23:26 +0200
Vlad Zahorodnii <vlad.zahorodnii at kde.org> wrote:

> Hi,
> 
> I've noticed that uploading data from shared client memory buffers to 
> textures hurts performance really bad in kwin. Sometimes, it takes about 
> 40ms to attach a client buffer to a texture. Since most compositors 
> don't take any precautions of uploading the buffer data asynchronously, 
> you may also experience this problem with weston, sway, etc.

Hi,

yes, I know this theoretical issue exists in Weston in the worst
form (does not use even PBOs), but this is the first time someone
actually raises the issue.

Could you tell more about in what kind of situation you see such
long time spent in texture uploads?

Maybe a 4K fullscreen window as wl_shm? What window size, how many
bytes per frame? What hardware platform? CPU and GPU?

Have you profiled this, where is the time spent inside GL(?) driver?
Is CPU busy or idle? If CPU is busy, is it doing a pixel format
conversion or just a memcpy()?

Is the client doing something strange with the buffers? Like
feeding dmabufs via wl_shm? Maybe allocated by V4L2? Is it possible
the buffers are hitting disk (possible if using files on not tmpfs
and not memfd)?

Could it be that kwin is not doing partial texture uploads for some
reason and instead always uploads the full image?

I'd like to rule out the need to fix drivers, the compositor, or
clients first before buying into to adding proper buffer damage.
Adding buffer damage is technically not a problem, we just need a
new global interface to extend wl_buffer interface. wl_buffer itself
cannot be extended, because it is forever stuck at version
"whatever", i.e. 1.

Did you also consider the memory cost in the compositor having to
duplicate each wl_buffer instead of just the wl_surface? Are you
really willing to pay that price?

Or, could a more elaborate solution work? Like, maintaining two
textures per wl_surface in the compositor instead of one texture
per wl_buffer? You would use one texture for compositing
(surface front texture) and the other texture for uploading from
wl_shm (surface back texture), then swap when the upload completes.
This would not need to add buffer damage in the protocol, you could
do with surface damage only, and you could always do minimal partial
updates, first from front to back to bring the back texture
up-to-date (GPU-accelerated?), and then upload the client changes
to the back texture before swapping.

Or, with the surface front and back textures, you just always blit
from the back texture to the front texture after the upload
finishes and never swap them to avoid the update-back step?


Thanks,
pq
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20210107/305fe366/attachment.sig>