Monday, April 10, 2017
Plan for today:
- Figure out how to get a 3D accelerated guest that works
- Spend some time on a discussion regarding APIs and tools for
GPGPUs. If I get invited to the discussion
- Work on Spice for Mac and the recorder / LEB128 branch.
Introduction to the Tao language
I watched this old video again today:
I was pleasantly surprised to see that someone has added
subtitles. And did a really good job at it too. Cool 
Software does not work
This morning again, I'm wasting tons of time waiting for Apple software that does not work. I still remember fondly MacOSX 10.6, which offered monumental stability an dperformance. But there:
- Right after a fresh boot, macOS is so slow I have to reboot it. Twice. I mean: slow enough text I type in Emacs takes tens of seconds to show up! Slow enough that a whole six minutes after I launched it, Activity Monitor is still unable to show me a list of processes!
- Software update waits ten minutes before asking for my password. And then is so slow I can't type it.
There was an Apple software update. For some reason, it took three tries to make that work.
The first time, the system would not shut down. The root cause seems
to be Kaspersky Anti-virus, which just loves eating 200% CPU (the
equivalent of 2 whole CPUs? Why?). Removed it. Of course, now the
software maintenance agent wants to reinstall it. But I seem to have
finally recovered my Mac I'm not sure I'll keep using it, given
that the only things it identified as "possible Trojan" is my own
JavaScript / NodeJS code...
Overall, it took about one hour between failed reboots and install time to finally get my Mac back. Yuck.
Meanwhile...
3D acceleration in guests
I'm still a bit stumped regarding what is happening with my 3D-accelerated guests.
The problem is really 3D acceleration. I get my graphics back if I reboot the guest after changing the <graphics> section to:
<graphics type='spice'>
<listen type='none'/>
<image compression='off'/>
<gl enable='no'/>
</graphics>
But if I run glxgears -info, now what I see is
GL_VERSION = 3.0 Mesa 17.1.0-devel (git-b2c97bc)
What puzzles me is that the version I last built was 957ccbe04a (last master I pulled this morning. The one I built before was c0e9e61c9. So where does this b2c97bc come from?
Running lsof -p $(pgrep glxgears) gives me
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME glxgears 2017 ddd cwd DIR 0,46 598 257 /home/ddd glxgears 2017 ddd rtd DIR 0,38 154 256 / glxgears 2017 ddd txt REG 0,38 23704 184533 /usr/bin/glxgears glxgears 2017 ddd mem REG 0,36 184533 /usr/bin/glxgears (path dev=0,38) glxgears 2017 ddd mem REG 0,36 21611 /usr/lib64/libtinfo.so.6.0 (path dev=0,38) glxgears 2017 ddd mem REG 0,36 159330 /usr/lib64/librt-2.24.so (path dev=0,38) glxgears 2017 ddd mem REG 0,36 21022 /usr/lib64/libffi.so.6.0.2 (path dev=0,38) glxgears 2017 ddd mem REG 0,36 157043 /usr/lib64/libgcc_s-6.3.1-20161221.so.1 (path dev=0,38) glxgears 2017 ddd mem REG 0,36 161299 /usr/lib64/libstdc++.so.6.0.22 (path dev=0,38) glxgears 2017 ddd mem REG 0,36 162526 /usr/lib64/libLLVM-3.9.so (path dev=0,38) glxgears 2017 ddd mem REG 0,36 161390 /usr/lib64/libelf-0.168.so (path dev=0,38) glxgears 2017 ddd mem REG 0,36 176509 /usr/lib64/libdrm_radeon.so.1.0.1 (path dev=0,38) glxgears 2017 ddd mem REG 0,36 176507 /usr/lib64/libdrm_nouveau.so.2.0.0 (path dev=0,38) glxgears 2017 ddd mem REG 0,36 21768 /usr/lib64/libz.so.1.2.8 (path dev=0,38) glxgears 2017 ddd mem REG 0,36 260038 /usr/lib/dri/swrast_dri.so (path dev=0,38) glxgears 2017 ddd mem REG 0,36 159612 /usr/lib64/libpcre.so.1.2.8 (path dev=0,38) glxgears 2017 ddd mem REG 0,36 20766 /usr/lib64/libXau.so.6.0.0 (path dev=0,38) glxgears 2017 ddd mem REG 0,36 159314 /usr/lib64/libdl-2.24.so (path dev=0,38) glxgears 2017 ddd mem REG 0,36 159326 /usr/lib64/libpthread-2.24.so (path dev=0,38) glxgears 2017 ddd mem REG 0,36 176501 /usr/lib64/libdrm.so.2.4.0 (path dev=0,38) glxgears 2017 ddd mem REG 0,36 20790 /usr/lib64/libXxf86vm.so.1.0.0 (path dev=0,38) glxgears 2017 ddd mem REG 0,36 21708 /usr/lib64/libxcb-dri2.so.0.0.0 (path dev=0,38) glxgears 2017 ddd mem REG 0,36 21711 /usr/lib64/libxcb-glx.so.0.0.0 (path dev=0,38) glxgears 2017 ddd mem REG 0,36 21735 /usr/lib64/libxcb.so.1.1.0 (path dev=0,38) glxgears 2017 ddd mem REG 0,36 174042 /usr/lib64/libX11-xcb.so.1.0.0 (path dev=0,38) glxgears 2017 ddd mem REG 0,36 20772 /usr/lib64/libXfixes.so.3.1.0 (path dev=0,38) glxgears 2017 ddd mem REG 0,36 20769 /usr/lib64/libXdamage.so.1.1.0 (path dev=0,38) glxgears 2017 ddd mem REG 0,36 20771 /usr/lib64/libXext.so.6.4.0 (path dev=0,38) glxgears 2017 ddd mem REG 0,36 161293 /usr/lib64/libselinux.so.1 (path dev=0,38) glxgears 2017 ddd mem REG 0,36 259990 /usr/lib/libglapi.so.0.0.0 (path dev=0,38) glxgears 2017 ddd mem REG 0,36 21763 /usr/lib64/libxshmfence.so.1.0.0 (path dev=0,38) glxgears 2017 ddd mem REG 0,36 21724 /usr/lib64/libxcb-sync.so.1.0.0 (path dev=0,38) glxgears 2017 ddd mem REG 0,36 21715 /usr/lib64/libxcb-present.so.0.0.0 (path dev=0,38) glxgears 2017 ddd mem REG 0,36 21709 /usr/lib64/libxcb-dri3.so.0.0.0 (path dev=0,38) glxgears 2017 ddd mem REG 0,36 21015 /usr/lib64/libexpat.so.1.6.2 (path dev=0,38) glxgears 2017 ddd mem REG 0,36 159310 /usr/lib64/libc-2.24.so (path dev=0,38) glxgears 2017 ddd mem REG 0,36 174044 /usr/lib64/libX11.so.6.3.0 (path dev=0,38) glxgears 2017 ddd mem REG 0,36 159316 /usr/lib64/libm-2.24.so (path dev=0,38) glxgears 2017 ddd mem REG 0,36 260017 /usr/lib/libGL.so.1.2.0 (path dev=0,38) glxgears 2017 ddd mem REG 0,36 159303 /usr/lib64/ld-2.24.so (path dev=0,38) glxgears 2017 ddd 0u CHR 136,0 0t0 3 /dev/pts/0 glxgears 2017 ddd 1w FIFO 0,10 0t0 30038 pipe glxgears 2017 ddd 2u CHR 136,0 0t0 3 /dev/pts/0 glxgears 2017 ddd 3u unix 0xffff9891b3f79800 0t0 31906 type=STREAM
Running a loop on the files with {tt "strings | grep "b2c97bc""}. This gives me the culprit:
/usr/lib/dri/swrast_dri.so %s%u.%u%s Mesa 17.1.0-devel (git-b2c97bc)
So it looks like I should remove this /usr/lib64 from the Mesa install path. Changing the configure script to
./configure --prefix=/usr --enable-libglvnd --enable-selinux --enable-gallium-osmesa --with-dri-driverdir=/usr/lib/dri --enable-gl --disable-gles1 --enable-gles2 --disable-xvmc --with-egl-platforms=drm,x11,surfaceless,wayland --enable-shared-glapi --enable-gbm --enable-glx-tls --enable-texture-float=yes --enable-gallium-llvm --enable-llvm-shared-libs --enable-dri --with-gallium-drivers=i915,nouveau,r300,svga,swrast,virgl --with-dri-drivers=swrast,nouveau
The change is to put the drivers in /usr/lib/dri. Rebuilding. Now, glxgears -info gives me the correct version. Making some progress. Rebooting with glenable='yes'. New art form:
What if I also rebuild Mesa on the host? Interesting that on the host, the existing dri installation is in /usr/lib64/dri. Info:
GL_RENDERER = Gallium 0.4 on AMD CAYMAN (DRM 2.49.0 / 4.10.8-200.fc25.x86_64, LLVM 3.9.1) GL_VERSION = 3.0 Mesa 13.0.4 GL_VENDOR = X.Org
For the host, I had to rebuild with
./configure --program-prefix= --disable-dependency-tracking --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc --datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib64 --libexecdir=/usr/libexec --localstatedir=/var --sharedstatedir=/var/lib --mandir=/usr/share/man --infodir=/usr/share/info --disable-asm --enable-selinux --enable-osmesa --with-dri-driverdir=/usr/lib64/dri --enable-egl --disable-gles1 --enable-gles2 --disable-xvmc --with-egl-platforms=x11,drm --enable-shared-glapi --enable-gbm --disable-opencl --enable-glx-tls --enable-texture-float=yes --enable-gallium-llvm --enable-dri --enable-xa --with-gallium-drivers=svga,radeonsi,swrast,r600,r300,nouveau,virgl --with-dri-drivers=nouveau,radeon,r200,i915,i965
The main difference being the --libdir=/usr/lib64 and --with-dri-driverdir=/usr/lib64/dri
That does not seem to change anything. Several attempts later, I still have the same artsy output.
On Muse, I ge something different. The problem seems to be mere misalignment of what is on the screen:
As a matter of fact, if I connect to f25-muse with VNC, I get a perfect picture even if the picture is garbled on screen when I see it through virt-manager. Time to try with remote-viewer, and to see what happens with Shuttle.
On Shuttle, I get a cursor on a black background. So the "more artsy" graphics are a sign that something is more wrong. Actually, on the host, I see this in dmesg:
[ 100.210616] [drm:radeon_cs_ioctl [radeon]] *ERROR* Invalid command stream !
So we are sending something bad to the Radeon. But for the NVIDIA card on Muse, it's likely I should just update the Spice components.
Rebuilding Spice
Updating the branches on Muse. Running autogen.sh for spice-gtk, I get:
./autogen.sh: line 11: gtkdocize: command not found
Not going to be a real issue on Muse (just dnf install gtk-doc), but I'm concerned about this for the Mac version. Well, later.
Next failure:
checking for intltool >= 0.40.0... found configure: error: Your intltool is too old. You need intltool 0.40.0 or later.
Need dnf install intltool. More failures. Apparently I have just copied over the source tree, but that's on a new disk, new system, so time to dnf builddep spice-gtk.
{scetion "Updating ELFE"}Udpated ELFE for LLVM 3.91, although this may have broken earlier releases as usual, so I'll have to look. As usual, the LLVM tutorial was completely useless in addressing the issues I ran into. It is not nearly complete enough.
2016-2017 - Christophe de Dinechin