They'd still have to map it and expose it via their API(s).
Current Generation Hardware Speculation with a Technical Spin [post GDC 2020] [XBSX, PS5]
- Thread starter Proelite
- Start date
- Status
They'd still have to map it and expose it via their API(s).
Yea, there's that as well.
I'm not even sure if that is a hardware component to be honest. So perhaps it's not?
I'm not really sure when I wrote that, it some ways it does sound like an application layer type feature.
Nah, devs can just throw the bytes right into the registry
nvm.. I see.
Thankyou for explaining it on this forum too!
It's what i and some others try to say but you do that so much better.Ofcourse prices will drop, dont think you will need to spend 1600 dollars, but it is going to be more expensive with pc gaming. You could wait a year or something, like late 2021, and things will look much better.
This. I guess it will come to light anyway.....
Gamepass is a very good deal, especially now when MS starts pumping out more aaa games. For both pc and xbox at the same time.
No idea what the XSX is going to cost, but that thing will be unbeatable on price/performance ratio, i'm a pc gamer but thats something ive to admit. A 12TF+ gpu with ray tracing at that level, 3.8ghz 8 core cpu, 1TB insane speed SSD (bcpack 6gb/s), all that in a small form factor thats going to run very quiet. Full BC all the way back to 2001, and PC/xbox cross plat games. As a pc gamer that sounds very tempting to me, i already have a pc powerfull enough that matches the xsx on most fronts aside from the ssd, but for the living room, i want an xsx. With gamepass i get to play on both so why not.
As most know, im a pc gamer but that xsx gets my attention. As a pc gamer you want the most powerfull hardware, and sustained high fps, think that is what MS seems to aim for.
AbsoluteBeginner
Regular
Yea, that makes sense. Introducing "free form" variable frequency instead of GPU/CPU mode would likely introduce further issues next gen with BC.
Oh Alex, you tease.
I mean, just thinking about the physics of it. The clock/power draw can't possibly be symmetrical between GPU and CPU.
GPU by surface area is going to draw significantly more power than the CPU.
So Cerny is probably very correct in revealing that if the CPU needed more power the GPU would lose some clockrate to serve the CPU power needs.
He failed to provide how much clockrate the CPU must lose for the GPU to hit maximum clock rate, because in my mind in the other direction the CPU must lose a lot of power to up the clock rate on the GPU side of things.
The only numbers you guys provided where the maximum clock rates for both the CPU and GPU.
Which truthful but not the full story.
The numbers provided should have been CPU is X then GPU is 2230 Mhz. Or CPU is 3500 Mhz GPU is Y.
Thinking out loud, there's no way that MS could have adopted this technology. 52 CUs should flat out kill the power allotment for the CPU.
D
Deleted member 13524
Guest
FTFY
33% is a fairly significant pricecut. And Zen 3 and Ampere will be out for holiday 2020. Wether XSX or PS5 or new pc components will be widely available on the shelves everywhere for holiday 2020 is another story. Hence i included 2021to be fair
Why is that you think?
It doesnt matter 9 to/or 10TF, you wont feel it when you actually play the games
Silent_Buddha
Legend
However
If PS5 == RDNA 1.9 then:
???
Sorry, I couldn't resist. I'd be surprised if it wasn't there as both SOCs likely started with stock RDNA 2 as a base.
Regards,
SB
How does PS5 SSD achieve 22GB/s speed? It needs 4:1 compression rate. Which algorithm will be used?
Love_In_Rio
Veteran
Anybody knows what are cache scrubbers for?. SSD data will go directly to gpu caches?. If so are they only useful for getting ssd data?.
Variable frequency is a great approach. Some people think Sony just want to have higher spec on paper so they choose extremely
high clock which will be be varied in real games.
But the idea of variable frequency is to fully utilize the capability of the cooling system. Just think Xsx, if a cross-gen game only
uses 50% of CPU, why not give more power to GPU to raise to 12.6TF or even 13TF if the cooler can hold ?
They use Kraken (better than Zlib which is also available). Usually the compression will be about 2:1 or so. But depending of the data compressed, it can go up to 4:1. It can uncompress that much (and reach 22GB/s) because of the dedicated hardware. Cerny said that 9 Zen 2 cores would have being needed to unpack the same data using that compression.
Interestingly those numbers were already in the SSD patent which was talking about a typical 10GB/s up to 20GB/s in some conditions.
Only some types of data would. Others would be like 1.01:1. In practice it's like any compression where some files compress by a large factor, and others stay almost the same size. They did say it's 10% better than LZ though (the hardware compression in ps4 and xb1)
The interesting part is that the uncompressed data would be structured for immediate use by the GPU, so things like masks, maps, alphas, would compress like crazy, while most albedo would be a low ratio I suppose.
I don't fully understand the coherency module and cache scrubbers, I assume it's another RDNA2 thing...
But why have that if you can have a sustained level of performance at say 2% lower gpu clocks?
What about games that will tax both to the max? Late gen games could actually do that.
Yes, but that drop took 3 months to happen. Zen 3 is by the looks of it going to be released relatively later than Zen 2 was released, so maybe end of Q3 starting sales immediately. If 3700X follows same pattern as 2700X, it would still be only 10% down from it's current price when the consoles hit the market.
Those values are set when the game is detected to be Woflenstein II or Doom, and only if the GPU is RDNA or later.
These are choices made by driver developers with regards to bug workarounds or performance tweaks for popular-enough games.
The point of Mesh shaders is to give game developers control over the input format and topology of their primitives. The driver changes appear to adjust what the internal compiler will do for chunking the standard stream of triangles, which it must be since the game developers wrote their shaders within the context of the standard pipeline.
It looks to me like there are at least two significant distinctions to be made, who is making these decisions, and where and how the shader is sourcing its inputs.
The values in this case only apply to RDNA, which may be another bit of evidence that there have been significant elements of the original concept for primitive shaders that have been changed or dropped.
It's not clear what the motivations are for these titles, though it could be to resolve performance regressions, per-GPU issues, instability, or to allow API-illegal behavior going by the comments of nearby code entries.
Microsoft's position is that it intends to reinvent the front end of the pipeline:
https://devblogs.microsoft.com/dire...on-shaders-reinventing-the-geometry-pipeline/
Primitive shaders slot into a place within the existing pipeline. Changing that makes the link to AMD's original concept more tenuous.
For the hardware tessellator stage, the stated intent is to replace it.
https://microsoft.github.io/DirectX-Specs/d3d/MeshShader.html
There's some theorizing that it's not strictly bandwidth, but also the memory transaction rate that the RT hardware can achieve. Since traversing the BVH means analyzing nodes and then following pointers to successive entries, there's more round-trip traffic rather than raw read bandwidth. Some of the research for ray tracing involves finding ways of gathering rays that hit the same nodes of the tree, which along with saving bandwidth saves on the number of round trips the hardware may need to make.
Depending on how well the BVH hardware caches data, or how often BVH data can be accessed again while still in a cache, there can be a benefit to higher clock speeds. Cerny did note that the primary downside is that memory is effectively further away in terms of latency, which means more divergent rays or less effective cache situations would make trips to memory or contention for memory more expensive for higher-clocked units.
This may be possible if they avoid significant writes to memory on cache flushes, or if they can avoid some flushes entirely. That may also change how much impact certain synchronization events have, where GPU cache flushes take time and the whole GPU needs to stall while they happen.
What's not clear yet is how much time this saves, or if it can avoid some of those events entirely.
An improvement there can help reduce the number of times where the CUs and fixed function units are idled, or how quickly they can ramp up afterwards due to caches being indiscriminately cleared.
Less clear is whether how much of this is unique to the PS5, or if there are different approaches that can get approximately the same result. Perhaps something like using fallback textures or last-frame data if the game is unsure of possibly state data can be close-enough versus a GPU that spends a lot of effort scrubbing caches.
A BVH is an acceleration structure, so the hopeful idea is that much of it is not being accessed heavily, or that portions are accessed in a bursty manner. It's likely part of the reason why AMD and Nvidia use RT hardware that works with a stack-based traversal method, and it's an argument IMG is making for its ray-tracing coherence engine.
The PS5 presentation mentioned zlib and Kracken compression. The 22 GB/s was given more as a peak value for some very lucky compression case, perhaps a lot of trivial or uniform values. That may point to a corner case in the existing decompression hardware that BCPack does not have. It's possible that if BCPack is more complex, they had other priorities to optimize for than a trivial decompression case that games wouldn't use. It may also point to a different choice in how the blocks are hooked up to the on-die fabric. Perhaps Sony opted to have a wider link or it has more links due to its internal arrangement, and that just happens to work out in some easier decode instances.
There are coherence engines that seem to be monitoring when data loaded from the SSD is placed into memory, and they signal the scrubbers to clear any lines in the GPU caches that might have data in the address ranges that were overwritten.
How often this can happen or what overheads there might be wasn't discussed. It was mentioned only in the context of the storage subsystem, although I wonder if anything else like the CPU or the audio co-processor could do something similar. The CPU-GPU path usually has a different and more direct way to invalidate cache entries, so I'm not sure if that would benefit unless such events can be heavier in terms of synchronization.
AbsoluteBeginner
Regular
But you wont be able to run them all the time at max. I dunno, I would rather they hit 2150MHz and 3.5GHz locked, then variable. Few % up and down, when both will not work at max seems like meh solution...
- Status
Similar threads
- Locked
