Re: [OE-core] [PATCH 00/12] Enable accelerated OpenGL in qemu
On Mon, 25 Feb 2019 at 10:47, Richard Purdie wrote: > libEGL warning: GLX/DRI2 is not supported As a guess: Debian 8 has a particularly old version of mesa on the host: https://packages.debian.org/source/jessie/mesa I would start by installing a more recent one from jessie-backports repo: https://packages.debian.org/source/jessie-backports/mesa I also have to mention that Debian 8 is no longer in full support, but in the 'LTS phase', which is described as: 'Debian LTS will not be handled by the Debian security team, but by a separate group of volunteers and companies interested in making it a success. ' https://wiki.debian.org/LTS/ Should we decommission the Debian 8 builders? Alex -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 00/12] Enable accelerated OpenGL in qemu
On Fri, 2019-02-22 at 15:33 +0100, Alexander Kanavin wrote: > V2 changes: addressed feedback from the first review round > V3 changes: > - better fix for missing qemu X11 include, as discussed with upstream > - maintainers.inc entry for virglrenderer > - egl-headless support (see below for details) > - improvements to kmscube recipe > - fix to vte-native to allow building it with gcc 4.8 > V4 changes > - address failures uncovered by yocto autobuilder > V5 changes > - remove patches that have been merged to master > - replace BBCLASSEXTEND_remove with PREFERRED_PROVIDER for mesa > recipe variants > V6 changes > - again rebase to master > - tweak oe-selftest to remove unnecessary re-builds of qemu-native > V7 changes > - rename virglrender_git.bb to virglrendender_0.7.0.bb > - update the status of virglrenderer patches > - further clarify the PACKAGECONFIG settings for qemu There is a further problem somewhere. I ran more tests over the weekend and fixed missing libEGL on ubuntu1604 for example. The debian8 worker is failing consistently: https://autobuilder.yoctoproject.org/typhoon/#/builders/80/builds/91 The log output is useless (which is a separate concern). When I try and launch qemu manually I get the output below: pokybuild@debian8-ty-1:~/yocto-worker/oe-selftest-debian/build$ DISPLAY=:1 /home/pokybuild/yocto-worker/oe-selftest- debian/build/build/tmp/work/x86_64-linux/qemu-helper-native/1.0- r1/recipe-sysroot-native/usr/bin/qemu-system-x86_64 -device virtio-net- pci,netdev=net0,mac=52:54:00:12:34:02 -netdev tap,id=net0,ifname=tap0,script=no,downscript=no -drive file=/home/pokybuild/yocto-worker/oe-selftest- debian/build/build/tmp/deploy/images/qemux86-64/core-image-minimal- qemux86-64.ext4,if=virtio,format=raw -vga vmware -show-cursor -usb -device usb-tablet -object rng-random,filename=/dev/urandom,id=rng0 -device virtio-rng-pci,rng=rng0 -vga virtio -display gtk,gl=on -cpu core2duo -enable-kvm -m 256 -serial tcp:127.0.0.1:51379 -serial tcp:127.0.0.1:34855 -pidfile pidfile_9641 -snapshot -kernel /home/pokybuild/yocto-worker/oe-selftest- debian/build/build/tmp/deploy/images/qemux86-64/bzImage --4.18.27+git0+9e348b6f9d_62f0a3acff-r0.2-qemux86-64-20190223080225.bin -append 'root=/dev/vda rw highres=off mem=256M ip=192.168.7.2::192.168.7.1:255.255.255.0 vga=0 uvesafb.mode_option=640x480-32 oprofile.timer=1 uvesafb.task_timeout=-1 console=tty1 console=ttyS0,115200n8 printk.time=1' libEGL warning: GLX/DRI2 is not supported ** (qemu-system-x86_64:10289): WARNING **: 09:43:00.199: Unknown X11 keycode mapping ''. Please report to qemu-de...@nongnu.org including the following information: - Operating system - X11 Server - xprop -root - xdpyinfo qemu-system-x86_64: -serial tcp:127.0.0.1:51379: Failed to connect socket: Connection refused qemu-system-x86_64: -serial tcp:127.0.0.1:51379: could not connect serial device to character backend 'tcp:127.0.0.1:51379' Any ideas why this works everywhere else but not on debian8? Cheers, Richard -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 00/12] Enable accelerated OpenGL in qemu
V2 changes: addressed feedback from the first review round V3 changes: - better fix for missing qemu X11 include, as discussed with upstream - maintainers.inc entry for virglrenderer - egl-headless support (see below for details) - improvements to kmscube recipe - fix to vte-native to allow building it with gcc 4.8 V4 changes - address failures uncovered by yocto autobuilder V5 changes - remove patches that have been merged to master - replace BBCLASSEXTEND_remove with PREFERRED_PROVIDER for mesa recipe variants V6 changes - again rebase to master - tweak oe-selftest to remove unnecessary re-builds of qemu-native V7 changes - rename virglrender_git.bb to virglrendender_0.7.0.bb - update the status of virglrenderer patches - further clarify the PACKAGECONFIG settings for qemu Why this? Why now? 1. I think we are heading towards a reality where some kind of working GL is a 'must' for any kind of UI work. 2. Typically people build images and then transfer them to the NUC or even target boards for testing - using qemu would be less awkward. 3. Current qemu configuration is basically useless here, as it only provides a very slow software GL driver from mesa. 0. TLDR: a) Gtk UI frontend $ . oe-init-build-env build-virgl $ bitbake core-image-sato-sdk $ runqemu kvm gl $$ run glxgears or any other GL-capable binary inside qemu b) egl-headless $ . oe-init-build-env build-virgl $ bitbake core-image-sato-sdk $ runqemu kvm egl-headless publicvnc $ $$ run glxgears or any other GL-capable binary inside qemu 1. For the local UI, qemu is switched over to use gtk frontend. I simply couldn't get SDL frontend to work properly, it only displays a blank black window or doesn't start at all. Same thing happens with qemu binaries provided by Fedora and opensuse (Ubuntu's qemu lacks virgl support). Seems like SDL support has regressed. 2. What is egl-headless? In this variant, Qemu does not open a UI window at all. Instead, it renders all graphics, including GL, into a memory buffer, which can be seen with a vnc or spice client (over a TCP socket). This has the following advantages: - no need to be physically present at the host machine, output (including GL bits!) can be seen remotely - no need for the host machine to run an X session 3. While the components are built against the most minimum necessary mesa-native set (gbm, egl, dri with no drivers), libepoxy loads and uses the host GL implementation (through a chrpath hack). This is both to save build times, and because the host is likely to have a set of drivers more appropriate for the physical machine (e.g. proprietary nvidia stack, although I didn't test that). 4. I tested this with - glamor X server - weston compositor with drm backend (build core-image-weston, then edit weston.ini in the image to use drm backed instead of fbdev). - kmscube - glxgears - https://www.geeks3d.com/gputest/ The latter two show FPS that is similar to running them directly on the host. 5. Some things I am not sure about: - how much of a 'default' should this be for running qemu. It works for me, but other people might find it less stable compared to the existing sdl-vmware-swrast setup. - what other tests and demos could be run - how could this be tested on the autobuilder. I wrote two oe-selftests for this (gtk, egl-headless), but one of them does require an X session, and both require ability to create opengl contexts on the host. The following changes since commit 47eb3d00e9d6a66aee1283dab29af8117a006d6d: resulttool: Improvements to allow integration to the autobuilder (2019-02-21 12:34:00 +) are available in the Git repository at: git://git.yoctoproject.org/poky-contrib akanavin/virgl-gtk http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=akanavin/virgl-gtk Alexander Kanavin (12): virglrenderer: add a recipe qemu: enable virglrenderer and glx options for native/nativesdk builds qemu: build target variant with gtk+, and nativesdk variant without sdl local.conf.sample: adjust the qemu config to enable gtk+ instead of sdl qemu: remove support for building against host sdl qemu: add a gettext-native dependency to gtk option qemu: add a patch to avoid a missing definition error qemu: add environment variable wrappers to make qemu look good with gtk frontend qemu: add a backported patch to fix egl-headless support runqemu: add options for enabling virgl GL acceleration runqemu: do not check for GL libraries selftest: add tests for virgl GL acceleration meta-poky/conf/local.conf.sample | 9 +-- meta-selftest/lib/oeqa/runtime/cases/virgl.py | 28 meta/conf/distro/include/maintainers.inc | 1 + meta/lib/oeqa/selftest/cases/runtime_test.py | 52 +++ meta/recipes-devtools/qemu/qemu.inc | 41 +++- .../qemu/0001-Add-a-missing-X11-include.patch | 65 +++ ...-egl-headless-add-egl_create_context.patch | 50 ++ ...x-libcap-hea
[OE-core] [PATCH 00/12] Enable accelerated OpenGL in qemu
V2 changes: addressed feedback from the first review round V3 changes: - better fix for missing qemu X11 include, as discussed with upstream - maintainers.inc entry for virglrenderer - egl-headless support (see below for details) - improvements to kmscube recipe - fix to vte-native to allow building it with gcc 4.8 V4 changes - address failures uncovered by yocto autobuilder V5 changes - remove patches that have been merged to master - replace BBCLASSEXTEND_remove with PREFERRED_PROVIDER for mesa recipe variants V6 changes - again rebase to master - tweak oe-selftest to remove unnecessary re-builds of qemu-native Why this? Why now? 1. I think we are heading towards a reality where some kind of working GL is a 'must' for any kind of UI work. 2. Typically people build images and then transfer them to the NUC or even target boards for testing - using qemu would be less awkward. 3. Current qemu configuration is basically useless here, as it only provides a very slow software GL driver from mesa. 0. TLDR: a) Gtk UI frontend $ . oe-init-build-env build-virgl $ bitbake core-image-sato-sdk $ runqemu kvm gl $$ run glxgears or any other GL-capable binary inside qemu b) egl-headless $ . oe-init-build-env build-virgl $ bitbake core-image-sato-sdk $ runqemu kvm egl-headless publicvnc $ $$ run glxgears or any other GL-capable binary inside qemu 1. For the local UI, qemu is switched over to use gtk frontend. I simply couldn't get SDL frontend to work properly, it only displays a blank black window or doesn't start at all. Same thing happens with qemu binaries provided by Fedora and opensuse (Ubuntu's qemu lacks virgl support). Seems like SDL support has regressed. 2. What is egl-headless? In this variant, Qemu does not open a UI window at all. Instead, it renders all graphics, including GL, into a memory buffer, which can be seen with a vnc or spice client (over a TCP socket). This has the following advantages: - no need to be physically present at the host machine, output (including GL bits!) can be seen remotely - no need for the host machine to run an X session 3. While the components are built against the most minimum necessary mesa-native set (gbm, egl, dri with no drivers), libepoxy loads and uses the host GL implementation (through a chrpath hack). This is both to save build times, and because the host is likely to have a set of drivers more appropriate for the physical machine (e.g. proprietary nvidia stack, although I didn't test that). 4. I tested this with - glamor X server - weston compositor with drm backend (build core-image-weston, then edit weston.ini in the image to use drm backed instead of fbdev). - kmscube - glxgears - https://www.geeks3d.com/gputest/ The latter two show FPS that is similar to running them directly on the host. 5. Some things I am not sure about: - how much of a 'default' should this be for running qemu. It works for me, but other people might find it less stable compared to the existing sdl-vmware-swrast setup. - what other tests and demos could be run - how could this be tested on the autobuilder. I wrote two oe-selftests for this (gtk, egl-headless), but one of them does require an X session, and both require ability to create opengl contexts on the host. The following changes since commit 29099c8a49bf9d35514bbc1e77657655598a80cc: maintainers.inc: replace Changhyeok Bae's @lge email address with a personal one (2019-02-08 10:57:19 +) are available in the Git repository at: git://git.yoctoproject.org/poky-contrib akanavin/virgl-gtk http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=akanavin/virgl-gtk Alexander Kanavin (12): virglrenderer: add a recipe qemu: enable virglrenderer and glx options for native/nativesdk builds local.conf.sample: adjust the qemu config to enable gtk+ instead of sdl qemu: build target variant with gtk+, and nativesdk variant without sdl qemu: remove support for building against host sdl qemu: add a gettext-native dependency to gtk option qemu: add a patch to avoid a missing definition error qemu: add environment variable wrappers to make qemu look good with gtk frontend qemu: add a backported patch to fix egl-headless support runqemu: add options for enabling virgl GL acceleration runqemu: do not check for GL libraries selftest: add tests for virgl GL acceleration meta-poky/conf/local.conf.sample | 9 +-- meta-selftest/lib/oeqa/runtime/cases/virgl.py | 28 meta/conf/distro/include/maintainers.inc | 1 + meta/lib/oeqa/selftest/cases/runtime_test.py | 52 +++ meta/recipes-devtools/qemu/qemu.inc | 41 +++- .../qemu/0001-Add-a-missing-X11-include.patch | 65 +++ ...-egl-headless-add-egl_create_context.patch | 50 ++ ...x-libcap-header-issue-on-some-distro.patch | 2 +- ...-messages-when-qemi_cpu_kick_thread-.patch | 2 +- meta/recipes-devtools/qemu/qemu_3.1.0.bb | 2 +
