Speculation: Ryzen 4000 series/Zen 3

[soresu]

Another option for Zen 3 is shared front-end with shared FPU - Bulldozer style. Front-end capable handling of 4-threads, back-end consisting of 2x Zen3+SMT2 int cores and shared powerful FPU (12-pipes shared by 4 threads). AMD has an experience with BD, it's simpler to do (than wider entire core +SMT4) and allows great FPU boost (indicated by leaks +40-50% FPU performance). However it's kind of sub-optimal solution IMHO.

Won't happen end of, anything that even looks like it will spook AMD customers and stock investors after the BD fustercluck - optics are extremely important when you are both this high and yet not the mountainous business force that is Intel (financially I mean).

I'll be happy to eat my words when the Zen3 details come out, but I strongly doubt that will be the case.

It's my opinion that someone convinced them during BD's concept stage that CMT was simply better than SMT, at the very least in terms of power efficiency - that plan may have been leaned into in the hope that a different MT strategy could make them unique in the market, unfortunately it caused them to fall spectacularly on their face amidst broken, burning glass.

 

[Topweasel]

Won't happen end of, anything that even looks like it will spook AMD customers and stock investors after the BD fustercluck - optics are extremely important when you are both this high and yet not the mountainous business force that is Intel (financially I mean).

I'll be happy to eat my words when the Zen3 details come out, but I strongly doubt that will be the case.

It's my opinion that someone convinced them during BD's concept stage that CMT was simply better than SMT, at the very least in terms of power efficiency - that plan may have been leaned into in the hope that a different MT strategy could make them unique in the market, unfortunately it caused them to fall spectacularly on their face amidst broken, burning glass.

I think GCN and BD put AMD in motion for their current moves. Everything was great with GCN for a release or two, but they thought they would get more developers to adopt better Mantle or move to Mantle like API's. But instead as soon as DX12 gets announces everyone just stops using Mantle. Years before DX12 and Vulcan get actually used. It also wasn't every coheasive. Mantle and direct GPU scheduling reduced CPU requirements where BD required programs to be written for it to utilized the extra resources per module. Both needing heavier work done by developers both in competing ways.

Zen was and RDNA is the start of on GPU's them going back to the basics. Make your stuff work the best on what is already out there. Do what they started with the old HD GPU lineup. Make sure its fast for what is out there, then add functionality. Don't require the added functionality to make the product work correctly (or in some cases worth while, the Geforce256 didn't sell because T&L and the RTX series for Ray tracing, they sell because they run everything else fast, but the RTX series is so lateral that RT is a selling point which I think was a mistake). Doubtful they make the same mistake so soon.

 

[soresu]

Mantle and direct GPU scheduling reduced CPU requirements where BD required programs to be written for it to utilized the extra resources per module. Both needing heavier work done by developers both in competing ways.

Yes, unfortunately I think AMD ha erred more than once on the point of leaving it to outside developers to do the work, especially when Intel and nVidia can afford to splurge on teams of software engineers to largely do it for them.

Strange that the console dominance AMD held didn't translate to more developers using AMD's hardware on principle though - I guess the difference in software platforms were too significant to directly translate experience perhaps.

I think that AMD could do with investing in their own optimised Linux build (like Clear Linux for Intel), but more for their GPU endeavors - the Linux community seem to be covering Zen support pretty well so far.

 

[Ajay]

Request for clarification: is TSMC 5nm going to be more akin to TSMC 7nm+ or 6nm?

7nm+. TSMC 6nm FF is an area reduction node based off 7nm FF. 5nm EUV isn’t just an optical shrink and will require more substantial design effort (which is probably why TSMC developed 6nm FF).

 

[soresu]

Years before DX12 and Vulcan get actually used.

Arguable - widely used would be a better argument.

DOOM 2016 had a Vulkan back end the same year Vulkan was announced, and Rise of the Tomb Raider had a DX12 update less than a year after W10 launched with DX12 officially.

It was a slow start sure, but far better than earlier API's like DX11 which took ages to get significant support.

 

[Thunder 57]

Arguable - widely used would be a better argument.

DOOM 2016 had a Vulkan back end the same year Vulkan was announced, and Rise of the Tomb Raider had a DX12 update less than a year after W10 launched with DX12 officially.

It was a slow start sure, but far better than earlier API's like DX11 which took ages to get significant support.

Vulkan Doom was great. OpenGL Doom at launch, not so much. It would just crash or stop responding at times. As time went on, that went away. I'm not sure if that was due to game fixes or Vulkan (which I turned on as soon as it was available) but it got better. I wish more developers would use Vulkan.

id/Bethesda/whoever has always went with OpenGL, or anything other than DirectX. Typically with good results.

 

[Topweasel]

Arguable - widely used would be a better argument.

DOOM 2016 had a Vulkan back end the same year Vulkan was announced, and Rise of the Tomb Raider had a DX12 update less than a year after W10 launched with DX12 officially.

It was a slow start sure, but far better than earlier API's like DX11 which took ages to get significant support.

Not sure what's off about what I said.

GCN launched in 2012, Mantle launched with BF4 in 2013, MS announced DX12 in 2014, 2 years later in 2016 Doom launched. I did mean widely used but the facts check out as is. DX12 wasn't consistently used till late 17 early 18. 5-6 years after AMD developing a uarch meant for on device scheduling to be used with low lovely api's.

 

[soresu]

5-6 years after AMD developing a uarch meant for on device scheduling to be used with low lovely api's.

I think it was less designed for Mantle/low level API as compute in general - its problems lay with extracting gaming FPS from all those lovely TFLOPS, something that nVidia's less versatile uArch was far more suited to.

I'd say low level API's just mitigated GCN's problems on the gaming side - I can only assume that the consoles made a better job of it as singular platform targets being easier to optimise for.

 

[Topweasel]

I think it was less designed for Mantle/low level API as compute in general - its problems lay with extracting gaming FPS from all those lovely TFLOPS, something that nVidia's less versatile uArch was far more suited to.

I'd say low level API's just mitigated GCN's problems on the gaming side - I can only assume that the consoles made a better job of it as singular platform targets being easier to optimise for.

They certainly had an eye towards general compute capability rather then adding specialized compute functionality. Well at least at the start. But I think that was the plan write to Mantle or other Low Level API's and boom these basically compute units would do great graphics as well. It helped them that the 7900 series and 200 series where generally pretty competitive at least at launch but Efficiency killed them. But the big problem is AMD thought they could change the market, maybe not to their will like Intel, but what they thought was just a better solution. But like I said lost their vision when it came to making sure first and foremost it was really good for what they were doing now. The 7970 and 290x were really fast, but way to big, and power hungry to keep up with Nvidia in the long run because the uarchs themselves where not particularly good at what was already out there.

 

[Olikan]

I think it was less designed for Mantle/low level API as compute in general - its problems lay with extracting gaming FPS from all those lovely TFLOPS, something that nVidia's less versatile uArch was far more suited to.

I'd say low level API's just mitigated GCN's problems on the gaming side - I can only assume that the consoles made a better job of it as singular platform targets being easier to optimise for.

Yeah, no low level API can fix GCN memory subsystem (huge bandwidth requirements)

 

[itsmydamnation]

Yeah, no low level API can fix GCN memory subsystem (huge bandwidth requirements)

When GCN was released it's memory sub system was fine, what the actual problem is AMD having no money to turn R&D ( see patients) into products as a result GCN 2,3,4,5 really didn't add a lot at the same time NV made big uarch changes almost every generation if not every second. But now AMD has money again and RDNA is the first product to come to market with that money. I expect each new generation to have far more uarch changes then ever existed within GCN.

 

[soresu]

When GCN was released it's memory sub system was fine, what the actual problem is AMD having no money to turn R&D ( see patients) into products as a result GCN 2,3,4,5 really didn't add a lot at the same time NV made big uarch changes almost every generation if not every second. But now AMD has money again and RDNA is the first product to come to market with that money. I expect each new generation to have far more uarch changes then ever existed within GCN.

True to an extent - I also believe that nVidia had to make more changes due to its more narrow focus on fps rather than a more forward thinking and compute versatile design like GCN.

The problem with that versatility in GCN was that like a big boat, it ate a lot of fuel and didn't turn quite so quickly (or cheaply) as a small one.

 

[moinmoin]

When GCN was released it's memory sub system was fine, what the actual problem is AMD having no money to turn R&D ( see patients) into products as a result GCN 2,3,4,5 really didn't add a lot at the same time NV made big uarch changes almost every generation if not every second. But now AMD has money again and RDNA is the first product to come to market with that money. I expect each new generation to have far more uarch changes then ever existed within GCN.

The development on RDNA definitely started way before Zen brought in the new money. Previously its progress just was majorly linked to the demand by the game console manufacturers that only now are getting into the final stage of finalizing their next gen products.

 

[Olikan]

When GCN was released it's memory sub system was fine, what the actual problem is AMD having no money to turn R&D ( see patients) into products as a result GCN 2,3,4,5 really didn't add a lot at the same time NV made big uarch changes almost every generation if not every second. But now AMD has money again and RDNA is the first product to come to market with that money. I expect each new generation to have far more uarch changes then ever existed within GCN.

While it's true about R&D... Amd also just went into a diferent path than Nvidia, Amd co-developed HBM with Samsung, while Nvidia went color compression, tiled rendering and cache...

 

[soresu]

The development on RDNA definitely started way before Zen brought in the new money. Previously its progress just was majorly linked to the demand by the game console manufacturers that only now are getting into the final stage of finalizing their next gen products.

The Wave32 uArch compatibility with Wave64 GCN code shows a clear console backwards compatibility thinking in RDNA development - it means together with Zen it should play any XB1/PS4 games well, and probably anything else like virtual console emulators coded for them too.

For Sony and Microsoft this represents the first generation where they have anything like the BW compatibility of Gamecube to WiiU that Nintendo had - coupled with a serious boost to performance its a win win for them.

 

[soresu]

Amd co-developed HBM with Samsung

I thought it was SK Hynix they partnered with?

 

[Olikan]

I thought it was SK Hynix they partnered with?

Oh yes, oops

 

[Ajay]

Wait a minute, what thread is this ?

 

[soresu]

Wait a minute, what thread is this ?

It happens more often than not, I've gotten confused which thread I was on more than once.

 

[ClockHound]

It happens more often than not, I've gotten confused which thread I was on more than once.

This forum supports SMT4 or is it 5...

 

[misuspita]

Ryzen 3 4200G “Renoir” spotted on SiSoft Sandra

Industry insider TUM_APISAK recently spotted a SiSoft Sandra OpenCL listing for the supposed Ryzen 3 4200G. Higher clock speeds promise better GPU performance. But does it feature Vega or Navi?

www.notebookcheck.net

Well, first signs of new APUs. I wonder what freq the cpu part will have

 

[uzzi38]

God, who wrote that article, that's absolutely horrible.

For starters, Renoir is still using Vega. This has been an established fact for literal months now, I don't get why it's still up for debate. It appears somebody needs to teach the writer the difference between CU counts and Codenames, the GPU in APUs don't get codenames. You don't go and say, 'Oh, there's gonna be a Navi 12, must be what the QPUs are getting'.

Secondly, Renoir shouldn't be changing much in the way of CU count, and that device has 8 CUs (512 shaders / 64 is 8). So I have no clue where the assumption its the Ryzen 3 4200U comes from.

 

[soresu]

Secondly, Renoir shouldn't be changing much in the way of CU count, and that device has 8 CUs (512 shaders / 64 is 8). So I have no clue where the assumption its the Ryzen 3 4200U comes from.

Yeah, I'd say 16 maximum, I heard 15 from one quarter.

 

[uzzi38]

Yeah, I'd say 16 maximum, I heard 15 from one quarter.

Afaik, 15 is already really high given GCNs scaling at higher core counts per Shader, I was personally expecting 13-14 max with mobile retail skus having 12 enabled.

Though I'm basing it off that old product master list that is almost certainly out of date. I mean, it listed 16 core Threadrippers, which were scrapped once EPYC started flying off the shelves and they didn't have the dies to throw at a useless sku any more.

 

[Richie Rich]

AMD Mark Papermaster actually didn't reject SMT4 for any upcoming product. This is a bit strange because he could do that and stop all speculations about SMT4 (unhelthy for stock market) and just confirm SMT2 from that leaked presentation. However he did not. Maybe he couldn't do that because Zen3 will support both SMT2 and SMT4.

AMD CTO Mark Papermaster: More Cores Coming in the 'Era of a Slowed Moore's Law'

Get ready for more cores

www.tomshardware.com