VirtualGL and SecondLife
69 views
Skip to first unread message
Kevin
Apr 5, 2023, 7:04:59 PM4/5/23
to VirtualGL User Discussion/Support
Hi!
I try to run Firestorm (SecondLife 64bit) on an AMD A10-5800K CPU with a RX550 GPU.
"vglrun glxinfo" and "vglrun glxgears" and "vglrun glxspheres64" works nicely... btw: glxspheres64 at 110fps...
But: Why does Firestorm hang with a "BadWindow" error?
Was anybody able to play Second Life with VirtualGL?
Thx.
Bye.
DRC
Apr 6, 2023, 10:20:14 PM4/6/23
to virtual...@googlegroups.com
Which driver are you using? If it's the open source AMDGPU driver, then
you might try setting VGL_AMDGPUHACK=1 in the environment.
Is it reproducible without creating a SecondLife account or jumping
through other hoops?
DRC
you might try setting VGL_AMDGPUHACK=1 in the environment.
Is it reproducible without creating a SecondLife account or jumping
through other hoops?
DRC
Kevin
Apr 7, 2023, 11:52:16 AM4/7/23
to VirtualGL User Discussion/Support
It is the amdgpu kernel module in the kernel package "linux-6.2.9.arch1-1" of ArchLinux.
You do not need a login... You can just download it from here: https://www.firestormviewer.org/linux/
Then unpack it... Have pulseaudio ready... And start in Phoenix-Firestorm-Releasex64-6-6-8-68380 this command: vglrun ./firestorm
In the end (before anything is drawn in the window, that pops up) i see this message:
X Error of failed request: BadDrawable (invalid Pixmap or Window parameter)
Major opcode of failed request: 152 (GLX)
Minor opcode of failed request: 29 (X_GLXGetDrawableAttributes)
Resource id in failed request: 0xa0000e
Serial number of failed request: 81
Current serial number in output stream: 81
Major opcode of failed request: 152 (GLX)
Minor opcode of failed request: 29 (X_GLXGetDrawableAttributes)
Resource id in failed request: 0xa0000e
Serial number of failed request: 81
Current serial number in output stream: 81
After that it only talks about HTTP and some cache issue...
Does the error message tell u something?
Funnily Singularity_1_8_9_8338_x86_64 works nicely...
But i prefer Firestorm...
Kevin
Apr 7, 2023, 12:38:58 PM4/7/23
to VirtualGL User Discussion/Support
oh...
and export VGL_AMDGPUHACK=1 does not change it...
Kevin
Apr 12, 2023, 2:59:00 PM4/12/23
to VirtualGL User Discussion/Support
Is this bug related?
On Friday, April 7, 2023 at 2:20:14 AM UTC DRC wrote:
DRC
May 3, 2023, 12:28:03 PM5/3/23
to virtual...@googlegroups.com
Sorry for the lack of activity. I was ill for a few weeks in April (invasive Group A strep— I do not recommend) and am now in the process of moving halfway across the United States with my wife. I hope to be back to work on VirtualGL and TurboVNC (including finishing up the TurboVNC 3.1 beta release) by the end of next week.
DRC
On Apr 12, 2023, at 1:59 PM, Kevin <kevin.ar...@gmail.com> wrote:
--
You received this message because you are subscribed to the Google Groups "VirtualGL User Discussion/Support" group.
To unsubscribe from this group and stop receiving emails from it, send an email to virtualgl-use...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/virtualgl-users/aca78e8d-bb6f-4114-a96a-a0d942ba1b05n%40googlegroups.com.
DRC
Jul 7, 2023, 3:23:22 PM7/7/23
to virtual...@googlegroups.com
Sorry for the delay. I finally got
libjpeg-turbo 3.0 out the door, after some intense weeks of
fixing unexpected security issues, and I am back to work on
VirtualGL and TurboVNC. I can't reproduce the exact issue you
reported, but Firestorm definitely does not work with VirtualGL
at all, regardless of the GPU. (I tested a Radeon Pro and a
Quadro with the latest drivers for both, and I also tested with
both the GLX and EGL back ends in VirtualGL.) The window is
always blank, and based on the error messages, it appears as if
the issue might actually be related to the issues we're seeing
with Chrome
(https://github.com/VirtualGL/virtualgl/issues/229)-- or, more
to the point, with ANGLE. I am experimenting with a local build
of ANGLE to attempt to nail down the cause.
DRC
--
Kevin
Dec 3, 2023, 1:48:03 AM12/3/23
to VirtualGL User Discussion/Support
ok... my current workaround (a DP cable... lol) works fine... -Kev
DRC
Feb 20, 2024, 3:24:46 PMFeb 20
to virtual...@googlegroups.com
Referring to
https://github.com/VirtualGL/virtualgl/issues/229#issuecomment-1948999166,
I have spent a great deal of unpaid labor trying to figure out how to
make VirtualGL work with Chrome's ANGLE back ends, since --use-gl=egl
(which bypasses ANGLE) crashes since Chrome v112. (It crashes even
without VirtualGL.) That resulted in some nasty hacks to make VirtualGL
work with Chrome/ANGLE. Unfortunately, those nasty hacks do not change
the situation with Firestorm (which also appears to use ANGLE.)
Firestorm appears to be complaining in the same way that Chrome
complains when you don't pass --disable-seccomp-filter-sandbox to it.
That makes me suspect that the issues may be related to GPU sandboxing,
which is problematic with VirtualGL because VGL does some things (such
as calling X11 functions) that GPU sandboxes consider to be security
risks. As a side note, one possible long-term solution to that would be
to move the VGL Faker's transport thread into another process and either
transmit rendered frames to it via shared memory or pass a PBO handle to
it and let it do deferred readback (see
https://github.com/VirtualGL/virtualgl/issues/9). That wouldn't address
the other issues with ANGLE or Chrome, but it would at least make
VirtualGL more sandbox-friendly.
At the moment, there's nothing more I can do to diagnose or fix the
problem without funding. If application developers care about remote
display, then I'm happy to have a dialogue with them, but VirtualGL
exists primarily because application developers (not to mention Linux
graphics system developers) don't care much about remote display. Here
I am 20 years later still trying to hack my way around that lack of
foresight, and it's becoming increasingly difficult to do so. Various
new features in Linux applications or Linux itself have thwarted
VirtualGL or TurboVNC in recent years, with seemingly no workarounds. I
don't know what else I can reasonably do. VirtualGL has a limited
general fund that pays for maintenance, but it has received no funded
development since 2022. That funded development was in fact to figure
out a method to use Chrome with VirtualGL, which resulted in the EGL/X11
interposer in VGL 3.1.x. That method worked fine until Google broke it
in Chrome v112, thus causing me to spend 50 or 60 unpaid hours trying in
vain to unbreak it. I am more than happy to work with application
developers to resolve compatibility issues with VirtualGL, but I can't
spend my free time (with emphasis on "free") trying to make VirtualGL
work with complicated applications whose developers don't care about
VirtualGL.
Sorry for the rant. I am not ranting specifically at you. I'm more
screaming into the void regarding the sub-optimal state of Linux remote
display in general. VirtualGL was always a hack, and I never expected it
to still be necessary in 2024. I expected the Linux community to
recognize the value of remote display and figure out a better way to do
it. Wayland may eventually prove to be that better way, but at the
moment it has its own issues that are non-starters for our project (not
the least of which is failure to converge around a common compositor
implementation, i.e. it doesn't have an equivalent of Xorg.) Meanwhile,
some companies have decided that it's easier to port their entire suite
of applications to Windows than it is to deal with Linux remote
display. I'll never understand why IBM/Red Hat and other major
enterprise Linux players aren't investing more R&D money into this
problem. The value proposition of remote display for large enterprises
is well-proven at this point. Our plucky little project has saved
companies millions of dollars in workstation refresh costs and
additional millions per year in ongoing IT costs. Yet the course of
Linux development, as a whole, seems to be making it more difficult to
do what we do and failing to provide viable alternatives. This is an
open invitation to any enterprise Linux/systems/GPU company to have a
conversation with me about possible future directions for Linux remote
display and what needs to happen (IMHO) to make it viable (or at least
as good as the current state of the art on Windows.)
DRC
https://github.com/VirtualGL/virtualgl/issues/229#issuecomment-1948999166,
I have spent a great deal of unpaid labor trying to figure out how to
make VirtualGL work with Chrome's ANGLE back ends, since --use-gl=egl
(which bypasses ANGLE) crashes since Chrome v112. (It crashes even
without VirtualGL.) That resulted in some nasty hacks to make VirtualGL
work with Chrome/ANGLE. Unfortunately, those nasty hacks do not change
the situation with Firestorm (which also appears to use ANGLE.)
Firestorm appears to be complaining in the same way that Chrome
complains when you don't pass --disable-seccomp-filter-sandbox to it.
That makes me suspect that the issues may be related to GPU sandboxing,
which is problematic with VirtualGL because VGL does some things (such
as calling X11 functions) that GPU sandboxes consider to be security
risks. As a side note, one possible long-term solution to that would be
to move the VGL Faker's transport thread into another process and either
transmit rendered frames to it via shared memory or pass a PBO handle to
it and let it do deferred readback (see
https://github.com/VirtualGL/virtualgl/issues/9). That wouldn't address
the other issues with ANGLE or Chrome, but it would at least make
VirtualGL more sandbox-friendly.
At the moment, there's nothing more I can do to diagnose or fix the
problem without funding. If application developers care about remote
display, then I'm happy to have a dialogue with them, but VirtualGL
exists primarily because application developers (not to mention Linux
graphics system developers) don't care much about remote display. Here
I am 20 years later still trying to hack my way around that lack of
foresight, and it's becoming increasingly difficult to do so. Various
new features in Linux applications or Linux itself have thwarted
VirtualGL or TurboVNC in recent years, with seemingly no workarounds. I
don't know what else I can reasonably do. VirtualGL has a limited
general fund that pays for maintenance, but it has received no funded
development since 2022. That funded development was in fact to figure
out a method to use Chrome with VirtualGL, which resulted in the EGL/X11
interposer in VGL 3.1.x. That method worked fine until Google broke it
in Chrome v112, thus causing me to spend 50 or 60 unpaid hours trying in
vain to unbreak it. I am more than happy to work with application
developers to resolve compatibility issues with VirtualGL, but I can't
spend my free time (with emphasis on "free") trying to make VirtualGL
work with complicated applications whose developers don't care about
VirtualGL.
Sorry for the rant. I am not ranting specifically at you. I'm more
screaming into the void regarding the sub-optimal state of Linux remote
display in general. VirtualGL was always a hack, and I never expected it
to still be necessary in 2024. I expected the Linux community to
recognize the value of remote display and figure out a better way to do
it. Wayland may eventually prove to be that better way, but at the
moment it has its own issues that are non-starters for our project (not
the least of which is failure to converge around a common compositor
implementation, i.e. it doesn't have an equivalent of Xorg.) Meanwhile,
some companies have decided that it's easier to port their entire suite
of applications to Windows than it is to deal with Linux remote
display. I'll never understand why IBM/Red Hat and other major
enterprise Linux players aren't investing more R&D money into this
problem. The value proposition of remote display for large enterprises
is well-proven at this point. Our plucky little project has saved
companies millions of dollars in workstation refresh costs and
additional millions per year in ongoing IT costs. Yet the course of
Linux development, as a whole, seems to be making it more difficult to
do what we do and failing to provide viable alternatives. This is an
open invitation to any enterprise Linux/systems/GPU company to have a
conversation with me about possible future directions for Linux remote
display and what needs to happen (IMHO) to make it viable (or at least
as good as the current state of the art on Windows.)
DRC
Reply all
Reply to author
Forward
0 new messages