Bug 83985

Do we need an option (for example `--device') to override default render node? Or it will be sufficient if we'll use the first working one using similar logic as in Mesa surfaceless EGL platform?
http://cgit.freedesktop.org/mesa/mesa/tree/src/egl/drivers/dri2/platform_surfaceless.c#n92

(In reply to Dawid Gajownik from comment #1)
> Do we need an option (for example `--device') to override default render
> node?

I suppose it wouldn't hurt, but it's also easy to add later. To have our 'make check' just work on usual setups we should probably start the implementation with the first working render node. That way you can leave plumbing the render node choice through our testing harness for later.

I think I have a working code now, but I'm still not sure how to test it. At least buffer-count-test and internal-screenshot-test works fine with a new renderer.

Before writing a new test (it will take some time because everything is new to me and I have to learn almost everything) I have a question regarding dependencies. Now headless-backend.so requires EGL (gl-renderer.so dependency), libudev and libgbm. Should `./configure --disable-egl' disable whole headless-backend or only new rendernode-gl renderer (#ifdef new code)?

(In reply to Dawid Gajownik from comment #3)
> I think I have a working code now, but I'm still not sure how to test it. At
> least buffer-count-test and internal-screenshot-test works fine with a new
> renderer.

That's excellent news! I believe that already verifies that a) wl_shm clients are rendered properly, and b) EGL-support is initialized correctly.

All that's left to test of the very basics is that hw-accelerated clients get composited correctly, similar to the internal-screenshot-test.

We will want to run all headless backend tests with the Pixman renderer by default, and if EGL is enabled, re-run the screenshot and EGL related tests with the gl-renderer. I'm not sure how easy that is with the current test harness, and the new test harness is still lacking the client helpers and could use converting buffer-count-test and internal-screenshot-test over before it's clear how to do this. So that may need to wait for later. Or maybe you already implemented this?

Even if we just use the gl-renderer on headless by default when --enable-egl, I think that would still be an improvement for short term. Long term we really want to test both renderers.

Note, that there could be some complications from running 'make check BACKEND=x11-backend.so' and similar, since we want to be able to run make check with also other backends. Although in the future with the new test harness, I suppose we'd be listing x11-backend etc. tests separately, rather than running the whole test suite with a certain backend. There are many open questions there.

> Before writing a new test (it will take some time because everything is new
> to me and I have to learn almost everything) I have a question regarding
> dependencies. Now headless-backend.so requires EGL (gl-renderer.so
> dependency), libudev and libgbm. Should `./configure --disable-egl' disable
> whole headless-backend or only new rendernode-gl renderer (#ifdef new code)?

--disable-egl should definitely only disable the gl-renderer part, not headless altogether.

I don't think we should have it as a build time option only, either. Of course, --disable-egl prevents gl-renderer from being built, but linking it in should be a runtime option.

You can check compositor-drm.c, it already has a switch between the GL and Pixman renderers. It even has code to switch from Pixman to GL renderer at runtime, but I don't think that's useful for headless (except perhaps for testing that exact feature).

I'd like to see your code to see what you use libudev and libgbm for. Ideally, headless backend would not link to anything more than it does right now upstream, even with --enable-egl but gl-renderer not used at runtime. OTOH, I don't want to clutter headless backend with dlopen()'ing libudev and whatnot.

I suppose you use libudev to find the render node? I think that could be replaced with EGL_EXT_device_base and EGL_EXT_device_drm extensions, which are WIP for Mesa still: http://lists.freedesktop.org/archives/mesa-dev/2015-July/089783.html

Are you using the EGL surfaceless platform or GBM platform? Could using the surfaceless platform remove the direct link from headless backend to libgbm?

Oh, I suppose our gl-renderer API does not account for rendering into an FBO off-screen. It always requires an EGLNativeWindowType to create an EGLSurface for. Do you know if there is anything we could pass in with surfaceless to get a working EGLSurface, or would it always force us to use an FBO because the EGLSurface is a dummy?

Anyway, these are just rough plans forward. For the moment, I am happy to just link headless-backend.so with libudev and libgbm when --enable-egl is configured. However, I would like gl-renderer.so to be dlopen()'d only when asked with the renderer option.


I'm adding in CC the people relevant to Weston's test suite and the Mesa EGL_EXT_device_base implementation.

(In reply to Pekka Paalanen from comment #4)
> Oh, I suppose our gl-renderer API does not account for rendering into an FBO
> off-screen. It always requires an EGLNativeWindowType to create an
> EGLSurface for. Do you know if there is anything we could pass in with
> surfaceless to get a working EGLSurface, or would it always force us to use
> an FBO because the EGLSurface is a dummy?

Hrm, it being called "surfaceless" and all, I would assume you cannot even create an EGLsurface to begin with, which leaves no other option than to use FBOs. So the alternative to GBM platform would be to use an FBO, which means extending the gl-renderer API to allow that. So, let's just use GBM for now.

(In reply to Pekka Paalanen from comment #4)
> We will want to run all headless backend tests with the Pixman renderer by
> default, and if EGL is enabled, re-run the screenshot and EGL related tests
> with the gl-renderer. I'm not sure how easy that is with the current test
> harness, and the new test harness is still lacking the client helpers and
> could use converting buffer-count-test and internal-screenshot-test over
> before it's clear how to do this. So that may need to wait for later. Or
> maybe you already implemented this?

As for now I've been only changing/adding 'server_parameters' string in the tests.

> --disable-egl should definitely only disable the gl-renderer part, not
> headless altogether.

OK, I'll fix the code.

> I don't think we should have it as a build time option only, either. Of
> course, --disable-egl prevents gl-renderer from being built, but linking it
> in should be a runtime option.

That's how I implemented it. I based my code a lot on compositor-drm and compositor-fbdev.

> I'd like to see your code to see what you use libudev and libgbm for.

I'll attach the patch shortly.
 
> I suppose you use libudev to find the render node?

Exactly, that's how it is used right now. First I used mesa approach to iterate through /dev/dri/renderD* files, but then I found out libudev from waffle source code.
https://github.com/waffle-gl/waffle/blob/master/src/waffle/gbm/wgbm_display.c#L67

> I think that could be
> replaced with EGL_EXT_device_base and EGL_EXT_device_drm extensions, which
> are WIP for Mesa still:
> http://lists.freedesktop.org/archives/mesa-dev/2015-July/089783.html

Thanks, I'll take a look at it.

> Are you using the EGL surfaceless platform or GBM platform? Could using the
> surfaceless platform remove the direct link from headless backend to libgbm?

GBM platfrom like in EGL_MESA_platform_gbm/EGL_KHR_platform_gbm example
https://www.khronos.org/registry/egl/extensions/MESA/EGL_MESA_platform_gbm.txt

The main difference is that:
1) I'm using renderD<num> device instead of card0
2) file is opened with "O_RDWR | O_CLOEXEC" not "O_RDWR | FD_CLOEXEC" flags.

On one of my systems FD_CLOEXEC was segfaulting nouveau_dri.so.

I did not experiment more with EGL_surfaceless platform because that it's not widely available yet and would require more work in gl-renderer. 

> Oh, I suppose our gl-renderer API does not account for rendering into an FBO
> off-screen. It always requires an EGLNativeWindowType to create an
> EGLSurface for. Do you know if there is anything we could pass in with
> surfaceless to get a working EGLSurface, or would it always force us to use
> an FBO because the EGLSurface is a dummy?

As far as I remember I stuck on creating an EGLsurface without gbm_surface *surface. My knowledge was so small that I started reading "OpenGL ES 3.0 Programming Guide" about EGL and FBO. In the meantime you mentioned this bug so I left #83984 and surfaceless platform for later.

Right now I don't know if it's possible but back then I was going into conclusion that FBOs need to be used instead of EGLSurface.

Anyway, many thanks for the all of this information. Such a mentoring helps me a lot :-)

Created attachment 117891 [details]
initial implementation

In Aug/Sep we had the following discussion:
http://lists.freedesktop.org/archives/wayland-devel/2015-August/024124.html
which seemingly died off at:
http://lists.freedesktop.org/archives/wayland-devel/2015-September/024128.html

Since no-one has objected, I think we should be looking at that new plan instead.

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/wayland/weston/issues/50.