Launching server with SteamVR + ALVR results in OpenGL logspam
When I try to launch the actual server on a real device using SteamVR + ALVR + AVP, I just get this printed to the console, and it just stays loading in SteamVR:
I initially tried with the Fedora packaged version, and that had the same issue as above (except ending in a segfault), and I just get that spam above with no segfault when built in dev mode locally. Flatscreen works fine, though.
Is this possibly due to Nvidia proprietary drivers? I'm using Nvidia driver version 575.64.05.
27 Replies
yep, it's probably nvidia
we're refactoring the server to use opengl
so this hopefully shouldn''t be an issue much longer
Ah got it
wait
i meant to not use opengl
to use vulkan
my brain does NOT wanna work today :blobcatgoogly:
Okay that makes a bit more sense
anyway if you wanna get an update when that's finished i can give you stardust notification role
yeah that'd be dope
thanks
here's a sneak peek btw
the server is using bevy now, with a custom wayland impl from scratch to take advantage of vulkan with the dmabufs
are those things that would have been laggy in opengl, or just useful tests for the vulkan implementation? sorry i'm not super familiar with graphics programming lol
ohhh no that's just a fun client i mocked up in a few hours
and it looked neat
ah gotcha lol
realistically for now vulkan is just for compatibility with everything, using the gpu that openxr is using (your dedicated one if present), working on nvidia, and eventually gaussian splatting
is the nvidia opengl implementation not quite the same as the open source driver implementations?
no, they impl their own
except if you use mesa which is glitchy in other ways
vulkan lets us guarantee we can pick the right gpu that openxr does
100% of the time
and so far it just works on nvidia
will have to ensure that's the case with wayland dmabuf tho
by pick the right gpu, you mean for people who have an igpu + a dedicated gpu, sometimes it will render stardust on a different gpu than openxr?
the old stereokit one is hardcoded to use
/dev/dri/renderD128
no matter what
because openxr never tells us what gpu is used when using opengl!!!
and i couldn't find a reliable way to guesstimate which it would be
but openxr tells us (via vulkan_enable2) what vkdevice is used when using vulkanlol that sounds painful
yes indeed
that's why it's been 10 MONTHS since the last release loooll
lol
anyways, thanks for the project! i'll keep an eye out for that update. also, not sure if useful, but i'd be happy to contribute any low hanging fruit that may exist - i kind of know my way around systems programming, though I've never really dealt with graphics. otherwise, happy to beta test whenever this gets there
!! yea i think there's a few things that'd be a huge help
you know rust?
i don't really need as much graphics help rn (i mean i do but schmarni knows enough)
but there's some abstracting of things that'd make code wayyy easier to maintain
using dbus and tokio and all
I made a toy wgpu project a while back (like a year or two at least lol), but I'm decently experienced with C++, though nowadays I do more JS than anything else :P
I'm a bit rusty with lower level stuff, but I think I could probably pick it back up without too much difficulty
C++ != Rust though, so not sure if there's some basic stuff that's alright for someone to get their feet wet - I don't want to be a net burden with review as opposed to a net benefit lol
wgpu isn't c++ though right?
yeah i made a toy rust app
nice nice
was trying to make a race sim with proper kinematics and such, then got busy and didn't finish lol
mood