I'm having trouble understanding the performance of the City Sample.
My computer (3900X, 32 GB, 3060 with 12 GB), is showing an average of 54% CPU usage (with no cores maxed out), and 68% GPU usage (1080p). RAM not full, and neither VRAM.
How come, with RAM, VRAM, GPU and CPU to spare, I'm getting 22 to 25 fps? What is the botleneck here? RAM Bandwidth(DDR4 3200)?
Ah that's good to know! I was curious how much of that was responsible for the difference in my experience vs. some other random factor. Glad to hear you got it working better in any case!
Well that's another legit advantage of the console UMA architecture - it's not "VRAM vs CPU RAM", you can fluidly use as much for graphics vs. other stuff. I wouldn't be surprised if the Matrix demo in particularly used more than 8GB for GPU resources, but I don't know the final breakdowns.
As I mentioned, almost everything in that demo are virtual textures. They only get loaded based on the mips that are required to render the given view. Thus dropping your main output resolution (as I believe they get LOD biased by default with TSR/DLSS/etc to still be sampled at the mips like they were rendered at full resolution) will drop your texture memory footprint. Alternatively I'm sure there's a virtual texture-specific LOD bias and/or pool size.
There's definitely no need to mess with the source assets. Just like Nanite, things only get streamed as they are needed.
might be UE5
How does it help developers when it isnt fully optimized for PC hardware?
In the editor or a compiled build?I'm having trouble understanding the performance of the City Sample.
My computer (3900X, 32 GB, 3060 with 12 GB), is showing an average of 54% CPU usage (with no cores maxed out), and 68% GPU usage (1080p). RAM not full, and neither VRAM.
How come, with RAM, VRAM, GPU and CPU to spare, I'm getting 22 to 25 fps? What is the botleneck here? RAM Bandwidth(DDR4 3200)?
Task manager is unfortunately quite unreliable for such things because Windows moves threads around between cores all the time. The bottleneck will almost certainly be a single thread somewhere (and thus the CPU's single-threaded performance) - usually the game, render or RHI thread - but you'd have to use a tool that understands user mode threads (like UnrealInsights) to see.Iis showing an average of 54% CPU usage (with no cores maxed out)
I have no idea what that settings does... it's totally possible that it only adjusts classic texture quality and does not affect virtual textures at all. I don't really know the details of how to tweak virtual textures in Unreal. Presumably you could modify the master material with an LOD bias but I'd be surprised if there wasn't a way to tweak the base bias, or the one that TSR applies.when setting sg.TextureQuality=0 (which according to you, adjusts MIP level bias beyond upscaling?)
Agreed. It's almost certainly a cvar somewhere, I'm just not familiar with those systems to point you at it.It's likely the Coalition did reduce texture detail specifically for Series S when optimizing the build for it.
I took an NSight trace and noticed in some passes the top unit throughput is actually PCIe, so I'm wondering if this could also be a bottleneck with the City map on PC, haven't spent too much time looking into this though.
^ without any pedestrians or cars, built with shipping config locally.
The Shaky Cam™ makes all the difference in succesfully fooling the brain.
There's two passes there that last for a grand total of... what... 250us or so that have high PCIe throughput. This is both completely normal (various passes will hit different bottlenecks in a given GPU/SKU), and completely unrelated to 3-order-of-magnitude longer stutters that occur on the CPU, not the GPU.I took an NSight trace and noticed in some passes the top unit throughput is actually PCIe, so I'm wondering if this could also be a bottleneck with the City map on PC, haven't spent too much time looking into this though.