2023 Updates_on_accelerated_compositing_in_WebKitGTK
- Date: 6th June 2023
- Issue: https://github.com/Igalia/webengineshackfest/issues/18
The session starts with a quick introductions of the participants
Carlos gives a presentation on the history of accelerated compositing in WebKitGTK. Link to the slides: https://notes.igalia.com/p/3AG5PqBJx#/
Carlos presents some challenges found using dmabuf for AC in the WebKitGTK context.
Carlos mentions the current dmabuf-based implementation is using two buffers, but it doesn't seem to be enough. When doing the swapbuffer after the buffer is rendered in the webview, the backbuffer might not available in time for the WebProcess to start rendering. We're exploring using three buffers to overcome this.
Discussion
Alex: What's your opinion of integration of WPE and WebKitGTK. Will we be able to share mode code?
Carlos: Yes, moving to use wpe renderer was a step in this direction, and the dma-buf approach is also something that might become shared between both ports. One issue is the large number of configurations that WebKitGTK needs to support, for example, GTK3 vs GTK4, X11 vs Wayland, etc. It would be great if we could get rid of the XComposite code path, for example.
Pablo: A question about the three-buffer approach. In WPE, we're using the nested compositor in the middle, and the buffers are created .... Do you have a clear picture of how this three buffer implementation will look like in WebkitGTK?
Carlos: There's a patch for that. In the case of the nested compositor, probably there wayland is already using two or three buffers, likely provided by wayland. The three buffers are ..., when we swap, ....
Pablo: So the buffer lifetime will be managed by the WebProcess?
Carlos: Yes, the WebProcess creates the buffers. There's an IPC message to configure the buffer paramenters. From that moment, the buffers are synchronized between the processes. When the buffer is swapped, the UIProcess is notified to do the same operation.
Pablo: And the ...
Carlos: There's the 'configure' message, the 'frame' message, .... There's a message 'frame-rendered' sent from the UIProcess to the WebProcess, telling the WebProcess can start rendering the next frame.
Enrique: Will legacy features like X11 window forwarding through ssh be still supported?
Carlos: Yes, because it relies in the UIProcess. The graphics are rendered in the Web/GPUProcess, but then forwarded to the UIProcess, and if it decides to dump that to memory and make it available for ssh X11 forwarding, that's perfectly possible.
Niko: About the multiple code paths, is it correct that we aren't automatically testing all those code paths?
Carlos: Yes, even before dma-buf this has been a problem.
Niko: Do you foresee any way we could test those configurations?
Carlos: The bots used for layout tests don't even have a GPU. That's why software rasterization is being used on them. Also because in that way we're not depending on specific GPU models. But it's true that we're not currently testing the accelerating drawing paths that real people uses on their machines. There's also the issue with inconsistent tests, in the sense of managing the varying expectations between those configurations. We're also leveraging development releases to let people out there test new code by themselves. But we don't have layout tests testing that.
Niko: ...
Clopez: Could we use this new GBM codepath in the bots? We only would need to have a render node. There's a GBM driver in the kernel that would allow us to do that, instead of using SHM. That way we could have layout tests running with accelerated compositing code.
Niko: We have a baseline in SVG that renders fine on one bot but fails on others (different pixels). It's completely caused by hardware. We're giving up on pixel tests because of that. But maybe GBM(?) would be a solution to that.
Clopez: If we have this solution deployed, we can maybe remove the surfaceless code path(?)
Carlos: Do we want to support some codepahts only for testing or in general? Because right now, if you build WebKitGTK with <>, it works, not efficiently, but works.
Clopez: Some users like FreeBSD may not be able to use the GBM path, or other hardware-related drivers/codepaths.
Carlos: These are two unrelated problems. One problem is supporting swrast, other is supporting platforms without GBM, dma-buf, etc. In the latter, it's a matter of not using a given technique, but they're still using the GPU with Angle, for example. In the former, we won't be using a GPU at all.
Alex: We would like to test what the actual people uses on their machines. Maybe we can ask people in the community what and how they are using.
Carlos: In the case of GTK, there's the non-accelerated compositing mode. People can just disable hw acceleration and they would be getting the sw rasterization. If we want to support those use cases in WPE, we would need to add sw rasterization there too.
Niko: What about running the tests with an emulated GPU?
Clopez: Qemu with emulated GPU would add more overhead and we would need to be aware of memory usage too. We could also explore some options of servers with GPU for the bots.
Niko: It's just a matter of throwing more money and development resources to the problem.
Pablo: Good point. Many times we're struggling, and thinking about creative ways to solve problems (even if not optimal), can be a good compromise. Developer time is the most expensive resource.
Alex: If some user comes asking for swrast, we can just point them to the alternative we use on those platforms not supporting accelerated compositing. In any case, we should reduce the amount of codepaths we support.
Clopez: If we used virtual hw, at least everybody would have the same environment to test.
Niko: About X11 stuff,
Could we move out of the GLX architecture and use only the one that has direct compositing(?)?
Carlos: I don't know in this case. It's actually GTK the one creating the context with GLX. The problem here is when GTK is using GTX, which is the case in GTK3 and sometimes GTK4, we are actually downloading and uploading the buffers again.
Carlos: I don't know if it would be a possibility to reduce the amount of codepaths, if there's the possibility to create the dma-buf, but targeting shared memory and not an traditional DMA buffer? In the case when we're downloading the texture, it may be downloaded into a dmabuf instead of as a texture. This could improve the case of importing those buffers.
Niko: I saw something about it in the context of networking(?)
Pablo: Closing the session now.