Current Generation Hardware Speculation with a Technical Spin [post GDC 2020] [XBSX, PS5]

Status
Not open for further replies.
His point is largely that to increase the variety of content developers will have to rely on procedural generation vs storing pre-made assets on the ssd.

It was a point made to downplay the SSD speed difference.
I'm sure if it was laid out in a less flamey way it would get better. But...
 
He talked about AVX instructions as an workload example.

What other examples of a workloads that will draw comparable amounts of power from CPU you have in mind?

I didn't realize int was used so much in graphics. I would have assumed it would be much more highly skewed to fp. Do you have any links or reading on where they're using it?

It's all in Turing whitepaper. https://www.nvidia.com/content/dam/...ure/NVIDIA-Turing-Architecture-Whitepaper.pdf
Page 13, figure 5
 
It was a point made to downplay the SSD speed difference.
I'm sure if it was laid out in a less flamey way it would get better. But...

There is nothing "flamey" about what he wrote. The wccftech headline is complete bullshit. I happen to think he's probably wrong and the procedural work will be handled up front and put onto ssd. I think the reason it was done in memory was because of the hdd performance. With a fast ssd they can probably make big gains up front and save a good chunk of the computing power. It's a good topic for discussion.

Edit: I do think there's a larger industry discussion to be had about the cost of games. Gamers are expecting a lot, but without having the cost of games go up, I'm not sure how many development studios are actually financially equipped to handle it. How many flops can Ubisoft handle if the cost of game dev goes 25% or 50% to meet consumer expectations for this new hardware.
 
Last edited:
No. It does not.
Turing has full speed parallel integer pipeline. That's used at on average 36% with the FP pipeline.
You could look at it as if Turing cards have +36% to their FLOPS (in real games, on paper they have 2x flops, because of that pipeline).
Yes I know, I was just superficially comparing the TF numbers, but my point still stands that other parameters come into the picture besides the pure TF number. There is the memory bandwidth like I mentioned, the fact Turing TF are higher than Navi (owing to the concurrent INT/FP execution, and better geometry units ..etc), also separate Tensor units if that ever took off on consoles.

I didn't realize int was used so much in graphics. I would have assumed it would be much more highly skewed to fp. Do you have any links or reading on where they're using it?
NVIDIA did state that INT/FP execution allows them to harness 30% more performance as game codes contain 3 INT instructions every 10 instructions.

Figure 5 shows that the mix of integer pipe versus floating point instructions varies, but across several modern applications, we typically see about 36 additional integer pipe instructions for every 100 floating point instructions. Moving these instructions to a separate pipe translates to an effective 36% additional throughput possible for floating point.
https://devblogs.nvidia.com/nvidia-turing-architecture-in-depth/

image5.jpg




NVIDIA also attributes superior RT performance to that capability alongside their RT cores.

geforce-rtx-gtx-dxr-metro-exodus-rtx-rt-core-dlss-frame-expanded-850px.png


The Turing architecture introduced INT32 Cores that operate simultaneously alongside FP32 Cores, helping reduce frame time.
https://www.nvidia.com/en-us/geforce/news/geforce-gtx-dxr-ray-tracing-available-now/
 
I happen to think he's probably wrong and the procedural work will be handled up front and put onto ssd.

+1 here.

I think the reason it was done in memory was because of the hdd performance.

It was rarely done in memory. Only for the most random stuff.
For example all the HZD GPU generated foliage was baked into the actual level at the build time, AFAIK.
It obviously baked much less stuff than the final objects on screen had though. So essentially it's just another way of "compressing" assets.
 
There is nothing "flamey" about what he wrote. The wccftech headline is complete bullshit. I happen to think he's probably wrong and the procedural work will be handled up front and put onto ssd. I think the reason it was done in memory was because of the hdd performance. With a fast ssd they can probably make big gains up front and save a good chunk of the computing power. It's a good topic for discussion.

Edit: I do think there's a larger industry discussion to be had about the cost of games. Gamers are expecting a lot, but without having the cost of games go up, I'm not sure how many development studios are actually financially equipped to handle it. How many flops can Ubisoft handle if the cost of game dev goes 25% or 50% to meet consumer expectations for this new hardware.
THank you for understanding what I meant. And thank you for reasonably disagreeing with me :)

And by procedural, I do not necessarily mean No Man Sky generated environments. I mean things like non bespoke textures for each and every object. So lower res base materials and swappable colours and a decal, trim system, and tilable detail textures to flesh out details. Or stampable decals to insert variation like idtech 7 now does - or assets with instanced bases and then mutable variations. Anything which reuses art instead of baking out 4K textures for each individual asset and drawing from the disk. Or even worse, something like megatexture.

There is a large production difference for time (and even detail advantages) by using sharable materials and texture sets, instead of completely bespoke textures for each object.

As I see it, an open world game design would not want to have many of its assets made to be 100% unique and therefore require lots of disk and ram space, when reused and shared materials with a proper decal system or wear system ontop would cut down required RAM amounts, disk space, AND production time.
 
Last edited:
When the vast majority of the PC install base supports AVX we should see broader support. Right now even requiring SSE leads to support issues.
 
If they could have 100% GPU and CPU all the time, there would not be a reason for boost clocks (or what they call it now, variable, smartshift etc). In special if they had trouble locking 2ghz for gpu and 3ghz for cpu at a fixed rate. This variable clocking enabled huge boosts for a reason.
There are a lot of assumptions here. You are assuming that they(Sony) had "trouble locking" the frequency when in reality what Mark Cerny said they had trouble with was none other than fan noise and by extension inconsistent power draw. This solution was done to fix those problems, not to "reach" a frequency number. That is unless you have intimate knowledge of their internal thought process. Variable clock/Continuous boost was enabled for a reason, true. But the reason was to keep fan noise down.
 
There are a lot of assumptions here. You are assuming that they(Sony) had "trouble locking" the frequency when in reality what Mark Cerny said they had trouble with was none other than fan noise and by extension inconsistent power draw. This solution was done to fix those problems, not to "reach" a frequency number. That is unless you have intimate knowledge of their internal thought process. Variable clock/Continuous boost was enabled for a reason, true. But the reason was to keep fan noise down.

And it is a good reason because my PS4 Pro is too loud.
 
Status
Not open for further replies.
Back
Top