4 ms·

The backing buffers are not so much copied as shared. A client application allocates backing surfaces (wl-egl does this for you for simple cases) and renders i

The backing buffers are not so much copied as shared. A client application allocates backing surfaces (wl-egl does this for you for simple cases) and renders into them. When you call swap buffers, it sends a handle to the client's backing surface to the server via IPC. Honestly that's one of the most amazing things about wayland, or more specifically the improvements in the Linux graphics stack over the last decade. Offscreen rendering is now implicitly supported, along with being able to share references to buffers on hardware devices between processes, rather than something like ANGLE, where the opengl commands themselves were sent between processes.

theamk 6y ago
Right, the client->compositor buffer is shared. But unless you are running a full screen app, at some point compositor will have to take all those pixels from the window's backing buffer and blit them into framebuffer, moving millions of pixels every frame. This is something that really needs video acceleration. It works today, but it would not be feasible in the past, where some people still had to rely on VESA card interfaces.
- sprash 6y ago
  I would assume that there is a proper damage protocol in place that would move a "millions of pixels" only when there is an actual change. The only way to avoid that is to give applications direct access to the front buffer and use a stecil buffer or some form of masks to prevent applications from drawing above each other.
- formerly_proven 6y ago
  Modern graphics hardware can composite multiple buffers at scan-out time (which does not consume extra memory bandwidth), but it's not clear to me whether anyone besides perhaps DWM uses that.
  - vetinari 6y ago
    Multiple means about 4 (that's the number for Skylake & Kabylake gen Intel), and one of them is cursor plane. There might be also misc limitation regarding overlaps, so it might not be generally usable. Android in the earlier years used it for the notification area, as it basically split the screen vertically when the notification shade was moved. Additionally, these buffers can be scaled at scan-out time. So what it is used for is emulating lower resolutions for Xrandr clients under XWayland (Wayland doesn't allow to switch resolutions to random apps). Under MacOS, scaling at scan-out time is used for fractionally scaling of the entire framebuffer without using GPU.
  - Teknoman117 6y ago
    I was under the impression that it was mostly the mobile GPUs that supported blending a large number of planes at scanout time. I've written software for random ARM SoCs where there were a dozen planes or so that you had to program the ordering and bounds of. The first was typically the default framebuffer, another was the cursor, two were the outputs of the hardware video decoders, and the rest were up to the application developer to use. The big desktop GPUs seem to only have the standard framebuffer, a cursor plane, and a small number (<= 2) of overlay planes. It seems that the general consensus is that they tend to have such a ridiculous amount of horsepower that rendering everything into an output buffer and displaying that won't even kick the GPU out of its idle power state. That being said, I had a few hours of fun hacking glxgears and glmark2 to render into the cursor plane on Wayland.
jcelerier 6y ago
It only comes 15 years after win32 and macOS which both allowed to share graphics card buffers across processes for a loooong time (check out Spout and Syphon for one of the main usage of this tech)
- Teknoman117 6y ago
  Exactly. This is why I was so happy about it. It was a pattern I was familiar with on macOS (IOSurface) and I'd known Windows had it. I'd noticed at the time that Chrome used ANGLE (a framework to present an OpenGL ES interface on top of a different graphics framework at runtime with the option of going interprocess) so that the tab sandbox processes could draw into the GPU sandbox process, I was curious why (at least for macOS) that they weren't rendering into an IOSurface and sharing the handle to the other processes (The answer being to use the lowest common denominator of features across the platforms you want to support). By comparison, the state of 3D acceleration was sad on Linux. You couldn't touch your fancy GPU without an X server running. Even if wayland itself fails as a successor to Xorg, the work that was done to separate the graphics drivers, 3D stack, and buffer management from being a monolithic plugin to Xorg was well worth the time investment.

theamk 6y ago

Right, the client->compositor buffer is shared. But unless you are running a full screen app, at some point compositor will have to take all those pixels from the window's backing buffer and blit them into framebuffer, moving millions of pixels every frame. This is something that really needs video acceleration. It works today, but it would not be feasible in the past, where some people still had to rely on VESA card interfaces.

sprash 6y ago
I would assume that there is a proper damage protocol in place that would move a "millions of pixels" only when there is an actual change. The only way to avoid that is to give applications direct access to the front buffer and use a stecil buffer or some form of masks to prevent applications from drawing above each other.
formerly_proven 6y ago
Modern graphics hardware can composite multiple buffers at scan-out time (which does not consume extra memory bandwidth), but it's not clear to me whether anyone besides perhaps DWM uses that.
- vetinari 6y ago
  Multiple means about 4 (that's the number for Skylake & Kabylake gen Intel), and one of them is cursor plane. There might be also misc limitation regarding overlaps, so it might not be generally usable. Android in the earlier years used it for the notification area, as it basically split the screen vertically when the notification shade was moved. Additionally, these buffers can be scaled at scan-out time. So what it is used for is emulating lower resolutions for Xrandr clients under XWayland (Wayland doesn't allow to switch resolutions to random apps). Under MacOS, scaling at scan-out time is used for fractionally scaling of the entire framebuffer without using GPU.
- Teknoman117 6y ago
  I was under the impression that it was mostly the mobile GPUs that supported blending a large number of planes at scanout time. I've written software for random ARM SoCs where there were a dozen planes or so that you had to program the ordering and bounds of. The first was typically the default framebuffer, another was the cursor, two were the outputs of the hardware video decoders, and the rest were up to the application developer to use. The big desktop GPUs seem to only have the standard framebuffer, a cursor plane, and a small number (<= 2) of overlay planes. It seems that the general consensus is that they tend to have such a ridiculous amount of horsepower that rendering everything into an output buffer and displaying that won't even kick the GPU out of its idle power state. That being said, I had a few hours of fun hacking glxgears and glmark2 to render into the cursor plane on Wayland.

jcelerier 6y ago

It only comes 15 years after win32 and macOS which both allowed to share graphics card buffers across processes for a loooong time (check out Spout and Syphon for one of the main usage of this tech)

Teknoman117 6y ago
Exactly. This is why I was so happy about it. It was a pattern I was familiar with on macOS (IOSurface) and I'd known Windows had it. I'd noticed at the time that Chrome used ANGLE (a framework to present an OpenGL ES interface on top of a different graphics framework at runtime with the option of going interprocess) so that the tab sandbox processes could draw into the GPU sandbox process, I was curious why (at least for macOS) that they weren't rendering into an IOSurface and sharing the handle to the other processes (The answer being to use the lowest common denominator of features across the platforms you want to support). By comparison, the state of 3D acceleration was sad on Linux. You couldn't touch your fancy GPU without an X server running. Even if wayland itself fails as a successor to Xorg, the work that was done to separate the graphics drivers, 3D stack, and buffer management from being a monolithic plugin to Xorg was well worth the time investment.