Help compiling mesa/gallium from git!

[Pekka Paalanen]

On Tue, 18 Feb 2014 11:12:01 -0800
Bill Spitzak <spitzak at gmail.com> wrote:

> Maybe you can correct my guess as to how all this software talks to each 
> other:
> 
> 1. An EGL-using wayland client talks to mesa's libEGL.

You have to ensure it actually gets the Mesa version of libEGL.

> 2. Somehow mesa decides to use Gallium rather than DRI (how? I see no 
> config option to cause this and attempting to disable DRI fails)

The preferences and fallbacks are pretty complicated.
EGL_DRIVER=egl_gallium env var would force Mesa to try only
egl_gallium.so.

> 3. Mesa then uses the "gallium driver" called "swrast" to draw into a 
> memory buffer.

Yes, more commonly known as llvmpipe and softpipe, defaulting to llvmpipe.

> 4. Client does eglSwapBuffers, and mesa/Gallium then uses the "egl 
> platform" called "wayland" to do wayland attach + commit ? This one 

Yes.

> really has me stumped as to how it is possible to make the "platform" 
> different than the "driver". My best guess is that "platform" is some 
> kind of option for the "swrast" driver and is not used by other drivers?

There are many different things in Mesa called "driver". It's the usual
confusion of an overloaded name.

The EGL driver egl_dri2 supports several platforms, and so does
egl_gallium, too, AFAIK. The Mesa EGL drivers each use a different Mesa
internal API to load the actual graphics driver, or something like
that. egl_dri2 can load both classic and gallium drivers, while
egl_gallium can only load gallium drivers.

Both egl_dri2 and egl_gallium support the Wayland platform, but in
different ways. This difference is why software rendered Wayland GL
apps work on egl_gallium, but not on egl_dri2.

If it sounds like a big ball of various glues, then that's because it
really is, IMHO.

> 5. Wayland/weston get this and decide to composite using EGL. It *also* 
> talks to mesa's libEGL, sending it commands to composite.

Not necessarily. With pixman-renderer, weston does not use EGL or any
GL at all. Instead, it gets the standard wl_shm buffers from clients,
uses pixman to draw the composite, and posts that to the X-server like
any other software rendered app.

egl_gallium.so has support to send the rendered images as generic
wl_shm buffers from the clients. egl_dri2.so does not.

> 6. Mesa again uses the "gallium driver" called "swrast" to draw the 
> composite into yet another buffer.

It could, if Weston was using the gl-renderer. Pixman-renderer is faster.

> 7. Wayland/weston does eglSwapBuffers and mesa/Gallium this time 
> magically decides to use the "x11" "egl platform" which then updates the 
> x11 window with the composited output.

Theoretically yes. However, because your X server is using NVIDIA
graphics stack, there could be complications. I don't think I've ever
tried that.

Weston could instead be using the NVIDIA libEGL and GLESv2 libs for its
own compositing, but like I said, getting weston to link to a different
graphics stack than *all* its clients is hard.

> It would also help a lot with any kind of description of what happens if 
> hardware supported EGL is working for either the compositor, the 
> clients, or both.

I don't think anyone supports software rendered compositors for
hardware accelerated clients in their EGL implementation, so that case
is out of the picture.

Software rendered clients just post wl_shm buffers to the compositor.
Software rendered GL can do that, if implemented (only egl_gallium
atm.).

Compositor either reads wl_shm buffers directly for software
compositing, or uploads the buffer content into a GL texture (for
hardware compositing) assuming that GL is implemented in hardware, but
it doesn't have to be.


On Tue, 18 Feb 2014 23:58:41 -0800
Bill Spitzak <spitzak at gmail.com> wrote:

> Okay, a bit more luck, in that I can compile weston.
> 
> I mostly discovered that there are parts of mesa you just cannot turn 
> off, no matter how much you are certain they are not used. Mesa 
> internally has calls into various functions in these modules from others 
> so they cannot be removed.
> 
> My current mesa configuration:
> 
>    ./autogen.sh --prefix=$WLD --enable-gles2 --enable-gallium-egl \
>        --with-egl-platforms=wayland,x11,drm --enable-gbm \
>        --with-gallium-drivers=swrast \
>        --with-dri-drivers=swrast --disable-dri3 --disable-glx
> 
> The most important thing was the dri-driver, otherwise you get the 
> _glapi_Dispatch symbol missing. Also x11, drm, gbm, and gles2 are needed 
> or mesa just will not compile.
> 
> I now have to run wayland with --use-pixman, when before it either 
> detected that it needed to use this, or the gl-renderer worked for some 
> reason.

You mean weston.

Earlier, maybe you were getting NVIDIAs libEGL, when you now get Mesa
libEGL for Weston itself. I think that is normal when you are mixing
completely different graphics stacks (NVIDIA vs. Mesa et al.).

> I cannot run any egl demos, even though I have been told this will allow 
> them to run with software emulation. weston-simple-egl produces this:
> 
> $ env ELG_LOG_LEVEL=debug weston/weston-simple-egl weston-simple-egl: 
> clients/simple-egl.c:159: init_egl: Assertion `ret && n >= 1' failed.
> [23:44:01.295] libwayland: disconnect from client 0x7578d0
> Aborted
> spitzak at asus:~/swdevl/wayland$ env EGL_LOG_LEVEL=debug 
> weston/weston-simple-egl
> libEGL debug: Native platform type: wayland (autodetected)
> libEGL debug: EGL search path is /home/spitzak/install/lib/egl
> libEGL debug: added /home/spitzak/install/lib/egl/egl_gallium.so to 
> module array
> libEGL debug: dlopen(/home/spitzak/install/lib/egl/egl_gallium.so)
> libEGL info: use wayland for display 0x1e28010
> libEGL debug: EGL user error 0x3001 (EGL_NOT_INITIALIZED) in 
> eglInitialize(failed to initialize screen)
> 
> libEGL info: use wayland for display 0x1e28010
> libEGL info: use software fallback
> libEGL debug: the best driver is Gallium
> libEGL debug: the value (0x8) of attribute 0x3040 did not meet the 
> criteria (0x4)
> libEGL debug: the value (0x8) of attribute 0x3040 did not meet the 
> criteria (0x4)
> libEGL debug: the value (0x8) of attribute 0x3040 did not meet the 
> criteria (0x4)
> libEGL debug: the value (0x8) of attribute 0x3040 did not meet the 
> criteria (0x4)
> libEGL debug: the value (0x8) of attribute 0x3040 did not meet the 
> criteria (0x4)
> libEGL debug: the value (0x8) of attribute 0x3040 did not meet the 
> criteria (0x4)
> libEGL debug: the value (0x8) of attribute 0x3040 did not meet the 
> criteria (0x4)
> libEGL debug: the value (0x8) of attribute 0x3040 did not meet the 
> criteria (0x4)
> libEGL debug: the value (0x8) of attribute 0x3040 did not meet the 
> criteria (0x4)
> libEGL debug: the value (0x8) of attribute 0x3040 did not meet the 
> criteria (0x4)
> weston-simple-egl: clients/simple-egl.c:159: init_egl: Assertion `ret && 
> n >= 1' failed.
> [23:44:06.115] libwayland: disconnect from client 0x7578d0
> Aborted

The assertion says it fails to find any suitable EGLConfigs.

#define EGL_RENDERABLE_TYPE             0x3040

#define EGL_OPENGL_ES2_BIT              0x0004  /* EGL_RENDERABLE_TYPE mask bits */
#define EGL_OPENGL_BIT                  0x0008  /* EGL_RENDERABLE_TYPE mask bits */

Looks like you do not have any GLESv2 renderable configs, you have only
OPENGL renderable configs. That sounds like you didn't build GLESv2
support in Mesa, but you claim you did, which makes me think, that you
are not using the binaries you actually built from Mesa the last time.

- pq