[Rumor, Tweaktown] AMD to launch next-gen Navi graphics cards at E3

[Ajay]

Possible if NAVI has no RT cores/hardware and AMD makes some serious efficiency improvements over Vega.

AMD will get an efficiency bump from the shift to N7 and hopefully some tweaks to GCN. Last roadmap I saw showed Navi being geared towards a performance increase and ‘ Next-Gen' being geared for 'efficiency' (significant architectural changes).

I’m assuming most of the performance improvement for Navi will come from a frequency bump and ,hopefully, at least a small increase in the number of CUs. I wish RTG had the resources to put out two Navi dies this year so they could better compete with NV - but I’ve seen no credible rumor to this effect. Maybe RTG will be able to introduce a scaled up Nave design in 2020 to fo along with the next-gen Instinct design due that year.

 

[Stuka87]

AMD will get an efficiency bump from the shift to N7 and hopefully some tweaks to GCN. Last roadmap I saw showed Navi being geared towards a performance increase and ‘ Next-Gen' being geared for 'efficiency' (significant architectural changes).

I’m assuming most of the performance improvement for Navi will come from a frequency bump and ,hopefully, at least a small increase in the number of CUs. I wish RTG had the resources to put out two Navi dies this year so they could better compete with NV - but I’ve seen no credible rumor to this effect. Maybe RTG will be able to introduce a scaled up Nave design in 2020 to fo along with the next-gen Instinct design due that year.

Pretty sure Lisa Su has already stated that this will be a full product line. I think we should fully expect two GPU's. One to replace Polaris, and one to replace Vega (On the gaming side, not Vega for compute heavy usages).

 

[AtenRa]

Games are becoming more and more compute heavy, RayTracing will increase the GPU compute needs the coming years. I see NAVI increasing the compute performance vs Polaris and not the other way.
You can also see this with NVIDIA, each generation is becoming more compute heavy than the one before.

Also, AMD needs to address the Entry and Middle-end professional GPU market with NAVI, like they did with Polaris. In my opinion NAVI will continue where Polaris ended. It will have some architectural enhancements over Polaris + what they can get from 7nm (increase clocks + higher efficiency). But this time they will have an advantage over NV due to 7nm vs 12nm.

 

[Yotsugi]

I see NAVI increasing the compute performance vs Polaris and not the other way

If you mean throwing more ALUs at the problem, then no.

You can also see this with NVIDIA, each generation is becoming more compute heavy than the one before.

They're making a very much better SM, yes, but better SM is a net gain in overall performance.

In my opinion NAVI will continue where Polaris ended

It replaces literally everything client, the older stuff remains for DC/OEM/embedded purposes only.

 

[AtenRa]

If you mean throwing more ALUs at the problem, then no.

I mean higher compute per mm2 (FP64, FP32, FP16, INT8, INT4 etc).

But, they could also use more ALUs as well due to the 7nm higher density over 14/12nm process.

 

[Yotsugi]

I mean higher compute per mm2

Most definite no, not with already nuclear heat density on V20.

But, they could also use more ALUs as well due to the 7nm higher density over 14/12nm process.

No.

 

[darkswordsman17]

AMD will get an efficiency bump from the shift to N7 and hopefully some tweaks to GCN. Last roadmap I saw showed Navi being geared towards a performance increase and ‘ Next-Gen' being geared for 'efficiency' (significant architectural changes).

I’m assuming most of the performance improvement for Navi will come from a frequency bump and ,hopefully, at least a small increase in the number of CUs. I wish RTG had the resources to put out two Navi dies this year so they could better compete with NV - but I’ve seen no credible rumor to this effect. Maybe RTG will be able to introduce a scaled up Nave design in 2020 to fo along with the next-gen Instinct design due that year.

Just did a quick Google for AMD GPU roadmap, and I think the most recent ones have been simple slides with Vega, Navi, and Next-Gen and it says increased performance and continuous performance per watt gains one the one (which applies to each one, but I could see how you might confuse it as Performance under Navi and perf/watt is under Next-Gen). The most recent one I don't think says anything other than it has the timeline of 2017 and 2020, with Vega 14nm, Vega 7nm, Navi, and Next-Gen listed. Gone are the more specific stuff ("HBM, next gen memory, mGPU, etc" that AMD had listed on their GPU slides before).

I think it'll be a variety of factors. I personally don't expect Navi to clock much higher than Vega 20, especially considering its was designed with the PS5 in mind. I think there will be a variety of factors that will make it perform better (in perf/W and perf/transistor) in graphics rendering than Vega. Software being one (where I think we'll finally see the fruits of the Next Gen Geometry engine that didn't get working fully on Vega; which I think that will come from a mixture of software and hardware improvements), and optimized hardware layout (mainly ratios of things like ROPs, texture units, shaders, etc, so that it leads to better software utilization).

Pretty sure Lisa Su has already stated that this will be a full product line. I think we should fully expect two GPU's. One to replace Polaris, and one to replace Vega (On the gaming side, not Vega for compute heavy usages).

If I remember, the way she was talking was just that they'd release a full product stack in 2019, which they already released Radeon VII in the high end/enthusiast market. Everything else that I've seen indicates Navi is aimed at the lower market (although if its performance is where its supposedly at, I have a hunch pricing will be higher than the $250 the rumors have said).

Games are becoming more and more compute heavy, RayTracing will increase the GPU compute needs the coming years. I see NAVI increasing the compute performance vs Polaris and not the other way.
You can also see this with NVIDIA, each generation is becoming more compute heavy than the one before.

Also, AMD needs to address the Entry and Middle-end professional GPU market with NAVI, like they did with Polaris. In my opinion NAVI will continue where Polaris ended. It will have some architectural enhancements over Polaris + what they can get from 7nm (increase clocks + higher efficiency). But this time they will have an advantage over NV due to 7nm vs 12nm.

Yeah, they can't really remove compute units/capability compared to Polaris as even the consoles use the compute capability (honestly they might use it more than PC dGPU side has been). But I do think the compute tasks that HPC/enterprise do, are different from the compute tasks that games (and other graphics) are doing. There's some overlap, but I think its diverging, and in a way that I'm not sure it makes sense to keep trying to integrate all those compute capabilities in the graphics pipeline. I think what AMD will do is use some of the base units from their GPU designs but remove the graphics only focused bits, and rework the others into a compute design (with the goal being to spin compute off into its own chiplet).

I'm thinking Navi might be every bit as compute heavy as Vega (with it being focused on graphics rendering improvements and carrying over a lot of Vega's compute capability - mostly in the pro market). If they do that, they could probably ditch Navi 20, letting them focus development on Arcturus (which they've said will be out next year). And, if my own personal prediction, that AMD is going to push mGPU with Navi, that would both need extra software development, but also help them not need to do a big update to Navi for the market that I'd expect Navi 20 was targeting. Timing I think also plays in their favor, GDDR6 lets them be able to stay away from expensive HBM, and PCI-e 5 won't be ready and Navi should be able to support PCI-e 4.0 this year (good for mGPU too).

 

[Yotsugi]

especially considering its was designed with the PS5 in mind

It wasn't.

If I remember, the way she was talking was just that they'd release a full product stack in 2019, which they already released Radeon VII in the high end/enthusiast market

Consumer Vega20 has not much time left to live.

I'm thinking Navi might be every bit as compute heavy as Vega

If by that you mean it still has quality SIMDs, then of course.

GDDR6 lets them be able to stay away from expensive HBM

G6 isn't cheap.

(good for mGPU too).

mGPU is dead.

 

[amrnuke]

Agree with Yotsugi, the problem with current AMD lineup at the mid and top tier is TdP and heat, they've just been just throwing more transistors and electrons at an already-hot product to try to hit the high end, but there are hard limits to that currently, and Radeon VII is a perfect example. You could just snag a 2080 for the same price and lower TdP and get 4-7% better performance basically across the board.

Who knows what Navi will bring. Perhaps it will provide solutions ranging up to a top end that will be close to 2070-2080 performance at a moderately lower price point than Radeon VII, to produce a better value proposition in the mid to high end.

 

[Yotsugi]

problem with current AMD lineup at the mid and top tier is TdP and heat

I said heat density, for Vega20 is ~300W in ~331mm^2 die.
That's a lot of heat.

Who knows what Navi will bring

Good value, for the most part.

 

[maddie]

At the same time the design costs at 5 nm are so insane, Navi better deliver or else it's going to be hard to justify continuing with a gaming only design. It'd just be easy to abandon and focus on compute only (and of course Zen and friends).

But the costs for additional designs are a fraction of the initial work. For example, once you do the video output processing unit, you can reuse it for several related designs. Same with (atomic) cache unit, Rops, etc.

Account for most the up front costs to be assigned to the pro compute market and a marginal cost for the gamer segment designs. Accounting allows leeway to calculate & manipulate the total cost of a product.

 

[Ajay]

I mean higher compute per mm2 (FP64, FP32, FP16, INT8, INT4 etc).

Yes, by area, but I don’t expect a change in the FMA 64/32 bit ratio. FP64 just uses too much die area (and active power) for a pure gaming GPU.

 

[Yotsugi]

FP64 just uses too much die area (and active power) for a pure gaming GPU.

It uses whatever for anything GCN.
Proper FP64 cruncher requires e2e SRAM ECC and some other bits, which are indeed a tax.
So they limit it to bare minimum 1/16 everywhere.

 

[AtenRa]

https://www.guru3d.com/news-story/n...cb-photos-with-gddr6-memory-navi-spotted.html

 

[Yotsugi]

https://www.guru3d.com/news-story/n...cb-photos-with-gddr6-memory-navi-spotted.html

Eww early naked PCB, without even memory.
At least the first Turing PCB leak showed up with it.

 

[Stuka87]

Ok, so we know it uses standard GDDR in most likely a 256bit configuration. I don't think anybody thought it would use HBM, but this proves it won't. And it has 2x8pin PCI-E power adapters. Which is interesting.

 

[crazzy.heartz]

2x 8Pin Connectors (shudders)

No 300+ Watt cards again, please..

 

[Yotsugi]

2x 8Pin Connectors (shudders)

No 300+ Watt cards again, please..

Of course it's gonna be a 300W future console fuel.
Who could've guessed?

 

[NostaSeronx]

Does anyone know what
- "Enable CU wavefront execution mode"
- HWRC // Register destination cache
means? (Cause, I think it is Super-SIMD-related, pre-Super-SIMD before they go Super-SIMD.)

Extra:
GFX9 and lower;
// The latency values are 1 / (operations / cycle) / 4.
WriteBranch, [HWBranch], 8
WriteExport, [HWExport], 4
WriteLDS, [HWLGKM], 5 // Can be between 2 and 64
WriteSALU, [HWSALU], 1
WriteSMEM, [HWLGKM], 5
WriteVMEM, [HWVMEM], 80
WriteBarrier, [HWBranch], 500 // XXX: Guessed ???
----
Write32Bit, [HWVALU], 1
Write64Bit, [HWVALU], 2
WriteQuarterRate32, [HWVALU], 4
WriteFloatFMA, [HWVALU], 1
WriteDouble, [HWVALU], 4
WriteDoubleAdd, [HWVALU], 2
WriteDoubleCvt, [HWVALU] 4

GFX10.1 // GFX1010 is however;
// The latency values are 1 / (operations / cycle).
WriteBranch, [HWBranch], 32
WriteExport, [HWExport, HWRC], 16
WriteLDS, [HWLGKM, HWRC], 20
WriteSALU, [HWSALU, HWRC], 5
WriteSMEM, [HWLGKM, HWRC], 20
WriteVMEM, [HWVMEM, HWRC], 320
WriteBarrier, [HWBranch], 2000
----
// Add 1 stall cycle for VGPR read.
Write32Bit, [HWVALU, HWRC], 5
Write64Bit, [HWVALU, HWRC], 9
WriteQuarterRate32, [HWVALU, HWRC], 17
WriteFloatFMA, [HWVALU, HWRC], 5
WriteDouble, [HWVALU, HWRC], 17
WriteDoubleAdd, [HWVALU, HWRC], 17
WriteDoubleCvt, [HWVALU, HWRC], 17

First group can be, / 4, and second group is, - 1 and /4. To get the GFX9 and lower values.

 

[Yotsugi]

HWRC // Register destination cache
means?

Means exactly what it means.
It's an opreuse cache, ol'faithful.

 

[NostaSeronx]

Means exactly what it means.
It's an opreuse cache, ol'faithful.

It isn't a op-cache; https://patents.google.com/patent/US20180357064A1/
"Additionally, the stream processor includes a vector destination cache to provide additional write and read bandwidth for the vector register file."
"In various embodiments, the stream processor is able to reduce power consumption by avoiding the duplication of operands within the same instruction. Also, the stream processor is configured to bypass the source operand buffer by reading directly from the vector register file RAM output flops when possible. Additionally, the vector destination cache includes multiple read ports for access from the VALU allowing the VALU to bypass accessing the vector register file bank RAM. Still further, the stream processor is configured to perform an on-demand allocation of the vector destination cache to increase the storage utilization of the vector destination cache. Still further, the stream processor includes a cache recycling mechanism to avoid refetching operands and to provide an extended data dependency check window."

One of the major things, it does not reference Super-SIMD. Which renames the VDST unit into Do$, or vice versa.

https://patents.google.com/patent/US20180121386A1
"The Do$ holds multiple instructions to extend an operand by-pass network to save read and write transactions' power."
"The VALU destination does not need to be written to main VGPR every cycle, as Do$ 250 can provide the ability to skip the write for write and write cases, such as those intermediary results for accumulated MUL-ADD."
"Do$ 250 holds multiple (typical value might be 8 or 16 instructions per cycle) instructions' destination data to extend the operand's by-pass network to save the main VGPR 110 read and write power."

 

[Yotsugi]

It isn't a op-cache

I never said opcache.
I said operand reuse cache (kind of wonky naming, but it can't be helped).
Like the one nV implements since Maxwell.
Bunch of CAMs, for fun and entertainment.

 

[Glo.]

If what seronx posted is correct, it pretty much confirms Navi is Super-SIMD architecture.

This thing will be pretty fast .

 

[Yotsugi]

it pretty much confirms Navi is Super-SIMD architecture.

More akin to what nV does, really.
But yes, the SIMDs are completely different.

 

[Glo.]

It appears it also confirms that this patent: https://patents.google.com/patent/US20180357064A1/
Is part of Navi's architecture. It appears quite a lot of architecture patents will appear with this architecture:

Proper Geometry Culling, Super-SIMD, High Bandwidth Vector Register files. Navi appears to be much more Graphics focused architecture than Compute.