No that's with DLSS on Nvidia so fake 8k. Better explain how the 3090 with its 384 bit bus can be slower against a 256 bit card in some games ( like F1 2020 ) at 8k.Ouch Nvidia more than 100% faster in tomb Raider
-
Competitor rules
Please remember that any mention of competitors, hinting at competitors or offering to provide details of competitors will result in an account suspension. The full rules can be found under the 'Terms and Rules' link in the bottom right corner of your screen. Just don't mention competitors in any way, shape or form and you'll be OK.
RDNA 3 rumours Q3/4 2022
- Thread starter Grim5
- Start date
- Status
More rumours, bunch of leakers are reporting the same thing today:
* Navi 33 is a 80CU monolithic GPU
* Navi 31 is a 2 x 80CU MCM GPU
Performance
* Navi 31 is targeting to be 150% faster than the RX6800 in Rasterization
* Navi 31 is targeting to be 100% faster than the RX6800 in Ray Tracing
Architecture
* RDNA 3 doesn't contain fixed function hardware for DirectML/Super Resolution/DLSS, Super Resolution/Direct ML uses the same pipeline as it does on RDNA 2
* Navi 33 is a 80CU monolithic GPU
* Navi 31 is a 2 x 80CU MCM GPU
Performance
* Navi 31 is targeting to be 150% faster than the RX6800 in Rasterization
* Navi 31 is targeting to be 100% faster than the RX6800 in Ray Tracing
Architecture
* RDNA 3 doesn't contain fixed function hardware for DirectML/Super Resolution/DLSS, Super Resolution/Direct ML uses the same pipeline as it does on RDNA 2
Last edited:
I think the only gauranteed t
Navi 31 is then targeting Ampere's RT performance, while Nvidia move to gen 3 RT cores. Did they just throw down another white flag?
Navi 31 is then targeting Ampere's RT performance, while Nvidia move to gen 3 RT cores. Did they just throw down another white flag?
Well there are no rumours from Nvidia's side, they're either better at hiding info or they are behind AMD in the design process. We don't yet know if Lovelace actually contain a 3rd gen RT core or if its the same core as Ampere - it could just be the same core just with more of them due to higher transistor density.
I would rather be conservative in your hopes than be disappointed later on
I really don't find it likely they are behind AMD in the design process. For all their faults nVidia is a company that keeps pushing forward.
They aren't yet like Intel which keeps lumbering along like a headless beast.
Caporegime
That's a 150Mhz higher than mine though, and yours is a 6800 XT so worse silicon.
Soldato
TSMC have already reported that Apple have the entire production for 5nm - ergo, why does WCCFTech believe RDNA3 will be on 5nm this year or next? it`ll be on 7nm
Soldato
Time will tell. RT cores at the end of the day are just striped down cuda cores and if their not processing rays there redundant. They also have to share the same cache pool which hinders their efficiency. At the end of the day Ampere is mammoth chip (thanks to all the extra fixed function hardware). Nvidia wouldn't have been able to get away with a chip that big at TSMC 7nm without sacrificing margins or increasing prices further.
At the end of the day ray tracing is a rendering technique that's only available for a handful of ultra high end PC gamers. Until ray tracing can be run on mid range cards whilst maintaining high frame rates traditional rasterisation is where it's at for most of us.
Associate
- Joined
- 29 Jun 2016
- Posts
- 529
It wouldn't surprise me if AMD were first to market with a MCM GPU design, whether it's RDNA3 is another thing. I figure that was one of the big benefits going to TSMC for their CoWoS (Chip on Wafer on Substrate), which allows super high density interconnects between dies, as required by GPU's. I gather its similar to Intels EMIB, which has higher density interconnectivity than AMD's interposer on Zen 3.
Soldato
Seriously? A new gpu once a year is how things used to be before it got harder to do die shrinks.
Apple are moving on to 3nm towards the end of this year at which point AMD gets a big slice, if not all, 5nm production. TSMC are also rapidly expanding 5nm production as well, it's almost a certainty that RDNA3 will be 5nm, just when is the question as they might favour Zen4 I guess...
Got harder to do die shrinks or nvidia got a huge lead and got greedy
Associate
It’d be good to see an MCM design from AMD where it showed the proof of concept in the first release that had a near par performance but clearly showed scope for up scaling.
A bit like how threadripper early on had the chiplets with clear spaces left for where more cores could be added and then on the next release they got filled and just blew intel out the water with it.
A bit like how threadripper early on had the chiplets with clear spaces left for where more cores could be added and then on the next release they got filled and just blew intel out the water with it.
The advances in interconnect tech is one factor which helps to make many approaches to MCM GPUs possible but there are complications with game rendering you can't easily solve in hardware alone. You definitely can't do it via a Zen like chiplet approach in hardware alone unless you somehow convince developers to all adopt explicit multi-adaptor and rework their old games.
Whilst the approach can't be exactly the same as Zen but looking at the block diagram (who knows what the actual/true layout is...) it seems like RDNA2 consists of a 'Command Processor' block, 4x discrete 'Shader Engines' and of course the Infinity Cache and memory interfaces, which do appear to be split into 4 but hard to tell how directly they tie into Shader Engine.
Given that would it not be feasible for the 'IO Die' (from Zen terminology) to be the 'Command Processor', plus memory interfaces and potentially/probably some level of cache. As that is the one input to the GPU it appears that then distributes work amongst the shader engines which 'just so happen' to now be on seperate dies.
Obviously this increases latency between dies/areas of the GPU (although with Zen they've worked hard to drastically reduce that) but more importately potentially/probably increases latency to VRAM which is likely the bigger problem, but not impossible to overcome...
No idea how this relates to nvidia designs but certainly could see how RDNA2 could morph into a usable MCM setup, not without issues but given their experience through developing Zen those issues don't seem insurmountable.
Soldato
The difference is the day to day operation of a CPU in Realtime is not affected by latency but a GPU running your game is. a MCM design will increase latency with the communication between the Cores and IO die etc Ryzen offsets this somewhat with loads of L2 cache.
We will prob see MCM designs for non gaming based products first like compute etc where the Real time latency is not as big as a issue only the overall operation time to finish a task.
I'm not sure if they can get over the latency issue for a gaming card as well physics.
Isn't the large cache something AMD has already employed on RDNA2 probably as a test run preparing for RDNA3.
Also AMD submitted a patent for an MCM design in which each GPU chiplets can simultaneously communicate with the CPU.
MCM for general compute on GPUs is "easy" using chiplets - but gaming is another matter again and you have all the issues almost no matter the hardware design that plague Crossfire/SLI.
One potential way around it would be to have blocks of "functionality" spread out on the substrate, using command processors, with high-speed interconnects where the compute blocks have rapid repurposability (somewhat like Intel tried but in software with Larrabee) so you can on the fly build multiple virtual GPUs with varying resource level depending on what part of the scene they are dealing with - but you still have problems there if one GPU has resident and/or is in the middle or processing the output that another GPU requires to finish its work, etc.
One potential way around it would be to have blocks of "functionality" spread out on the substrate, using command processors, with high-speed interconnects where the compute blocks have rapid repurposability (somewhat like Intel tried but in software with Larrabee) so you can on the fly build multiple virtual GPUs with varying resource level depending on what part of the scene they are dealing with - but you still have problems there if one GPU has resident and/or is in the middle or processing the output that another GPU requires to finish its work, etc.
- Status