If I run piglit inside QEMU with virgl, I get an assert inside the i965 driver like so: ../src/intel/compiler/brw_fs_visitor.cpp:449: void fs_visitor::emit_fb_writes(): Assertion `!prog_data->dual_src_blend || key->nr_color_regions == 1' failed. To avoid running the complete test-suite, you can run this to reproduce it instead: piglit run quick_gl -t ".*arb_blend_func_extended-fbo-extended-blend-pattern_gles2" results/quick_gl/ What you'll see is the whole VM crashing, due to the VM process calling abort(). This obviously requires an assert-enabled build of mesa to reproduce. It also seems I'm not the only one who has this problem: https://dri.freedesktop.org/~cbrill/dri-log/?channel=intel-gfx&highlight_names=&date=2018-06-22
Here's some inspection of the state: (gdb) p prog_data->dual_src_blend $1 = true (gdb) p key->nr_color_regions $2 = 7 (gdb) p this->dual_src_output.file $3 = VGRF (gdb) p this->outputs[0].file $4 = VGRF This is what this->outputs looks like: { {<backend_reg> = {<brw_reg> = {{{type = BRW_REGISTER_TYPE_F, file = VGRF, negate = 0, abs = 0, address_mode = 0, pad0 = 0, subnr = 0, nr = 44}, bits = 2883650}, {{swizzle = 0, writemask = 0, indirect_offset = 0, vstride = 0, width = 0, hstride = 0, pad1 = 0}, df = 0, u64 = 0, d64 = 0, f = 0, d = 0, ud = 0}}, offset = 0}, stride = 1 '\001'}, {<backend_reg> = {<brw_reg> = {{{type = BRW_REGISTER_TYPE_F, file = VGRF, negate = 0, abs = 0, address_mode = 0, pad0 = 0, subnr = 0, nr = 46}, bits = 3014722}, {{swizzle = 0, writemask = 0, indirect_offset = 0, vstride = 0, width = 0, hstride = 0, pad1 = 0}, df = 0, u64 = 0, d64 = 0, f = 0, d = 0, ud = 0}}, offset = 0}, stride = 1 '\001'}, {<backend_reg> = {<brw_reg> = {{{type = BRW_REGISTER_TYPE_F, file = VGRF, negate = 0, abs = 0, address_mode = 0, pad0 = 0, subnr = 0, nr = 47}, bits = 3080258}, {{swizzle = 0, writemask = 0, indirect_offset = 0, vstride = 0, width = 0, hstride = 0, pad1 = 0}, df = 0, u64 = 0, d64 = 0, f = 0, d = 0, ud = 0}}, offset = 0}, stride = 1 '\001'}, {<backend_reg> = {<brw_reg> = {{{type = BRW_REGISTER_TYPE_F, file = VGRF, negate = 0, abs = 0, address_mode = 0, pad0 = 0, subnr = 0, nr = 48}, bits = 3145794}, {{swizzle = 0, writemask = 0, indirect_offset = 0, vstride = 0, width = 0, hstride = 0, pad1 = 0}, df = 0, u64 = 0, d64 = 0, f = 0, d = 0, ud = 0}}, offset = 0}, stride = 1 '\001'}, {<backend_reg> = {<brw_reg> = {{{type = BRW_REGISTER_TYPE_F, file = VGRF, negate = 0, abs = 0, address_mode = 0, pad0 = 0, subnr = 0, nr = 49}, bits = 3211330}, {{swizzle = 0, writemask = 0, indirect_offset = 0, vstride = 0, width = 0, hstride = 0, pad1 = 0}, df = 0, u64 = 0, d64 = 0, f = 0, d = 0, ud = 0}}, offset = 0}, stride = 1 '\001'}, {<backend_reg> = {<brw_reg> = {{{type = BRW_REGISTER_TYPE_F, file = VGRF, negate = 0, abs = 0, address_mode = 0, pad0 = 0, subnr = 0, nr = 50}, bits = 3276866}, {{swizzle = 0, writemask = 0, indirect_offset = 0, vstride = 0, width = 0, hstride = 0, pad1 = 0}, df = 0, u64 = 0, d64 = 0, f = 0, d = 0, ud = 0}}, offset = 0}, stride = 1 '\001'}, {<backend_reg> = {<brw_reg> = {{{type = BRW_REGISTER_TYPE_F, file = VGRF, negate = 0, abs = 0, address_mode = 0, pad0 = 0, subnr = 0, nr = 51}, bits = 3342402}, {{swizzle = 0, writemask = 0, indirect_offset = 0, vstride = 0, width = 0, hstride = 0, pad1 = 0}, df = 0, u64 = 0, d64 = 0, f = 0, d = 0, ud = 0}}, offset = 0}, stride = 1 '\001'}, {<backend_reg> = {<brw_reg> = {{{type = BRW_REGISTER_TYPE_UD, file = BAD_FILE, negate = 0, abs = 0, address_mode = 0, pad0 = 0, subnr = 0, nr = 0}, bits = 120}, {{swizzle = 0, writemask = 0, indirect_offset = 0, vstride = 0, width = 0, hstride = 0, pad1 = 0}, df = 0, u64 = 0, d64 = 0, f = 0, d = 0, ud = 0}}, offset = 0}, stride = 1 '\001'} <repeats 56 times> } As you might notice, this means we have 7 times pretty much the same entry, the only difference is this: nr = 44}, bits = 2883650 nr = 46}, bits = 3014722 nr = 47}, bits = 3080258 nr = 48}, bits = 3145794 nr = 49}, bits = 3211330 nr = 50}, bits = 3276866 nr = 51}, bits = 3342402
Here's the usable part of the stack-trace: #0 0x00007ffff2b6bfeb in raise () at /lib64/libc.so.6 #1 0x00007ffff2b565c1 in abort () at /lib64/libc.so.6 #2 0x00007ffff2b56491 in _nl_load_domain.cold.0 () at /lib64/libc.so.6 #3 0x00007ffff2b64752 in () at /lib64/libc.so.6 #4 0x00007ffec5c59841 in fs_visitor::emit_fb_writes() (this=0x7ffffffebae0) at ../src/intel/compiler/brw_fs_visitor.cpp:449 #5 0x00007ffec5c1fc57 in fs_visitor::run_fs(bool, bool) (this=0x7ffffffebae0, allow_spilling=true, do_rep_send=false) at ../src/intel/compiler/brw_fs.cpp:6798 #6 0x00007ffec5c20bd7 in brw_compile_fs(brw_compiler const*, void*, void*, brw_wm_prog_key const*, brw_wm_prog_data*, nir_shader const*, gl_program*, int, int, int, bool, bool, brw_vue_map*, char**) (compiler=0x5555565c9030, log_data=0x55555d128350, mem_ctx=0x55555c8f3790, key=0x7ffffffec8f0, prog_data=0x7ffffffec5d0, src_shader=0x55555ce58970, prog=0x55555d4538e0, shader_time_index8=-1, shader_time_index16=-1, shader_time_index32=-1, allow_spilling=true, use_rep_send=false, vue_map=0x7ffffffec810, error_str=0x7ffffffec5c8) at ../src/intel/compiler/brw_fs.cpp:7151 #7 0x00007ffec54c49bb in brw_codegen_wm_prog (brw=0x55555d128350, fp=0x55555d4538e0, key=0x7ffffffec8f0, vue_map=0x7ffffffec810) at ../src/mesa/drivers/dri/i965/brw_wm.c:179 #8 0x00007ffec54c5fb5 in brw_fs_precompile (ctx=0x55555d128350, prog=0x55555d4538e0) at ../src/mesa/drivers/dri/i965/brw_wm.c:678 #9 0x00007ffec54a860d in brw_shader_precompile(gl_context*, gl_shader_program*) (ctx=0x55555d128350, sh_prog=0x55555cfd3850) at ../src/mesa/drivers/dri/i965/brw_link.cpp:56 #10 0x00007ffec54a988c in brw_link_shader(gl_context*, gl_shader_program*) (ctx=0x55555d128350, shProg=0x55555cfd3850) at ../src/mesa/drivers/dri/i965/brw_link.cpp:375 #11 0x00007ffec57fb46e in _mesa_glsl_link_shader(gl_context*, gl_shader_program*) (ctx=0x55555d128350, prog=0x55555cfd3850) at ../src/mesa/program/ir_to_mesa.cpp:3174 #12 0x00007ffec5664996 in link_program (no_error=false, shProg=0x55555cfd3850, ctx=0x55555d128350) at ../src/mesa/main/shaderapi.c:1206 #13 0x00007ffec5664996 in link_program_error (ctx=0x55555d128350, shProg=0x55555cfd3850) at ../src/mesa/main/shaderapi.c:1286 #14 0x00007ffec5665f9a in _mesa_LinkProgram (programObj=66) at ../src/mesa/main/shaderapi.c:1778 #15 0x00007ffff7b7d475 in add_shader_program (ctx=ctx@entry=0x55555cd79d50, vs=<optimized out>, fs=fs@entry=0x55555d303100, gs=0x0, tcs=0x0, tes=0x0) at ../../src/vrend_renderer.c:1328 #16 0x00007ffff7b82602 in vrend_draw_vbo (ctx=0x55555cd79d50, info=info@entry=0x7fffffffce10, cso=<optimized out>, indirect_handle=<optimized out>, indirect_draw_count_handle=<optimized out>) at ../../src/vrend_renderer.c:3876 #17 0x00007ffff7b9eee8 in vrend_decode_draw_vbo (length=12, ctx=0x55555d4066d0) at ../../src/vrend_decode.c:422 #18 0x00007ffff7b9eee8 in vrend_decode_block (ctx_id=<optimized out>, block=<optimized out>, ndw=<optimized out>) at ../../src/vrend_decode.c:1374
+1, still reproducible with mesa-dri-drivers-18.3.4-1.fc29.x86_64
hi guys. Could you please provide more info about reproducing steps? Below my findings and steps, and I couldn't reproduce this issue yet. sudo "$QEMU_VIRGL_PATH" -hda /var/lib/libvirt/images/ubuntu18.04.qcow2 -cdrom /home/den/Downloads/ubuntu-18.04.1-desktop-amd64.iso -boot once=c,menu=off -enable-kvm -device virtio-vga,virgl=on -device nec-usb-xhci -device usb-tablet -no-reboot -soundhw ac97 -m 2048 -display sdl,gl=on -name "ubuntu18.04.vmware" $* here is how I am running VM. From here I took man for QEMU compiling with virgl support https://at.projects.genivi.org/wiki/display/GDP/QEMU+with+hardware+graphics+acceleration?src=contextnavpagetreemode Configuration: Ubuntu 18.04 kernel 4.15.0-29 name of display: :0 display: :0 screen: 0 direct rendering: Yes Extended renderer info (GLX_MESA_query_renderer): Vendor: Red Hat (0x1af4) Device: virgl (0x1010) Version: 19.1.0 Accelerated: yes Video memory: 0MB Unified memory: no Preferred profile: compat (0x2) Max core profile version: 0.0 Max compat profile version: 2.1 Max GLES1 profile version: 1.1 Max GLES[23] profile version: 3.0 OpenGL vendor string: Red Hat OpenGL renderer string: virgl OpenGL version string: 2.1 Mesa 19.1.0-devel (git-19ab082001) OpenGL shading language version string: 1.20 Mesa was compiled from source (as I understand, with debug enabled): meson -Dbuildtype=debug -Dvalgrind=false -Ddri-drivers=i965 -Dgallium-drivers=virgl -Dvulkan-drivers= -Dgallium-omx="disabled" -Dplatforms=x11,drm,surfaceless -Dtools=intel ./mbuild64/ And here is dmesg output, to be sure that virgl really was enabled: tester@tester-Standard-PC-i440FX-PIIX-1996:~/repository/piglit/results/quick_gl$ dmesg | grep gl [ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) [ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 5 global_irq 5 high level) [ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level) [ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 10 global_irq 10 high level) [ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 11 global_irq 11 high level) [ 1.217173] [drm] virgl 3d acceleration enabled Piglit result: tester@tester-Standard-PC-i440FX-PIIX-1996:~/repository/piglit$ ./piglit run quick_gl -t ".*arb_blend_func_extended-fbo-extended-blend-pattern_gles2" ~/repository/piglit/results/quick_gl/ [1/1] fail: 1 Thank you for running Piglit! Results have been written to /home/tester/repository/piglit/results/quick_gl Now I am running full "quick_gl" suite. Intermediate result: skip 39, pass - 174, fail 29 My original HW is: KBL (Intel HD620) kernel 4.20.6-042006-generic
Oh... error in i965... Ok, I will compile mesa with debug flags on host machine too. btw - all suite running crashes gnome-shell. I think that's because less of RAM. Checking
ok. Summarizing: 1. Built mesa version (debug) latest from git 2. Launched VM: sudo "$QEMU_VIRGL_PATH" -hda /var/lib/libvirt/images/ubuntu18.04.qcow2 -cdrom /home/den/Downloads/ubuntu-18.04.1-desktop-amd64.iso -boot once=c,menu=off -enable-kvm -device virtio-vga,virgl=on -device nec-usb-xhci -device usb-tablet -no-reboot -soundhw ac97 -m 4096 -display sdl,gl=on -name "ubuntu18.04.vmware" $* 3. Ran piglit test: piglit run quick_gl -t ".*arb_blend_func_extended-fbo-extended-blend-pattern_gles2" results/quick_gl/ Result: test failed, nothing was printed into the main (host) console. UPD - during running this test (in a suite or separately) >./streaming-texture-leak -auto gnome-shell always crashing. dmesg says that it requieres swap, which I didn't allocate... so this shouldn't relate to the original ticket. here is output from host console from the VM start: https://gist.github.com/DenKos363/4e3b76f6f379dc1084e4e95d6a727ef7
(In reply to Denis from comment #4) > hi guys. Could you please provide more info about reproducing steps? Below > my findings and steps, and I couldn't reproduce this issue yet. Thanks for trying! > Piglit result: > tester@tester-Standard-PC-i440FX-PIIX-1996:~/repository/piglit$ ./piglit run > quick_gl -t ".*arb_blend_func_extended-fbo-extended-blend-pattern_gles2" > ~/repository/piglit/results/quick_gl/ > [1/1] fail: 1 > Thank you for running Piglit! > Results have been written to /home/tester/repository/piglit/results/quick_gl > hmm, are you testing with X with DISPLAY set? (I test with Xorg & mutter started manually) Then: DISPLAY=:42 ./piglit run -t ".*arb_blend_func_extended-fbo-extended-blend-pattern_gles2" -o -v tests/quick_gl results/quick_gl Will crash qemu in i965_dri.so: #2 0x00007f182daaa769 in __assert_fail_base (fmt=0x7f182dc11e90 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=0x7f182a932148 "!prog_data->dual_src_blend || key->nr_color_regions == 1", file=0x7f182a932088 "../src/intel/compiler/brw_fs_visitor.cpp", line=449, function=<optimized out>) at assert.c:92 #3 0x00007f182dab89f6 in __GI___assert_fail (assertion=0x7f182a932148 "!prog_data->dual_src_blend || key->nr_color_regions == 1", file=0x7f182a932088 "../src/intel/compiler/brw_fs_visitor.cpp", line=449, function=0x7f182a9327c0 "void fs_visitor::emit_fb_writes()") at assert.c:101 I can try to get a better backtrace.
>hmm, are you testing with X with DISPLAY set? (I test with Xorg & mutter started manually) In my case I am booting into "regular" OS. I mean, X and gnome-shell are starting automatically after login. Will try to start X manually
X.Org X Server 1.19.6 Release Date: 2017-12-20 X Protocol Version 11, Revision 0 Build Operating System: Linux 4.4.0-119-generic x86_64 Ubuntu Current Operating System: Linux tester-Standard-PC-i440FX-PIIX-1996 4.15.0-29-generic #31-Ubuntu SMP Tue Jul 17 15:39:52 UTC 2018 x86_64 Kernel command line: BOOT_IMAGE=/boot/vmlinuz-4.15.0-29-generic root=UUID=763a1b48-0913-49e9-951e-216479e9132d ro quiet splash vt.handoff=1 Build Date: 13 April 2018 08:07:36PM xorg-server 2:1.19.6-1ubuntu4 (For technical support please see http://www.ubuntu.com/support) Current version of pixman: 0.34.0 Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. current Xorg version. If you have more resent (1.20+) then possibly I should update my version and recheck. Could you please check it?
I compiled mesa git on the host, reproduced the crash Host virgl, qemu, mesa, are git master version. Guest mesa is git master version. I run in f29 VM started as multi-user target, and run Xorg and mutter manually (Xorg -nolisten tcp -noreset :42 vt5 -auth /tmp/xauth). xorg 1.20.3-3.fc29 mutter-3.30.2-2.fc29 Thread 1 "qemu-system-x86" received signal SIGABRT, Aborted. __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50 50 return ret; (gdb) bt #0 0x00007f162bd9e53f in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50 #1 0x00007f162bd88895 in __GI_abort () at abort.c:79 #2 0x00007f162bd88769 in __assert_fail_base (fmt=0x7f162beefe90 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=0x7f1628c726e8 "!prog_data->dual_src_blend || key->nr_color_regions == 1", file=0x7f1628c72628 "../src/intel/compiler/brw_fs_visitor.cpp", line=449, function=<optimized out>) at assert.c:92 #3 0x00007f162bd969f6 in __GI___assert_fail (assertion=assertion@entry=0x7f1628c726e8 "!prog_data->dual_src_blend || key->nr_color_regions == 1", file=file@entry=0x7f1628c72628 "../src/intel/compiler/brw_fs_visitor.cpp", line=line@entry=449, function=function@entry=0x7f1628c72d60 <fs_visitor::emit_fb_writes()::__PRETTY_FUNCTION__> "void fs_visitor::emit_fb_writes()") at assert.c:101 #4 0x00007f1628a350b5 in fs_visitor::emit_fb_writes() (this=this@entry=0x7ffc349e4e00) at ../src/intel/compiler/brw_fs_visitor.cpp:449 #5 0x00007f16289f5c7c in fs_visitor::run_fs(bool, bool) (this=this@entry=0x7ffc349e4e00, allow_spilling=allow_spilling@entry=true, do_rep_send=do_rep_send@entry=false) at ../src/intel/compiler/brw_fs.cpp:7452 #6 0x00007f16289f6c35 in brw_compile_fs(brw_compiler const*, void*, void*, brw_wm_prog_key const*, brw_wm_prog_data*, nir_shader*, gl_program*, int, int, int, bool, bool, brw_vue_map*, char**) (compiler=<optimized out>, log_data=log_data@entry=0x56304045d9a0, mem_ctx=mem_ctx@entry=0x56304031da10, key=key@entry=0x7ffc349e6630, prog_data=prog_data@entry=0x7ffc349e6300, shader=<optimized out>, shader@entry=0x5630402379e0, prog=<optimized out>, shader_time_index8=<optimized out>, shader_time_index16=<optimized out>, shader_time_index32=<optimized out>, allow_spilling=<optimized out>, use_rep_send=<optimized out>, vue_map=<optimized out>, error_str=<optimized out>) at ../src/intel/compiler/brw_fs.cpp:7803 #7 0x00007f162850ca43 in brw_codegen_wm_prog (brw=brw@entry=0x56304045d9a0, fp=fp@entry=0x563040234880, key=key@entry=0x7ffc349e6630, vue_map=0x7ffc349e6550) at ../src/mesa/drivers/dri/i965/brw_wm.c:184 #8 0x00007f162850e9e2 in brw_fs_precompile (ctx=ctx@entry=0x56304045d9a0, prog=0x563040234880) at ../src/mesa/drivers/dri/i965/brw_wm.c:705 #9 0x00007f16284f8144 in brw_shader_precompile (sh_prog=0x563040314520, ctx=0x56304045d9a0) at ../src/mesa/drivers/dri/i965/brw_link.cpp:56 #10 0x00007f16284f8144 in brw_link_shader(gl_context*, gl_shader_program*) (ctx=0x56304045d9a0, shProg=0x563040314520) at ../src/mesa/drivers/dri/i965/brw_link.cpp:377 #11 0x00007f16286ff7f9 in _mesa_glsl_link_shader(gl_context*, gl_shader_program*) (ctx=ctx@entry=0x56304045d9a0, prog=prog@entry=0x563040314520) at ../src/mesa/program/ir_to_mesa.cpp:3170 #12 0x00007f16285c19d9 in link_program (no_error=<optimized out>, shProg=<optimized out>, ctx=<optimized out>) at ../src/mesa/main/shaderapi.c:1206 #13 0x00007f16285c19d9 in link_program_error (shProg=0x563040314520, ctx=0x56304045d9a0) at ../src/mesa/main/shaderapi.c:1286 #14 0x00007f16285c19d9 in link_program_error (ctx=0x56304045d9a0, shProg=0x563040314520) at ../src/mesa/main/shaderapi.c:1284 #15 0x00007f162e4a23e0 in add_shader_program () at /home/user/src/virgl/lib/libvirglrenderer.so.0 #16 0x00007f162e4aa8e9 in vrend_draw_vbo () at /home/user/src/virgl/lib/libvirglrenderer.so.0 #17 0x00007f162e4d5700 in vrend_decode_draw_vbo () at /home/user/src/virgl/lib/libvirglrenderer.so.0 #18 0x00007f162e4d83f0 in vrend_decode_block () at /home/user/src/virgl/lib/libvirglrenderer.so.0 #19 0x00007f162e49e704 in virgl_renderer_submit_cmd () at /home/user/src/virgl/lib/libvirglrenderer.so.0
Ok, at least we have different X versions. Will try to update it and recheck. Could you please also show how did you compile mesa? To be sure that we have the same configuration in it. Btw, about qemu, i sent s link to manual, with qemu version i took >wget http://download.qemu-project.org/qemu-2.12.0.tar.xz This one. So if you compiled from git, then you have fresher version, will check and this thing.
(In reply to Denis from comment #11) > Ok, at least we have different X versions. Will try to update it and > recheck. Could you please also show how did you compile mesa? To be sure > that we have the same configuration in it. On host: meson build -Dprefix=$PREFIX -Dlibdir=lib \ -Dplatforms=drm,x11,wayland,surfaceless \ -Ddri-drivers=i965 \ -Dgallium-drivers=virgl,swrast On guest: meson build -Dprefix=/usr \ -Dplatforms=x11,drm,surfaceless,wayland \ -Dgallium-drivers=virgl,swrast \ -Dselinux=true > > Btw, about qemu, i sent s link to manual, with qemu version i took > >wget http://download.qemu-project.org/qemu-2.12.0.tar.xz > This one. So if you compiled from git, then you have fresher version, will > check and this thing. fwiw, I'll attach the shell script I use for testing (it's not automated, but gives you an idea of the commands I use to setup tests)
Created attachment 143680 [details] test setup script
Hi, thanks for the script. I found out, that during discussion I didn't ask your HW configuration (on host). Provide it please (in my case, I tested on KBL and CFL). I can't apply it on my PC, but looks like you don't do anything special or extra, comparing with my manual setup, except that fact that you are running X manually. As I said, I am running VM as usual OS (and strange, but I can't switch to another TTY in it, to run one more session manually. I read that QEMU has terminal Ctrl+Alt+2, as example, where I can send keys combination, but it doesn't work for me). So what I did - I created manually one more image and installed fedora29 there. Then updated all packages, setup piglit and ran these tests (using X and using Wayland) on system mesa (18.3.4 in VM) - in both cases they passed. Host machine: Manjaro (CoffeLake) Mesa 19.1.0-devel (git-2ac5c5c1b5) (with debug enabled) The only thing which "hanged" or crashed my VM, was running all suite: >piglit run quick_gl ./results/quick_gl/ Errors below (VM became black with blinking cursor on the top left part of the screen) printed in "host" cmd (not sure that it related to current report): fsout_c7 = fsout_c0; } vrend_hw_emit_rs: core profile violation reported 22 "Xwayland" Stipple 0 vrend_hw_emit_rs: core profile violation reported 22 "Xwayland" Stipple 0 vrend_hw_emit_rs: core profile violation reported 22 "Xwayland" Stipple 0 vrend_hw_emit_rs: core profile violation reported 22 "Xwayland" Stipple 0 vrend_hw_emit_rs: core profile violation reported 22 "Xwayland" Stipple 0 vrend_hw_emit_rs: core profile violation reported 22 "Xwayland" Stipple 0 virtio_gpu_virgl_process_cmd: ctrl 0x106, error 0x1200 virtio_gpu_virgl_process_cmd: ctrl 0x106, error 0x1200 vrend_renderer_transfer_iov: context error reported 23 "Xwayland" Illegal resource 72332 virtio_gpu_virgl_process_cmd: ctrl 0x106, error 0x1200 virtio_gpu_virgl_process_cmd: ctrl 0x106, error 0x1200 virtio_gpu_virgl_process_cmd: ctrl 0x106, error 0x1200 virtio_gpu_virgl_process_cmd: ctrl 0x106, error 0x1200 vrend_renderer_transfer_iov: context error reported 23 "Xwayland" Illegal resource 72787 virtio_gpu_virgl_process_cmd: ctrl 0x106, error 0x1200 virtio_gpu_virgl_process_cmd: ctrl 0x106, error 0x1200 virtio_gpu_virgl_process_cmd: ctrl 0x106, error 0x1200 vrend_renderer_transfer_iov: context error reported 23 "Xwayland" Illegal resource 72855 virtio_gpu_virgl_process_cmd: ctrl 0x106, error 0x1200 virtio_gpu_virgl_process_cmd: ctrl 0x106, error 0x1200 virtio_gpu_virgl_process_cmd: ctrl 0x106, error 0x1200
hi Marc-Andre, Erik. Do you have any updates or new information about this issue?
-- 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/mesa/mesa/issues/1756.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.