You are not logged in.
This error occurs on any Chromium-based browsers as well as any Electron-based apps like FreeTube for example
Same there as well?
I was so surprised by this that I forgot to check if this error occurs with other applications as well.
Have you tried the behavior w/ the LTS kernel?
Not yet. Will give it a try and report.
Offline
Here's my report:
The error occurs with Linux 6.6 as well. Tested with Virt-Manager 3D-Acceleration|OpenGL settings.
I'll focus on that error now. Together with the graphics glitch in Doom 3 it is easily reproducible, unlike the artifacts in e.g. FreeTube, which appear to be random.
Offline
https://bbs.archlinux.org/viewtopic.php … 3#p2204343 ?
Though that should and did affect pretty much everything…
Also
printenv | grep -iE '(mesa|sdl|gl)' # though that makes no sense w/ the fresh system
Offline
Also
printenv | grep -iE '(mesa|sdl|gl)' # though that makes no sense w/ the fresh system
Disclaimer: I'm on my own system again with no direct access to my friend's system.
grep -iE '(mesa|sdl|gl)
yields
KGLOBALACCELD_PLATFORM=org.kde.kwin
MESA_VK_DEVICE_SELECT=8086:7d55
VDPAU_DRIVER=va_gl
__EGL_VENDOR_LIBRARY_FILENAMES=/usr/share/glvnd/egl_vendor.d/50_mesa.json
__GLX_VENDOR_LIBRARY_NAME=mesa
LS_COLORS=rs=0:di=01;34:ln=01;36:mh=00:pi=40;33:so=01;35:do=01;35:bd=40;33;01:cd=40;33;01:or=40;31;01:mi=00:su=37;41:sg=30;43:ca=00:tw=30;42:ow=34;42:st=37;44:ex=01;32:*.7z=01;31:*.ace=01;31:*.alz=01;31:*.apk=01;31:*.arc=01;31:*.arj=01;31:*.bz=01;31:*.bz2=01;31:*.cab=01;31:*.cpio=01;31:*.crate=01;31:*.deb=01;31:*.drpm=01;31:*.dwm=01;31:*.dz=01;31:*.ear=01;31:*.egg=01;31:*.esd=01;31:*.gz=01;31:*.jar=01;31:*.lha=01;31:*.lrz=01;31:*.lz=01;31:*.lz4=01;31:*.lzh=01;31:*.lzma=01;31:*.lzo=01;31:*.pyz=01;31:*.rar=01;31:*.rpm=01;31:*.rz=01;31:*.sar=01;31:*.swm=01;31:*.t7z=01;31:*.tar=01;31:*.taz=01;31:*.tbz=01;31:*.tbz2=01;31:*.tgz=01;31:*.tlz=01;31:*.txz=01;31:*.tz=01;31:*.tzo=01;31:*.tzst=01;31:*.udeb=01;31:*.war=01;31:*.whl=01;31:*.wim=01;31:*.xz=01;31:*.z=01;31:*.zip=01;31:*.zoo=01;31:*.zst=01;31:*.avif=01;35:*.jpg=01;35:*.jpeg=01;35:*.mjpg=01;35:*.mjpeg=01;35:*.gif=01;35:*.bmp=01;35:*.pbm=01;35:*.pgm=01;35:*.ppm=01;35:*.tga=01;35:*.xbm=01;35:*.xpm=01;35:*.tif=01;35:*.tiff=01;35:*.png=01;35:*.svg=01;35:*.svgz=01;35:*.mng=01;35:*.pcx=01;35:*.mov=01;35:*.mpg=01;35:*.mpeg=01;35:*.m2v=01;35:*.mkv=01;35:*.webm=01;35:*.webp=01;35:*.ogm=01;35:*.mp4=01;35:*.m4v=01;35:*.mp4v=01;35:*.vob=01;35:*.qt=01;35:*.nuv=01;35:*.wmv=01;35:*.asf=01;35:*.rm=01;35:*.rmvb=01;35:*.flc=01;35:*.avi=01;35:*.fli=01;35:*.flv=01;35:*.gl=01;35:*.dl=01;35:*.xcf=01;35:*.xwd=01;35:*.yuv=01;35:*.cgm=01;35:*.emf=01;35:*.ogv=01;35:*.ogx=01;35:*.aac=00;36:*.au=00;36:*.flac=00;36:*.m4a=00;36:*.mid=00;36:*.midi=00;36:*.mka=00;36:*.mp3=00;36:*.mpc=00;36:*.ogg=00;36:*.ra=00;36:*.wav=00;36:*.oga=00;36:*.opus=00;36:*.spx=00;36:*.xspf=00;36:*~=00;90:*#=00;90:*.bak=00;90:*.crdownload=00;90:*.dpkg-dist=00;90:*.dpkg-new=00;90:*.dpkg-old=00;90:*.dpkg-tmp=00;90:*.old=00;90:*.orig=00;90:*.part=00;90:*.rej=00;90:*.rpmnew=00;90:*.rpmorig=00;90:*.rpmsave=00;90:*.swp=00;90:*.tmp=00;90:*.ucf-dist=00;90:*.ucf-new=00;90:*.ucf-old=00;90:
Offline
That's from our vulkan tests? But vkcube was unaffected anyway.
Did you see the max bpc thread?
Doom3 is the open source linux client, not some windows binary?
Offline
That's from our vulkan tests? But vkcube was unaffected anyway.
Whuat. What are you talking about now? If you're referring to my latest codeblock, that was the output of
printenv | grep -iE '(mesa|sdl|gl)'
Did you see the max bpc thread?
The one you've linked? Yes, but I don't think these issues are related :-(
Doom3 is the open source linux client, not some windows binary?
Yes, open source client.
Offline
What are you talking about now?
MESA_VK_DEVICE_SELECT=8086:7d55
VDPAU_DRIVER=va_gl
__EGL_VENDOR_LIBRARY_FILENAMES=/usr/share/glvnd/egl_vendor.d/50_mesa.json
__GLX_VENDOR_LIBRARY_NAME=mesa
They're probably left overs from earlier efforts to fix this?
If not, remove/unet those and try again.
Yes, but I don't think these issues are related :-(
I don't really either, but we're starting to run out of reasonable explanations…
Did you use the ame monitor on both systems?
Last edited by seth (2024-11-10 16:52:53)
Offline
They're probably left overs from earlier efforts to fix this?
If not, remove/unet those and try again.
Not quite. They are there to prevent certain processes from running on the NVIDIA eGPU. But the issue at hand precedes these settings, so I know for sure they are not related.
I don't really either, but we're starting to run out of reasonable explanations…
Did you use the ame monitor on both systems?
Nope, as I've said before, no hardware or software or files or configs or peripherals were linked to my system when the same error occurred on my friend's desktop.
You're right though, this is getting tedious. Say, do you know where I can report qemu/virt-manager/libvirt/virtio bugs and errors? Do they have a Github of some sorts? I couldn't find a definite place to report this.
Offline
Is the eGPU attached when this happens?
Does doom3 or qemu run ok on the nvidia GPU?
https://libvirt.org/bugs.html but w/ the Doom3 issues (did we test https://archlinux.org/packages/extra/x86_64/xonotic/ or https://archlinux.org/packages/extra/x86_64/warsow/ or so?) there must be some common element/wider factor (SDL?)
The default mesa dri definitions include
<application name="Doom 3: BFG" executable="Doom3BFG.exe">
<option name="allow_glsl_builtin_variable_redeclaration" value="true" />
<option name="force_glsl_extensions_warn" value="true" />
</application>
which will likely not meet your doom executable - what if you run it sth. like
allow_glsl_builtin_variable_redeclaration=true force_glsl_extensions_warn=true doom3
?
Offline
Is the eGPU attached when this happens?
As I've said, the issue predates my eGPU setup.
Does doom3 or qemu run ok on the nvidia GPU?
I've tried switching to NVIDIA for Renderer in OpenGL settings in Qemu, but it didn't work. Doom3 ran flawlessly on the eGPU I had before the NVIDIA (Intel Arch A770 LE)
https://libvirt.org/bugs.html but w/ the Doom3 issues (did we test https://archlinux.org/packages/extra/x86_64/xonotic/ or https://archlinux.org/packages/extra/x86_64/warsow/ or so?) there must be some common element/wider factor (SDL?)
Tested with Xonotic (SDL and GLX), ran flawlessly.
The default mesa dri definitions include
<application name="Doom 3: BFG" executable="Doom3BFG.exe"> <option name="allow_glsl_builtin_variable_redeclaration" value="true" /> <option name="force_glsl_extensions_warn" value="true" /> </application>
which will likely not meet your doom executable - what if you run it sth. like
allow_glsl_builtin_variable_redeclaration=true force_glsl_extensions_warn=true doom3
?
I've banned Doom III to my VM :-D
I'd have to re-install it and re-install the native port/mod.
But I made another discovery that may help us. I've been trying to pinpoint the issue with Chromium-based applications and I think I found the culprit:
This is when running Brave with "--ozone-platform-hint=auto --enable-features=VaapiVideoDecodeLinuxGL". Hardware acceleration is confirmed to be active with intel_gpu_top.
This is the same scenario, but this time the flag "--ozone-platform-hint=auto". Hardware acceleration is confirmed to be active with intel_gpu_top.
On a side note, what about the pictures? I understand posting pictures is generally discouraged here, but this is a graphical issue, so I guess it is appropriate to post graphics for illustration?
Offline
https://bbs.archlinux.org/viewtopic.php?id=244031&p=33
Browser video HW accel is a special (and sad) case.
https://wiki.archlinux.org/title/Hardwa … tion#Intel
pacman -Qs intel
https://wiki.archlinux.org/title/Hardwa … ing_VA-API
The browser artifacts are then limited to video playback only?
So the remaining offenders are doom3 and libvirt?
On a side note, what about the pictures?
You're supposed to link them and not embed anything > 250x250, regardless of the nature of the thread to keep loading fast and the mouse wheel cool.
Offline