By using this site, you agree to our Privacy Policy and our Terms of Use. Close
Pemalite said:
EpicRandy said:

Meshes deformation are all handled by the CPU, all games logics are, a feature rich title will make extensive use of the CPU and will likely be CPU bottlenecked. that's why it was important For the series S to have the same capacity CPU wise. Mesh are simply not that demanding on memory and memory bandwidth. for instance a single uncompressed full 4k texture channel is literally 48MB in memory, for the same size you can have meshes with 16M+ vertices and up to the same amount of tris (max is same amount -1). On Series S your likely to also work with mesh with less LoD so should even be easier on the CPU.

Not always done on the CPU.
And considering with RDNA you aren't geometry limited like Graphics Core Next, it's not going to be the bottleneck it once was.


In Unity for example, you can make use of the Tessellator on a modern GPU to deform the mesh rather than require a high vertex count at all times.
See here: https://docs.unity3d.com/Manual/SL-SurfaceShaderTessellation.html


But it all comes down to the developer, the more you shift the load onto the GPU, the better.

Yes like TressFx or other similar feature, those are not what you would use for something dynamics and persistent and I'm not concerned at all for the series S on those aspect as they usually are all very scalable. For something dynamics you would not use those because meshes deformed by the GPU are not available for the CPU to perform logics on like collision and to be persisted.

At the end of the day CPU is the barrier for game functionality (which is why the Series S is scaled down in pretty much every aspect except this one) and the GPU is responsible for graphic fidelity. GPU is also the one being hungry in bandwidth and Memory size so scale it down and you can scale both the other accordingly. That's why on pc your graphics cards have their own dedicated faster memory pool.

Last edited by EpicRandy - on 13 March 2023