VRChat is a social VR application that is fun to be in. I DJ in that application for others and have come across a problem GPU drivers later than 22.5.1. It is a known problem with VRChat and AMD. Users that try to use UDON based media players crash to the steamvr virtual desktop and there is no work around other than avoiding any worlds with media players. Is anyone taking a look at this? The problem does not occur in desktop mode interestingly enough. Only in VR does the crash occur. As soon as a twitch stream link is entered in the media player I get exited from the application with an AMD Error pop up stating the drivers had stalled and had to be restarted.
Same. Affects 6800XT too. Pretty sad that a 4 month old driver is the only solution. This type of thing is why my next GPU will be Nvidia. I still remember when this card came out it took AMD almost half an entire year to release a driver that didn't immediately crash Substance Painter. Taking too many Ls being stuck with AMD drivers.
NVIDIA does run into occasional glitches as well so Ill keep sticking with AMD but I am disappointed that there is no support or acknowledgement of issues. Is there a better forum to report issues?
I just recently built an entirely new PC with a 6900XT and I crash in almost every world that has a media player in it within mere seconds of loading in. If I can stop the media player in time before the crash I might survive.
For me the symptoms of the crash are as follows:
I then have to open the Steam VR environment and close VRChat. I can then start VRChat again, hopefully not having set my home world to a location which has such a media player, otherwise I'll crash again within seconds. I can reliably crash if I visit the same world instance again.
This does not happen with all worlds that have a media/video player, but it is a severe issue on most.
In my opinion it should not happen that the AMD drivers crash/hang.
Seems to still be crashing on Adrenalin 22.10.2
If this isn't fixed when the 7xxx cards come out, RDNA3 early adopters who play VRChat are going to be disappointed. They won't be able to use the May driver to fix this and will be stuck with a broken VRChat experience until AMD gets around to acknowledging the problem and fixing it. It took AMD half a year to do that with the Substance Painter bug so I don't have a lot of hope.
In the meantime, if you need a world that doesn't crash you, Midnight Rooftop/Spooktop runs fine. Might be an issue with worlds that have an older version of the video/stream player perhaps?
The VRC team claims that AMD has acknowledged the issue. Is there any confirmation that it is actually a driver issue and not their newest update messing with it?
Before the security update any drivers worked fine by the confirmation of many including myself.
It's been quite a few drivers iterations since and yet there is no sign of AMD confirming the issue.
I'm running on a 6950 XT with a 5900X on 32GB.
Its an issue with some middleware, namely AVPro Video which handles the video playback. Apparently ChilloutVR has the same issue since they use the same middleware. At the same time VRChat released their controversial EAC update they silently did some other updates in the background which included updating AVPro.
Renderheads, the developer behind AVPro Video, is aware of the issue and is in contact with VRChat. Problem is they can't reproduce it as they don't have any Radeon cards to test. Here's the link to their github report on the matter. https://github.com/RenderHeads/UnityPlugin-AVProVideo/issues/1290
It's crazy that I even have to use 22.5.1 to even be in my homeworld that had an udon player. What's crazy is that it was working just fine and then over the weekend all the sudden I come back and get instant crashing. AMD cards are great, but man do they suck in VR.
Honestly that sounds like a cope
If it's a driver crash, it's an AMD issue at the end of the day. Especially so if it worked on an older driver and doesn't crash competitors' drivers. Maybe VRChat will ultimately be able to change something to work around a bug in AMD's driver, but it doesn't change the fact that this is caused by AMD's notoriously poor drivers. An application should not be able to trigger a driver crash.