Bugzilla

If Dmabuf screen sharing isn't used to achieve zero copy somewhere, then it has no performance benefit over MemFD screen sharing, right?
In my understanding there would be no point to use the dmabuf code path unless it is wired up to be used for zero-copy presentation in egl hardware rendering (like egl dmabuf webgl/vaapi are used).
That's how I understand comment 26.

comment 43:
On Wayland you can be running as Xwayland or as Wayland and if you use EGL without display connection, you might end up using the wrong gpu or wrong egl implementation:

bug 1769499: Firefox ran as native Wayland app on Nvidia (MOZ_ENABLE_WAYLAND=1 env var, enabled by default on Firefox Nightly)
- used headless egl (it was actually Nvidia's X11 EGL implementation) in RDD process to make EGLImage from vaExportSurfaceHandle
- tried to use X11-EGL EGLImage in Wayland-EGL hardware rendering and failed.
- Workaround was running Firefox with EGL_PLATFORM=wayland nvidia driver environment variable.

bug 1773377: Firefox ran as native Wayland app on Nvidia while also having an Intel GPU
- used egl surfaceless platform (which defaults to renderD128: Intel in this case) in RDD process to make EGLImage from vaExportSurfaceHandle
- tried to use EGLImage (from Intel GPU) in Wayland-EGL hardware rendering on Nvidia GPU and failed.
- Fixed by using egl device platform with correct device in RDD process (/dev/dri/renderD129 can be obtained from EGL_DRM_DEVICE_FILE_EXT from EGL context with display connection and be compared with EGL_DRM_RENDER_NODE_FILE_EXT from enumerated devices)

Overview of combinations supported by Firefox:

| platform | WebRender type | WebGL type | hw decoding¹ | for which drivers² |
| --- | --- | --- | --- | --- |
| wayland (enabled on nightly) | egl hardware rendering | egl dmabuf webgl | egl dmabuf vaapi | mesa >= 17 (since bug 1818992), nvidia > 530.30.02 |
| wayland (enabled on nightly) | egl hardware rendering | egl webgl (copy) | - | nvidia >= 470.82 |
| wayland (enabled on nightly) | software rendering | egl webgl (copy) | - | mesa < 17, nvidia < 470.82 |
| x11 & xwayland | egl hardware rendering | egl dmabuf webgl | egl dmabuf vaapi | mesa >= 17,  nvidia > 530.30.02 |
| x11 & xwayland | egl hardware rendering | egl webgl (copy) | - | nvidia >= 470.82 |
| x11 & xwayland | glx hardware rendering | glx webgl (copy) | - | - |
| x11 & xwayland | software rendering | egl webgl (copy) | - | - |
| x11 & xwayland | software rendering | glx webgl (copy) | - | mesa < 17, nvidia < 470.82  |

¹) based on vaExportSurfaceHandle: Enabled on nightly with mesa>=21, can be manually enabled for older mesa or nvidia-vaapi-driver.
²) nouveau, xwayland and arm64 have slightly different rules

If Dmabuf screen sharing isn't used to achieve zero copy somewhere, then it has no performance benefit over MemFD screen sharing, right?
In my understanding there would be no point to use the dmabuf code path unless it is wired up to be used for zero-copy presentation in egl hardware rendering (like egl dmabuf webgl/vaapi are used).
That's how I understand comment 26.

comment 43:
On Wayland you can be running as Xwayland or as Wayland and if you use EGL without display connection, you might end up using the wrong gpu or wrong egl implementation:

bug 1769499: Firefox ran as native Wayland app on Nvidia (MOZ_ENABLE_WAYLAND=1 env var, enabled by default on Firefox Nightly)
- used headless egl (it was actually Nvidia's X11 EGL implementation) in RDD process to make EGLImage from vaExportSurfaceHandle
- tried to use X11-EGL EGLImage in Wayland-EGL hardware rendering and failed.
- Workaround was running Firefox with EGL_PLATFORM=wayland nvidia driver environment variable.

bug 1773377: Firefox ran as native Wayland app on Nvidia while also having an Intel GPU
- used egl surfaceless platform (which defaults to renderD128: Intel in this case) in RDD process to make EGLImage from vaExportSurfaceHandle
- tried to use EGLImage (from Intel GPU) in Wayland-EGL hardware rendering on Nvidia GPU and failed.
- Fixed by using egl device platform with correct device in RDD process (/dev/dri/renderD129 can be obtained from EGL_DRM_DEVICE_FILE_EXT from EGL context with display connection and be compared with EGL_DRM_RENDER_NODE_FILE_EXT from enumerated devices)

Overview of combinations supported by Firefox:

| platform | WebRender type | WebGL type | hw decoding¹ | for which drivers² |
| --- | --- | --- | --- | --- |
| wayland (enabled on nightly) | egl hardware rendering | egl dmabuf webgl | egl dmabuf vaapi | mesa >= 17, nvidia > 530.30.02 |
| wayland (enabled on nightly) | egl hardware rendering | egl webgl (copy) | - | nvidia >= 470.82 |
| wayland (enabled on nightly) | software rendering | egl webgl (copy) | - | mesa < 17, nvidia < 470.82 |
| x11 & xwayland | egl hardware rendering | egl dmabuf webgl | egl dmabuf vaapi | mesa >= 17 (since bug 1818992),  nvidia > 530.30.02 |
| x11 & xwayland | egl hardware rendering | egl webgl (copy) | - | nvidia >= 470.82 |
| x11 & xwayland | glx hardware rendering | glx webgl (copy) | - | - |
| x11 & xwayland | software rendering | egl webgl (copy) | - | - |
| x11 & xwayland | software rendering | glx webgl (copy) | - | mesa < 17, nvidia < 470.82  |

¹) based on vaExportSurfaceHandle: Enabled on nightly with mesa>=21, can be manually enabled for older mesa or nvidia-vaapi-driver.
²) nouveau, xwayland and arm64 have slightly different rules

If Dmabuf screen sharing isn't used to achieve zero copy somewhere, then it has no performance benefit over MemFD screen sharing, right?
In my understanding there would be no point to use the dmabuf code path unless it is wired up to be used for zero-copy presentation in egl hardware rendering (like egl dmabuf webgl/vaapi are used).
That's how I understand comment 26 + comment 65.

comment 43:
On Wayland you can be running as Xwayland or as Wayland and if you use EGL without display connection, you might end up using the wrong gpu or wrong egl implementation:

bug 1769499: Firefox ran as native Wayland app on Nvidia (MOZ_ENABLE_WAYLAND=1 env var, enabled by default on Firefox Nightly)
- used headless egl (it was actually Nvidia's X11 EGL implementation) in RDD process to make EGLImage from vaExportSurfaceHandle
- tried to use X11-EGL EGLImage in Wayland-EGL hardware rendering and failed.
- Workaround was running Firefox with EGL_PLATFORM=wayland nvidia driver environment variable.

bug 1773377: Firefox ran as native Wayland app on Nvidia while also having an Intel GPU
- used egl surfaceless platform (which defaults to renderD128: Intel in this case) in RDD process to make EGLImage from vaExportSurfaceHandle
- tried to use EGLImage (from Intel GPU) in Wayland-EGL hardware rendering on Nvidia GPU and failed.
- Fixed by using egl device platform with correct device in RDD process (/dev/dri/renderD129 can be obtained from EGL_DRM_DEVICE_FILE_EXT from EGL context with display connection and be compared with EGL_DRM_RENDER_NODE_FILE_EXT from enumerated devices)

Overview of combinations supported by Firefox:

| platform | WebRender type | WebGL type | hw decoding¹ | for which drivers² |
| --- | --- | --- | --- | --- |
| wayland (enabled on nightly) | egl hardware rendering | egl dmabuf webgl | egl dmabuf vaapi | mesa >= 17, nvidia > 530.30.02 |
| wayland (enabled on nightly) | egl hardware rendering | egl webgl (copy) | - | nvidia >= 470.82 |
| wayland (enabled on nightly) | software rendering | egl webgl (copy) | - | mesa < 17, nvidia < 470.82 |
| x11 & xwayland | egl hardware rendering | egl dmabuf webgl | egl dmabuf vaapi | mesa >= 17 (since bug 1818992),  nvidia > 530.30.02 |
| x11 & xwayland | egl hardware rendering | egl webgl (copy) | - | nvidia >= 470.82 |
| x11 & xwayland | glx hardware rendering | glx webgl (copy) | - | - |
| x11 & xwayland | software rendering | egl webgl (copy) | - | - |
| x11 & xwayland | software rendering | glx webgl (copy) | - | mesa < 17, nvidia < 470.82  |

¹) based on vaExportSurfaceHandle: Enabled on nightly with mesa>=21, can be manually enabled for older mesa or nvidia-vaapi-driver.
²) nouveau, xwayland and arm64 have slightly different rules