We need GPU process on Wayland to use VAAPI outside content process so let's create one.

Short reminder that there's one possible alternative: bug 1731890. Just for the record.

Quote from matrix:

gerard-majax: I'm not sure exactly about VA-API specifically, but the plan is to have such a utilityprocess that can be used by different actors, and each with a specific sandboxing
and from that discussion, I think the first customer might be moving RDD audio decoders to this new

The GPU process can cooperate with the utility one. I guess we want to have GPU on Wayland anyway.

If the goal is to move compositing out of the parent process, then the utility process project isn't really relevant. The original purpose of the GPU process (as I understand it) was to allow recovering from GPU driver bugs that crash the process, so that might be useful in general.

But, as a substitute for having an “RDD but with GPU access” process:

1. We could just give the RDD process GPU access, as long as it's the specifics aren't too unreasonable; it's not running hostile script so it's harder to attack than a content process.
2. The utility process project does matter, because it will eventually let us run codecs that need GPU access in a different process from those that don't.

eglCreatePlatformWindowSurfaceEXT may be a way how to implement it (EGL rendering to offscreen dmabuf surface).

(In reply to Martin Stránský [:stransky] (ni? me) from comment #4)

eglCreatePlatformWindowSurfaceEXT may be a way how to implement it (EGL rendering to offscreen dmabuf surface).

FWIW, that's AFAIK what Wine-Wayland devs currently explore as well (and AFAIK is used in Chrome-Wayland). Note that, as we'll not use the EGL-Wayland platform any more for buffer handling, we'll have to do extra work if we want to keep e.g. direct-scanout/dmabuf feedback capabilities and stuff like that.

(In reply to Robert Mader [:rmader] from comment #5)

FWIW, that's AFAIK what Wine-Wayland devs currently explore as well (and AFAIK is used in Chrome-Wayland). Note that, as we'll not use the EGL-Wayland platform any more for buffer handling, we'll have to do extra work if we want to keep e.g. direct-scanout/dmabuf feedback capabilities and stuff like that.

What do you mean with EGL-Wayland platform?

(In reply to Martin Stránský [:stransky] (ni? me) from comment #6)

What do you mean with EGL-Wayland platform?

Essentially the Wayland specific methods like wl_egl_window_create() from <wayland-egl.h> and the buffer handling in https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/src/egl/drivers/dri2/platform_wayland.c. Or rather: the abstraction that EGL does over the Wayland protocols so we can just use eglMakeCurrent()/eglSwapBuffer() and don't need to call wl_surface_attach()/wl_surface_commit() and handle buffers/the swapchain.

That's what you plan, right? Attaching/committing the dmabuf-buffers to surfaces manually in the main process?

We need to create offscreen rendering target in GPU process based on dmabuf somehow and then transfer that to main process. How is the dmabuf rendered in main process is another question. The wl_surface_attach / wl_surface_commit may be better than another blit to wl_egl_window.

Sorry, there was a problem with the detection of inactive users. I'm reverting the change.

(In reply to Martin Stránský [:stransky] (ni? me) from comment #0)

We need GPU process on Wayland to use VAAPI outside content process so let's create one.

To update this bug: we were able to support VA-API by using the RDD process, and it wasn't necessary to let it connect to the display server (bug 1769499).

AFAIK if we want to go this way on Linux/Wayland we can use what we have already implemented for WebGL where shared dmabuf surfaces are used for remote GL rendering.