D
Deleted member 13524
Guest
Pin compatible with Zeppelin
AMD back in early 2016 seemed to call "Zeppelin" to what is now the 2*CCX core that is present on current Ryzen CPUs.
AMD back in early 2016 seemed to call "Zeppelin" to what is now the 2*CCX core that is present on current Ryzen CPUs.
APU with quad core + 11 CUs.
No sign of any HBM
The HSA feature box also does not show going forward.
The core is still called Zeppelin, it doesn't refer to just 2*CCX but the whole 8-core chip with interconnects and memorycontrollers and everythingAMD back in early 2016 seemed to call "Zeppelin" to what is now the 2*CCX core that is present on current Ryzen CPUs.
I'd be shocked if HSA were really gone, but HBM, tempting as it is for APUs, is still limited in capacity and quite expensive. AMD could theoretically make a chip with dual memory controllers and PHYs, but that would cost them some effort, time, silicon area and power. Being restricted to HBM alone would make the chip unusable for a lot of server workloads, which could be a problem.
Sent from my Archos 50 Helium Plus using Tapatalk
Sent from my Archos 50 Helium Plus using Tapatalk
D
Deleted member 13524
Guest
My line of thinking is if Intel gets to charge $400 for the 15-28W dual-cores with Iris Pro and eDRAM, why wouldn't OEMs ask AMD for a similarly premium APU using HBM, knowing that it'd get substantially better performance?
itsmydamnation
Veteran
They probably dont even need HBM to do it*, but if i was AMD i would have thought it was worth the cost to put 1 HBM memory controller on a RR die connected to the GPU cache controller. In products that dont use HBM just package as normally. As HBM2 pricing changes OEM's/AMD can re-evaluate the cost/ performance trade off in there pricing stack.
*hopeflly AMD with 1/2 decent cores will force reviews etc to actually evaluate intels GPU drivers/real world performance far more then they currently do.
"Only 32-bit OSes are affected, and only when running 16-bit real-mode code". <--- doesn't sound like a blocker, unless you have to run old OS inside the VM.
Let's put it this way. If you had to put your OS install inside a vm, your head would explode from rage. For the rest of the world, they're really not affected.
There's plenty of bleeding edge users at the server forums that have been having nothing but grief trying to keep their new server builds stable. Like with everything Linux based, they should have waited for actual hardware support before jumping in. I hope that their issues aren't tied to non-fixable hardware and simply need better software support built into the kernels.
Blazkowicz
Legend
I had no idea such an enhancement to the VM86 mode existed.
If you had a 386 or better running Windows 3.0 or 3.1, the VM86 mode is what is used to run DOS command prompts (multiple of them!) from Windows.
There's still something similar today : you can install the 32bit version of Windows 10 on physical hardware and run Windows 3.1 applications. It would be fairly unlikely someone does this on a Ryzen but then your Windows 3.1 applications should crash and fail to run even though you're not using VMware, Virtualbox or Hyper-V etc.
If you had a 386 or better running Windows 3.0 or 3.1, the VM86 mode is what is used to run DOS command prompts (multiple of them!) from Windows.
There's still something similar today : you can install the 32bit version of Windows 10 on physical hardware and run Windows 3.1 applications. It would be fairly unlikely someone does this on a Ryzen but then your Windows 3.1 applications should crash and fail to run even though you're not using VMware, Virtualbox or Hyper-V etc.
AMD probably just doesn't bother to market it anymore. Its ROCm stack is built upon parts from the HSA effort anyway, and AMD can very well roll cache coherency and platform atomics for Raven Ridge in ROCm without HSA compliance at launch.
It just costs more or less the effort of building a normal monolithic SoC, with extra cost in assembly. TBH it would just be a giant APU with a different configuration of GPU local memory. Whether it is marketable is another story.
Why would it? The so-called "HBCC" already addressed the issue, and is working very well for Nvidia under the name Unified Virtual Memory. The HMM patch in Linux is also on its way to upstream. Let alone the fact that the APU may already access pageable system memory directly without it.
Last edited:
Blazkowicz
Legend
In the linked article and one of its comments, they give the workaround for disabling this thing in vmware (or leave to you the task of finding out how to do it if you use something else). That and a microcode update might either disable or fix the feature. Or a small patch for your virtualization software might work around it.
So, this is a visible hardware bug but not a terribad one.
We can be 100% sure there are many other ones like on any new CPU.
So, this is a visible hardware bug but not a terribad one.
We can be 100% sure there are many other ones like on any new CPU.
Last edited:
Both windows xp and server 2003 have x64 versions. Which cand run on Ryzen. Thus the issue is for existing deployments rather.
What that article seemed to imply was that this info was under NDA for a while. For me, that's the alarming bit. That sound unprofessional on AMD's part?
What that article seemed to imply was that this info was under NDA for a while. For me, that's the alarming bit. That sound unprofessional on AMD's part?
DavidGraham
Veteran
I'd expect it to be, given how it boots with a Ryzen logo
I'm getting really good performance on Prey at 4k Ultra but that's to be expected because I'm aiming for 60 fps and it is pretty much locked at that. Good thing they bundled that game with the Crosshair VI Hero, it's a very good game!
I'm getting really good performance on Prey at 4k Ultra but that's to be expected because I'm aiming for 60 fps and it is pretty much locked at that. Good thing they bundled that game with the Crosshair VI Hero, it's a very good game!
Similar threads
