Next Generation Hardware Speculation with a Technical Spin [pre E3 2019]
- Thread starter AlNom
- Start date
-
- Tags
- 5 bytes non sequitur
- Status
https://www.guru3d.com/articles_pages/msi_geforce_rtx_2070_gaming_z_review,12.html
Guru3d is pretty reputable.
DavidGraham
Veteran
TPU retested all cards with new games and drivers this month in preparation for Navi.
https://www.techpowerup.com/reviews/TechPowerUp/GPU_Review_System_Update_May_2019/2.html
And so did ComputerBase.
https://www.computerbase.de/2019-05...bschnitt_grafikkartenbenchmarks_in_2560__1440
Very difficult to fit 300W into a reasonable console BOM, or physical size, or noise figures. There is an exponential cost when going significantly above 200W. It's about the SoC power density starting to require expensive stuff.
This seems to confirm sony asked for some modifications to the silicon for this, otherwise this would be a simple pcie4 plus software. Or an external ssd controller, or on their southbridge, all of which wouldn't require any involvement from AMD.
Optimizations which sony asked to help ray tracing, and most definitely no dedicated RT silicon?
They seems to imply the new arch is flexible enough not to need separate compute units for RT workload.
Optimizations can be anything at this point. Sony/AMD could have retooled a certain amount of CUs (8, 10, 12, etc.) to handle RT functionality only. Got rid of any logic fat that would have dragged RT performance down, and added any logic more purposeful or suitable for RT. So in many ways its still bespoke dedicated RT silicon.
Last edited:
I'm overthinking it but the choice of words is interesting when amd talks about their clients, hinting at the scope of the alterations:
1. Optimizations
2. Customizations
3. Proprietary technology
There's tweaks for backwards compatibility with the PS4 as well. A decent chunk of the ISA for GFX10 has moved to line up with the PS4's generation, but there are gaps.
Then there's whatever tweaks were made to the PS4's architecture. Some seem to have made their way into APUs, like the Onion+ bus. That might have been superseded by the latest fabric, though there may still need to be tweaks if there's some quirk to Sony's implementation.
The number of ACEs is different, though the virtualized queue model with HWS might emulate it. There's the dual graphics command processor setup that is present in some form for all modern consoles. AMD might need to add that again or have a front end capable of performing whatever functions that used to be handled by them.
One potentially significant tweak was the PS4's volatile cache flag, which allowed cache writeback to proceed more quickly for compute shaders. Whether that would persist, or if there's enough performance in a new cache hierarchy to replace it is not known.
One random item for backwards compatibility is a bug that was revealed with the PS4 jailbreak, where the DMA engine's command queue is read with a presumably buggy offset. If the PS4 has low-level code sent as-is to that queue, it wouldn't work without the bug being emulated in future hardware.
Then there's whatever tweaks were made to the PS4's architecture. Some seem to have made their way into APUs, like the Onion+ bus. That might have been superseded by the latest fabric, though there may still need to be tweaks if there's some quirk to Sony's implementation.
The number of ACEs is different, though the virtualized queue model with HWS might emulate it. There's the dual graphics command processor setup that is present in some form for all modern consoles. AMD might need to add that again or have a front end capable of performing whatever functions that used to be handled by them.
One potentially significant tweak was the PS4's volatile cache flag, which allowed cache writeback to proceed more quickly for compute shaders. Whether that would persist, or if there's enough performance in a new cache hierarchy to replace it is not known.
One random item for backwards compatibility is a bug that was revealed with the PS4 jailbreak, where the DMA engine's command queue is read with a presumably buggy offset. If the PS4 has low-level code sent as-is to that queue, it wouldn't work without the bug being emulated in future hardware.
AMD heads have used these words interchangeable whenever it suits their needs. IIRC, Lisa Su just a few weeks ago talked about providing custom hardware for Sony's "secret sauce" (God I hate that word). And if there is any secret sauce, it usually references proprietary technology.
I found a couple things she said to be interesting although I can't remember where I read it now, was follow up questions after the keynote.
With navi, it's always wait until next show for details. Think E3 is the real deal this time though.
- Navi was in development prior to Sonys collaboration.
- From what I remember sounded like she said RT was always on the roadmap
- Flexable design to allow the semi custom updates, meaning RT can be tweaked per requirements is how I took the answer
With navi, it's always wait until next show for details. Think E3 is the real deal this time though.
This is something I've raised when talking about customisation. There could be a lot of work to support PS4 BC.
Even if it was straight GCN if some instructions where removed or behaved differently, it could potentially needed more work than people assume. Their software stack isn't as abstracted as Xbox.
In an interview at E3 last year Phil Spencer specifically mentioned ray tracing when talking about future things they were working on with their platform team.
Surprised i haven't seen much discussion about that since that is the kind of nugget that usually get forums and blogs talking.
Yea, the trouble is no one knows what it actually means when that is said, much like PS5 hardware RT.
We don't actually know what it actually entails.
Him saying that just shows that they at least had it in mind.
not too much to say unless we know how it performs while ray tracing.
Support for RT is one thing. Designing the next generation of games around RT is something else.
if we're getting the later, RT performance has to be very good. If we're getting the former, than it will be less impactful overall.
Most, if not all, the patents I have seen dealing with PS4 backwards compatibility deals with CPU instructions/frequencies and docs relating to any potential memory/bandwidth timing issues. For the most part, the GPU should be mostly a plug-and-play situation towards BC, while the CPU and memory configuration would need more prioritization towards compatibility.
Old news
2014:
The Xbox One could one day make use of a powerful rendering technique called "real-time ray-tracing," an advanced system used to achieve photorealistic lighting effects. Microsoft Studios executive Phil Spencer has confirmed that internal tests are already underway.
https://www.gamespot.com/articles/x...ring-system-for-amazing-visuals/1100-6418060/
What leads you to this line of thinking?
Lack of patents?
When navi was being started it was prior to Sony input as confirmed by AMD.
So there could easily be lots of decisions that was made that would make PS4 BC harder to achieve.
Which would mean customizing navi to achieve it, if it was too much work on the software side to guarantee 100% seemless BC.
Don't remember thatOld news
2014:
The Xbox One could one day make use of a powerful rendering technique called "real-time ray-tracing," an advanced system used to achieve photorealistic lighting effects. Microsoft Studios executive Phil Spencer has confirmed that internal tests are already underway.
https://www.gamespot.com/articles/x...ring-system-for-amazing-visuals/1100-6418060/
- Status
Similar threads
- Locked
