Hi, I’m attending the GTC lectures this week on CloudXR 4.0, should we assume these talks will actually coincide with a 4.0 release?
Since CloudXR 4.0 is only coming out a couple months, it still leaves a lot of open questions.
The server-side direct engine plugin is very interesting, as is the integration with Monado to get a true OpenXR plugin that works both on Windows and Linux, natively.
However, I don’t see a huge advantage to removing SteamVR as a dependency unless there are also client samples that use OpenXR, because this is how one accesses special features like hand, eye, body tracking these days. So you would still have an information bottleneck unless you write your own OpenXR client, enable those extensions, then forward all that data and functionality through CloudXR and have the server end expose them using the same OpenXR extensions, as if it were accessing the HMD locally. This won’t be possible for all cases, obviously (things like Local Dimming), but passthrough is a must-have feature that you mentioned will have support in some way, and that’s also accessed through OpenXR on Quest.
Can an Nvidia rep confirm whether there will be an OpenXR-based client sample that runs on standalones?
It’s 2023, all those proprietary SDKs are long-since deprecated.
Everyone’s using OpenXR now, it’s time Nvidia jumps on board. I was surprised originally when I started using CloudXR professionally last year, that despite the name, it has nothing to do with OpenXR.
We wrote our own OpenXR-based client but it’s not open source and has various issues, so it would still be good for Nvidia to make an official, clean OpenXR client that runs on a variety of headsets or non-VR devices.
@tegradave sorry to bug ya, but I’d really like to know the answer to this for my roadmap planning, if you’re able to tell us.
From the videos on CXR 4.0 on GTC I got the impression Nvidia was focusing on OpenXR support for the server side first, but having OpenXR on both the client and the server is really necessary to achieve A-to-Z transparent feature support (like eye-, face-, hand-, and body-tracking). CloudXR should really just act as if the headset were plugged in locally, with as direct-as-possible forwarding of all the extensions / poses / feature toggles as one can have. Some features only make sense on the client side, like local dimming or Meta’s foveated rendering extension that directly affects the rasterizer, but others have no reason they can’t just be forwarded directly over the wire, like hand / body poses, eye gaze data, etc.
Like I said, I already have an OpenXR-based client implemented that uses CloudXR, but there are several issues and it would be great to have a reference implementation from Nvidia that irons out all the kinks and shows us all “best practices”. Not to mention one that works and is fully tested / proven to work on a variety of headsets.
Nvidia is in a much better place than most of us to leverage HMD vendors to fix their buggy OpenXR runtimes so that hacks/workarounds aren’t needed per platform.