[SQU-312] [Beta] Force rendering gpu with Vuplex Webview

[Myrkie]

Feature Description: Currently the stable version of XSOverlay allows you to force what GPU it runs on through a native unity argument using the force-device-index X flag, X being the index of the GPU you want to use starting from 0

Additional context: this is nice for people with multiple GPU setups or use have integrated graphics with a dedicated GPU and want to force which GPU it renders on, as currently if a program is rendered on a separate GPU from SteamVR it will not be shown through your HMD. in the case with integrated graphics this can be a major issue, for my specific use I run the entirety of SteamVR on my second GPU separated from my main system to have more usable vram to dedicate towards intensive games that tend to max out the vram.

_SQU-312

[Xiexe]

All web rendering happens through a system in Unity. The nodeJS server doesn't render anything, it just serves the page files to you.

Are you saying the Ui pages aren't rendering on the correct gpu when you use the launch parameter.

[Myrkie]

yes, at least last time I tested the menu will become completely invisible in SteamVR when using force rendering index like how it does if rendering on the wrong GPU

[Xiexe]

That's really interesting. I'm not sure how I would go about testing that as I've only got one GPU in my system with no integrated graphics.

[Myrkie]

Im not sure how you could test it either, though here is a video of the issue occurring just tested to make see if its still an issue. as you can see any elements are not loading though it will properly load the layout previously saved. aswell as a log, it does have some stack traces in it.

https://user-images.githubusercontent.com/20288698/220196613-c4725874-0349-4c23-813e-461a3041bbd2.mp4

output_log_2023-02-20__15.47.40.txt

[Xiexe]

I'm assuming switching the GPU does result in correct behavior?

[Xiexe]

It's possible that chromium is running on the wrong gpu.

I'll do some digging and see if it has a launch parameter to change which gpu it's using.

[Myrkie]

yes, switching GPU does result in corrected behavior, thought doing that requires swapping everything to the main GPU IE: plugging the headset into the main GPU. a tool like NVIDIAs GPU activity tool tells you which processes are running on that GPU.

[Myrkie]

It's possible that chromium is running on the wrong gpu.

I'll do some digging and see if it has a launch parameter to change which gpu it's using.

do you happen to be using CEFSharp?

[Myrkie]

if you are it might be possible to force which adapter it runs on using sharpDX ive used the same fix with VRCX's VR overlay though im not sure if that fix can apply to your use case. https://github.com/vrcx-team/VRCX/commit/e24103ec30ea2deda1e3780d1976622b17166d95

[Xiexe]

All the rendering happens through vuplex which is just a Unity wrapper and renderer for chromium.

That's likely where the issue is.

[Myrkie]

ahh I see it could be a mix of both, can see that unity part is working fine though considering the displays do show up.

[Xiexe]

It's 100% an issue with the chromium instance running on the wrong display adapter. Vuplex allows you to set launch parameters for that instance, but chromium seems to have about ... 50 million launch parameters to dig through.

[Myrkie]

yeah, kinda hard to find something when you don't exactly know what your looking for.

[Xiexe]

I've passed the log to the creator of Vuplex who I was already in touch with. I'll keep you up to date.

[Myrkie]

thanks ill be waiting till then.

[Xiexe]

Hey!

I've heard back from the vuplex dev, and they'd like to take a look at your chromium logs after the crash happens.

You can get the log here: \steamapps\common\XSOverlay_Beta\XSOverlay_Data\Plugins\x86_64\VuplexWebViewChromium\chromiumlog.txt

[Myrkie]

hi sorry for the late response, the file chromiumlog.txt doesn't exist but log-chromium.txt and log-chromium.txt~ does. that's one hell of an error code log-chromium.txt log-chromium.txt~

[Xiexe]

Thanks! I'll forward these to him!

Sorry, I had typoed the name. These are the correct logs.

[Myrkie]

all good if you need anymore logs or steps let me know.

[binarynate]

Hi, @Myrkie 👋🏻. This is Nate, the founder of Vuplex. I'm sorry for the inconvenience and for my delayed response. I've been traveling for the past several days but am back now and am getting caught up on support. The logs you provided are helpful, and they seem to indicate that the approach that 3D WebView uses to make the Chromium process use the same GPU as the Unity process is failing for some reason in this scenario. Can you please do me a favor and check if it works if you specify the GPU using the approach described here? That's the approach I used while developing the GPU matching functionality. Coincidentally, my Windows machine with multiple graphics cards suddenly stopped booting at the beginning of last week, but I am working to bring it back up so that I can test with it.

[Myrkie]

Hi which application would I set as using the GPU, would I be specifying XSOverlay? or should I do that for Vuplex WebView.exe

[binarynate]

Yes, I mean XSOverlay.

[Myrkie]

alright i go do that and see if anything changes.

[Myrkie]

Hi I just tested, and the results actually get worse instead of the Vuplex webview not rendering nothing renders, not even the windows as they would when using -force-device-index 1 through my experiences the approach provided above only works on windows 11 as Microsoft has added a feature to force a preferred GPU, with windows 10 this option was dropped in a preview build as currently setting graphics preference just gives me a "power saving" and "high power GPU" option with my first GPU being the only option

here are the relevant logs from XS and Vuplex

output_log_2023-03-01__22.42.43.txt

log-chromium.txt log-chromium.txt~

[Myrkie]

On second thought it hasn't gotten worse its just merely the same except this time XS is not loading my previous configuration so the windows that did function don't load automatically

[binarynate]

Thank you for your feedback! I'll work on getting my dual-GPU test environment back up, and I'll send you an update within the next week.

[Myrkie]

Thanks for the report back, if you need me to test anything else just tell me.

[Xiexe]

Any updates on this?

[Myrkie]

Any updates on this?

as far as im aware this is still not fixed and is still an underlying issue with Vuplex ill test it in a few minutes to see if anything has changed.

[Myrkie]

hi, just tested can still confirm that -force-device-index 1 only forces the unity application still and thus UI rendering doesn't work while window rendering does work if I happen to have an auto load layout.

[Xiexe]

Any updates on this?

as far as im aware this is still not fixed and is still an underlying issue with Vuplex ill test it in a few minutes to see if anything has changed.

Sorry, i should have specified that this was a question for the Vuplex dev, lol.

I haven't heard anything back in awhile or seen any activity here, so wanted to bump it.

I likely can't hold a release back any longer for this as people are wanting updates.

[Myrkie]

I likely can't hold a release back any longer for this as people are wanting updates.

in this case ill just keep an old build until this has been fixed inside vuplex

[binarynate]

I'm very sorry for not getting back to you, @Xiexe and @Myrkie . I initially worked on this issue, but then I lost track of it in my issue tracker and it slipped through the cracks. I was unable to set up a development environment with multiple graphics cards like I expected, but I recently updated 3D WebView's code to fix some issues with how it handles multiple graphics cards and to handle more logging. So, I suspect that will resolve the issue or at least provide more log messages hinting at the issue. I'm getting ready to publish the updates as part of a new v4.4.1 release. I'll post an update here soon (hopefully when the next few days) when I publish v4.4.1 so that you can upgrade to the new version, @Myrkie .

[Myrkie]

ill wait for xiexe to provide a new build with the updated vuplex and then provide any logs that are created if the issue persists.

[Myrkie]

can confirm this is still an issue with the latest release, making XSOverlay completely unusable and unable to downgrade as the branch is now gone. here is the associated log with how it looks in video.

https://github.com/Xiexe/XSOverlay-Issue-Tracker/assets/20288698/196506d0-6d74-4a97-8b13-93dfc5b49667

output_log.txt

[Xiexe]

This doesn't seem like a Vuplex issue anymore, looking into it.

[Myrkie]

im currently running on main gpu until you got a test build then i can swap over when im next free.

[Xiexe]

The output log attached is from build 286 - the current build is 627. Could you provide an up-to-date log?