I have a Vive and a pretty high-end Alienware Area-51 PC with lots of memory, a good CPU, and a GTX 1080 graphics card.
My VR game was running well under 4.14, never dropping frames. However, when I updated UE4 from 4.14 to 4.17.2, the game’s performance severely dropped from around 6.5ms to around 10ms and above, often dropping frames depending on where I look.
4.14 stat gpu:
4.14 Vive Perf:
4.17 stat gpu:
4.17 Vive Perf:
BTW, is there a way to be able to view the stat gpu labels in 4.17?
My question is how can I go about tracking down why my game runs so terribly under 4.17 as opposed to 4.14?
Hi Steven,
Somewhere around the 4.14 time frame we discovered that for SteamVR, our render targets were smaller than they were supposed to be. When we adjusted them to be correct, it caused a noticeable perf hit to people used to it the other way. I don’t know if this is what you’re seeing (we can’t remember exactly when we fixed it - I perused release notes and didn’t see any mention of it), but it is a possibility.
We use RenderDoc here a lot to diagnose graphics problems like what you’ve seen here. I’d suggest you take a render doc capture of before and after and compare - are the target sizes different?
Unfortunately the stats can be misrepresentative if you’re not hitting framerate. Since we expect the CPU thread to be a single frame behind the render thread, we sometimes hang in the render thread waiting for the CPU. This sometimes will show up as increased time in one of those stats.
Hope this helps!
Thanks for providing those projects. Being able to capture the same content in different engine versions side by side is really helpful! I believe I’ve been able to track down the discrepancy. 4.15 changed the default value for dbuffer decals to true. dbuffer decals force a full depth pre-pass which is where the majority of the frame time difference is going. Since you’re not using that feature, turn it off in the render settings (Engine → Rendering → Lighting → dbuffer decals).
I created two test projects using the VR template, one with the 4.14.3 stock engine, and the other with the 4.18.0 stock engine, and I got similar results to my game - 4.18 is incredibly slow in VR compared with 4.14. Even the CPU usage increases with 4.18. But the GPU is the main problem. Here are the results:
4.14.3 stat gpu:
4.14.3 vive perf:
4.18.0 stat gpu:
4.18.0 vive perf:
As you can see, the GPU runs around 2ms slower on 4.18 than it does in 4.14. And the CPU runs about 1ms slower. The performance is even worse with our game, likely because our scene is quite a bit more complex than the VR template scene. This is a very big problem for us, and we very much hope you can help get us back to the fast speed the engine used to run at.
You can download the projects here, but honestly there’s nothing to them:
SpeedTest_414:
SpeedTest_418:
FWIW, I just tried the same VR template test using 4.15.3 and it runs just as slowly as 4.18.0 does, so whatever changed to make the engine slower appears to have happened in 4.15.
Steve
Hello,
It’s been over a week, so wanted to check in. We very much need help on this. We cannot go back to 4.14, nor can we live with the unusually large hit in performance that came along with the engine update.
Thanks,
Steve
Can you confirm the screen percentage is the same in both projects by typing r.screenpercentage into the console, press enter, then bring up the console again and see what it’s set to. Ensure both are equal.
I took a look at your test projects. The 4.18 project enables the z pre pass where the 4.14 project does not. With the pre pass on for both projects, at the same screen percentage, the timing I’m seeing in the valve performance monitor is essentially identical. Actually 4.18 was slightly better.
Can you provide a development build of your project that demonstrates the performance discrepancy? Most likely this is either a screen percentage change or default feature quality change that would be easier to track down with A/B comparisons locally.
HZB is used for three features: HZB occlusion, ssao and ssr. If any of these features are on, the HZB will be built. You probably don’t want hzb occlusion. It’s best for scenes with a large number of objects to reduce occlusion query cost. The HZB is used for tracing screen space effects as well. Try disabling all three features. You can quickly toggle ssao with ‘show screenspaceao’ and ssr with ‘show screenspacereflections’. With all three features disabled, the hzb should no longer be generated.
I went ahead an marked this thread as private. Can you provide a project that shows this regression? You can also email me a link directly if that’s better: ryan.vance@epicgames.com I’ll try track down the discrepancy.
More info…
We’ve updated our game to 4.18 and it still runs much slower than 4.14, as we suspected it would. Here’s some info on the performance data we captured.
4.14 stat gpu:
4.14 vive perf:
4.18 stat gpu:
4.18 vive perf:
As you can see, 4.18 is much slower than 4.14, taking 45% longer to render the same scene. To get 4.18 to render as fast as 4.14, I need to lower r.ScreenPercentage from 110 to 70. Of course, that looks terrible and isn’t a viable solution.
Looking at the gpu stats, here’s a comparison of the same scene in 4.14 vs. 4.18:
Some of the costs decrease from 4.14 to 4.18, but HZB takes over 13 times longer on 4.18. Slate UI has also increased from 0.07 to 0.41, which is odd since we’re not using Slate in this portion of the game (perhaps “stat gpu” uses Slate?). But HZB is the big difference.
I tried r.HZBOcclusion 0, but that made no difference.
r.SSR.quality 0 gained us 1ms, which is nice. However, it also gains us 1ms in 4.14 which is even nicer.
And even more info…
I also decided to compare the same scene in 4.14 vs. 4.18 without VR. Here are the results:
Non-VR 4.14 stat gpu:
Non-VR 4.18 stat gpu:
So even without VR, 4.18 still renders this scene slower than 4.14, taking 28% longer than 4.14. Doubling a portion of that render time (one for each eye), could account for the 45% longer render time in VR that I’m experiencing, but just guessing at that.
Hi Steven,
Did you take a render doc capture like I suggested, and compare render target sizes? Like I mentioned, 4.15 may be the change where we corrected the SteamVR target sizes. If that’s not it, a render doc capture could better illuminate the issue than a stats dump will.
Hi Ryan,
I will triple check, but screen percentage is 110 in both projects. I had to lower screen percentage to 70 in 4.18 in order to see the same performance as 4.14 with screen percentage at 110 (see my comments above for more info).
I did see that HZB is consuming a lot of time in 4.18 (see my comments above for details). Is that the same as z pre pass? How can I disable that in 4.18? From my comments above: “I tried r.HZBOcclusion 0, but that made no difference. r.SSR.quality 0 gained us 1ms, which is nice. However, it also gains us 1ms in 4.14”.
I can provide development builds of the game in both 4.14 and 4.18. Would you please mark this thread as private so that I can provide the links to you privately?
Thanks for your help.
Steve
I’m also interested in this ,we’ve noticed this in our VR casino too
Ryan,
When I turn off all 3 of those things, the 4.18 version drops from 9ms to 7.75ms. However, the 4.14 version drops from 7.25ms to 6ms for the same scene.
Looking around with the headset in the same scene, 4.18 gets up to a maximum of 9ms with those 3 settings disabled. However, 4.14 gets up to a maximum of 7ms with those same 3 settings disabled.
Also, I checked r.screenpercentage on both versions, and they both reported 110.
Steve
Ryan, I emailed you the links and additional info. If you’d like, you can make this thread public again in case it helps others. Many thanks for your help.
Hey Ryan,
Thanks so much for tracking this down!
The scene I tested was running at 7.25ms in 4.18, and dropped to 5.6ms when I disabled dbuffer decals, which is fantastic.
One odd thing is that when I enable dbuffer decals in 4.14, the scene runs faster than when dbuffer decals are disabled (5.5ms enabled vs. 6ms disabled). I’m not going to worry about that, though. Our project is running at the speed it used to, so we’re good.
Suggesting that dbuffer decals be disabled for VR would probably be a helpful thing to add to the UE4 VR setup documentation.
Thanks again!
Steve
