Re: Help compiling mesa/gallium from git!
On Tue, 18 Feb 2014 11:12:01 -0800 Bill Spitzak spit...@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 spit...@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
Re: Help compiling mesa/gallium from git!
On Tue, 18 Feb 2014 23:58:41 -0800 Bill Spitzak spit...@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 Btw. whenever you reconfigure Mesa, and especially if you use Mesa in-place without installing it to a prefix, it is good to do a 'git clean -dxf' before configuring. Just in case, and particularly if you do not do a 'make distclean' before reconfiguring. - pq ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Help compiling mesa/gallium from git!
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. 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@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 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Help compiling mesa/gallium from git!
On Fri, 07 Feb 2014 09:54:36 -0800 Bill Spitzak spit...@gmail.com wrote: Okay, removing everything with gallium in it's name from the install worked. But make install in mesa puts it all back! Would clean fix this? What I am really interested in is the proper configure line for mesa. I am currently only interested in running wayland atop an Nvidia X server, and running GL/EGL wayland clients inside that, and some of the errors indicate that I may be able to run software-emulated EGL with the proper configuration. *sigh*... I wrote a long nice reply and then my laptop crashed. Ok, here's the summary anyway. - your configure line looks fine, but - you need --enable-gallium-egl, because you want software rendered Wayland GL/GLES apps to work - you need to use weston's pixman renderer, not gl-renderer. Sw-rendered GL apps will work anyway with egl_gallium.so, but not with egl_dri2.so. - if you used weston's gl-renderer, you need to get weston to load NVIDIA libEGL, but you always need Wayland apps to load Mesa libEGL. That is almost impossible without serious hacking, especially if you built weston-desktop-shell to use EGL. So better to not have weston use EGL/GL at all. - you probably run not the binaries you think you are, because of the problems and the warnings about source being more recent than executable. That needs to be fixed. Check /proc/PID/maps for what binaries are loaded for a process. Thanks, pq ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Help compiling mesa/gallium from git!
In order to try to compile the new xserver for wayland, I updated mesa to the latest git version, and now wayland does not work at all! Considering it has worked for a long time I would like to try to fix this, it is really unfortunate. It does appear the problem is in egl gallium and it's software fallback. Pekka you were just talking about this in another thread so I thought you may have an idea what is wrong, or perhaps what I should do to get around it. Running weston in the debugger with the debug symbols turned on produces this (this is from inside a terminal on X so I am using the X11 compositor): Starting program: /home/spitzak/install/bin/weston --modules=xwayland.so [Thread debugging using libthread_db enabled] Using host libthread_db library /lib/x86_64-linux-gnu/libthread_db.so.1. Date: 2014-02-07 PST [09:14:13.518] weston 1.4.0 http://wayland.freedesktop.org/ Bug reports to: https://bugs.freedesktop.org/enter_bug.cgi?product=Waylandcomponent=westonversion=1.4.0 Build: 1.4.0-59-gc94d622 compositor: Move view repositioning logic into shell (2014-02-05 17:36:00 -0800) [09:14:13.518] OS: Linux, 3.2.0-58-generic, #88-Ubuntu SMP Tue Dec 3 17:37:58 UTC 2013, x86_64 [09:14:13.518] warning: XDG_RUNTIME_DIR /run/shm is not configured correctly. Unix access mode must be 0700 (current mode is 777), and must be owned by the user (current owner is UID 0). Refer to your distribution on how to get it, or http://www.freedesktop.org/wiki/Specifications/basedir-spec on how to implement it. [09:14:13.519] Using config file '/home/spitzak/.config/weston.ini' [09:14:13.519] Loading module '/home/spitzak/install/lib/weston/x11-backend.so' [09:14:13.619] initializing x11 backend [09:14:13.621] Loading module '/home/spitzak/install/lib/weston/gl-renderer.so' libEGL debug: Native platform type: x11 (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: added egl_dri2 to module array libEGL debug: dlopen(/home/spitzak/install/lib/egl/egl_gallium.so) libEGL info: use X11 for display 0x632e40 libEGL info: use software fallback Program received signal SIGSEGV, Segmentation fault. 0x71b980af in egl_g3d_new_sw_screen (ndpy=optimized out, ws=0x654040) at common/egl_g3d.c:67 warning: Source file is more recent than executable. 67 } This does appear to be in egl_gallium.so, which is recently compiled, I am not sure why I get the Source file is more recent error. Mesa is built with the following config line, which is ridiculous complex and probably the source of my troubles, but I really have no idea what any of this means: ./autogen.sh --prefix=$WLD --enable-gles2 --disable-gallium-egl \ --with-egl-platforms=wayland,x11,drm --enable-gbm \ --enable-shared-glapi --with-gallium-drivers=r300,r600,swrast,nouveau \ --with-dri-drivers= --disable-dri3 Thanks for any help! ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Fwd: Re: Help compiling mesa/gallium from git!
The new mesa you built has no egl_gallium.so (since you have --disable-gallium-egl), but you have not removed the old egl_gallium.so, and it tries to load it, since it is here. Axel Davy Le 07/02/2014 18:30, Bill Spitzak a écrit : In order to try to compile the new xserver for wayland, I updated mesa to the latest git version, and now wayland does not work at all! Considering it has worked for a long time I would like to try to fix this, it is really unfortunate. It does appear the problem is in egl gallium and it's software fallback. Pekka you were just talking about this in another thread so I thought you may have an idea what is wrong, or perhaps what I should do to get around it. Running weston in the debugger with the debug symbols turned on produces this (this is from inside a terminal on X so I am using the X11 compositor): Starting program: /home/spitzak/install/bin/weston --modules=xwayland.so [Thread debugging using libthread_db enabled] Using host libthread_db library /lib/x86_64-linux-gnu/libthread_db.so.1. Date: 2014-02-07 PST [09:14:13.518] weston 1.4.0 http://wayland.freedesktop.org/ Bug reports to: https://bugs.freedesktop.org/enter_bug.cgi?product=Waylandcomponent=westonversion=1.4.0 Build: 1.4.0-59-gc94d622 compositor: Move view repositioning logic into shell (2014-02-05 17:36:00 -0800) [09:14:13.518] OS: Linux, 3.2.0-58-generic, #88-Ubuntu SMP Tue Dec 3 17:37:58 UTC 2013, x86_64 [09:14:13.518] warning: XDG_RUNTIME_DIR /run/shm is not configured correctly. Unix access mode must be 0700 (current mode is 777), and must be owned by the user (current owner is UID 0). Refer to your distribution on how to get it, or http://www.freedesktop.org/wiki/Specifications/basedir-spec on how to implement it. [09:14:13.519] Using config file '/home/spitzak/.config/weston.ini' [09:14:13.519] Loading module '/home/spitzak/install/lib/weston/x11-backend.so' [09:14:13.619] initializing x11 backend [09:14:13.621] Loading module '/home/spitzak/install/lib/weston/gl-renderer.so' libEGL debug: Native platform type: x11 (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: added egl_dri2 to module array libEGL debug: dlopen(/home/spitzak/install/lib/egl/egl_gallium.so) libEGL info: use X11 for display 0x632e40 libEGL info: use software fallback Program received signal SIGSEGV, Segmentation fault. 0x71b980af in egl_g3d_new_sw_screen (ndpy=optimized out, ws=0x654040) at common/egl_g3d.c:67 warning: Source file is more recent than executable. 67} This does appear to be in egl_gallium.so, which is recently compiled, I am not sure why I get the Source file is more recent error. Mesa is built with the following config line, which is ridiculous complex and probably the source of my troubles, but I really have no idea what any of this means: ./autogen.sh --prefix=$WLD --enable-gles2 --disable-gallium-egl \ --with-egl-platforms=wayland,x11,drm --enable-gbm \ --enable-shared-glapi --with-gallium-drivers=r300,r600,swrast,nouveau \ --with-dri-drivers= --disable-dri3 Thanks for any help! ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
