Bug 267578 – [GTK] WebView empty with GTK Vulkan renderer

• Component: WebKitGTK
• Status: RESOLVED FIXED

[Kdwk]

GTK has a new unified GPU renderer with two options -- ngl and vulkan. They can be tested when running Epiphany Technology Preview with the environment variable GSK_RENDERER=ngl or GSK_RENDERER=vulkan. When the latter is applied, WebViews are empty.

Epiphany Technology Preview 46.alpha-1-gcdc325ea9+/ WebKitGTK 2.43.3

[Benjamin Otte]

Repeating what I wrote in the related GTK bug in https://gitlab.gnome.org/GNOME/gtk/-/issues/6354#note_1984647:

I think this is an issue with syncing. Vulkan and GL probably use different GPU queues, and I suspect Ephy doesn't set a GLSync on the GLTexture.
And then the Vulkan code starts blitting the teture before the GL code is done drawing it.

Note that for me (on my Intel laptop with F39 Ephy), the WebView isn't empty, but it tends to be incomplete with either the bottom missing or some images not yet rendered.

Setting a breakpoint it seems that F39 Ephy uses gdk_gl_texture_new() and not the texture builder, and that doesn't even allow passing sync objects.
It also seems Ephy uses dmabufs, so it should probably use GdkDmabufTextureBuilder - note that dmabufs carry sync information explicitly, but I have no idea if Ephy's dmabufs are setup properly with them.

[Benjamin Otte]

I just realized that as Epiphany is using GL textures, the Vulkan renderer (for now) will use the same code path as the Cairo renderer would and glReadPixels()/glGetTexImage() the texture. So even if it worked (and it's a mystery even to Mesa people who I've been asking on IRC), this code path would be slow on Vulkan.

But that would also be fixed via use of GdkDmabufTextureBuilder.

[Carlos Garcia Campos]

I plan to use the new GTK4 API to build the texture, but we can't bump the GTK4 requirement, so we need to keep the old code for a while.

[Benjamin Otte]

I know why this fails.

You call gdk_gl_texture_new() only once. The Vulkan and Cairo renderer then make a copy of the texture and cache it. And because GDK textures are guaranteed to never change, they do not update that copy ever and reuse the cache.

You must not:
1. Update the dmabuf until the GdkTexture was freed (use the destroy notify for that).
2. Use the same GdkTexture multiple times with different contents (that really follows from (1)).

The reason why this looks like it fails entirely and that tripped me up is that the first time you use that texture the page isn't loaded yet so GTK sees (and caches) an empty buffer.

[Carlos Garcia Campos]

hmm, will not that affect the performance if we have to create/destroy texture on every frame?

[Benjamin Otte]

A GdkTexture is just a small wrapper object that refers to some memory holding pixels and includes a promise that the memory will not be modified until the texture releases the memory via its destroy notify.

The thing you don't want to recreate is the actual dmabuf fd, but creating a new texture is what you need to do - because it refers to different pixels now.

[Carlos Garcia Campos]

Pull request: https://github.com/WebKit/WebKit/pull/23497

[Carlos Garcia Campos]

(In reply to Carlos Garcia Campos from comment #7)
> Pull request: https://github.com/WebKit/WebKit/pull/23497

This does what GTK expects, I hope. It fixes the rendering with vulkan, but it's indeed super slow. I plan to submit a follow up PR to use the new dmabuf texture builder api.

[Benjamin Otte]

The performance in GL is still roughly the same, right?

[Carlos Garcia Campos]

(In reply to Benjamin Otte from comment #9)
> The performance in GL is still roughly the same, right?

Right, at least in my laptop the impact of creating and destroying the GL textures and GdkTextures is not noticeable.

[Carlos Garcia Campos]

With dmabuf texture builder and vulkan it's still super slow.

[Benjamin Otte]

That might be because you're using a dmabuf format/modifier combo that the Vulkan driver doesn't support. GTK will then fall back to local CPU copies. GDK_DEBUG=dmabuf should tell you what's going on.

Getting Vulkan to play nice with dmabufs requires slightly different steps than GL, and it might just be that Webkit is not getting them right.  
I'm no expert on that part though. The biggest difference is that Vulkan does require dmabufs to have modifiers or it will reject them, but skimming the WebKit codebase it looks like modifiers are handled fine.

[Carlos Garcia Campos]

Initialized support for 373 dmabuf formats
Creating dmabuf texture, format AR24:0x100000000000008,  premultiplied, 3 planes, memory format 0, downloader GskGLRenderer
FIXME: Add support for disjoint dmabufs to Vulkan
Importing dmabuf (format: AR24:0x100000000000008, planes: 3) into GL
Imported 2048x1386 AR24:0x100000000000008 dmabuf as GL_TEXTURE_2D texture

[Carlos Garcia Campos]

Using WEBKIT_DMABUF_RENDERER_BUFFER_FORMAT=AR24:0 which forces AR24 with linear modifier makes it work much better indeed

Vulkan uploaded 2048x1386 AR24::0000000000000000 dmabuf
Creating dmabuf texture, format AR24:0,  premultiplied, 1 planes, memory format 0, downloader none

[Benjamin Otte]

What hardware are you using there?

I didn't implement the disjoint stuff because both my AMD and Intel driver claimed it couldn't do them (It didn't set VK_FORMAT_FEATURE_DISJOINT_BIT on the VkFormatProperties of the formats) and I had no way to test.

[Carlos Garcia Campos]

Intel Corporation Raptor Lake-P [Iris Xe Graphics]

[Benjamin Otte]

Could you try if https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/6830 fixes things for you?

[Carlos Garcia Campos]

(In reply to Benjamin Otte from comment #17)
> Could you try if https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/6830
> fixes things for you?

Fixes the warning, but the format is still reported as unsupported.

Creating dmabuf texture, format AR24:0x100000000000008,  premultiplied, 3 planes, memory format 0, downloader GskGLRenderer
Vulkan driver does not support format AR24::0100000000000008 with 3 planes
Importing dmabuf (format: AR24:0x100000000000008, planes: 3) into GL
Imported 2048x1386 AR24:0x100000000000008 dmabuf as GL_TEXTURE_2D texture

[Benjamin Otte]

Does the format dump at the top have a line like:

Vulkan supports dmabuf format AR24::0100000000000008 with 3 planes and features 0x1dd81

It does on my TigerLake with Mesa main.

[Carlos Garcia Campos]

Vulkan supports dmabuf format AR24::0000000000000000 with 1 planes and features 0x1dd83
Vulkan supports dmabuf format AR24::0100000000000001 with 1 planes and features 0x1dd83
Vulkan supports dmabuf format AR24::0100000000000002 with 1 planes and features 0x1dd83
Vulkan supports dmabuf format AR24::0100000000000006 with 2 planes and features 0x1dd81

Those are the AR24 ones listed there

[Benjamin Otte]

That does indeed look like this is a driver issue then and your libgbm and EGL do support that format but Vulkan does not.

The fun with 2 graphics APIs...

But it seems to work otherwise, so I'm gonna merge that GTK fix and once that and your DmabufTexture fixes and the new Intel driver arrive, this is going to just work.

[Benjamin Otte]

Just realized that you're using AR24 as the format - is there a reason you're not using XR24? Can webpages be transparent?

I'm asking because XR24 is more suitable for the Graphics Offload I filed https://gitlab.gnome.org/GNOME/epiphany/-/issues/2274 about.

[Carlos Garcia Campos]

(In reply to Benjamin Otte from comment #22)
> Just realized that you're using AR24 as the format - is there a reason
> you're not using XR24? Can webpages be transparent?
> 
> I'm asking because XR24 is more suitable for the Graphics Offload I filed
> https://gitlab.gnome.org/GNOME/epiphany/-/issues/2274 about.

Yes, we prefer formats with alpha because the web view can have a transparent background. But we could try to be smarter and actually check the current web view color to decide the format. That means we need to change the buffer formats if the web view background color changes.

[EWS]

Committed 273818@main (93cc2e901af9): <https://commits.webkit.org/273818@main>

Reviewed commits have been landed. Closing PR #23497 and removing active labels.

[Benjamin Otte]

The reason I was asking is because offloading and in particular direct scanout in compositors can only directly scan out from opaque buffers. Otherwise GTK/the compositor has to composite the image with the background first.

And the way both of those decide if a buffer is opaque is by looking at the format.

With work like https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2660 going on it would mean that every maximized webpage could be directly sent to the kernel, though I think that work doesn't strictly require opaqueness on modern GPUs.

In any case, I think it's a worthwhile thing to investigate.