Vega refresh - Expected? How might it look?

[DaQuteness]

In Windows,
I find three Vega part numbers in the driver for the Crimson Relive 17.8.2
687f.1, 687f.2, 687f.3
In Linux

    {0x1002, 0x6860, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_VEGA10|AMD_EXP_HW_SUPPORT},
    {0x1002, 0x6861, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_VEGA10|AMD_EXP_HW_SUPPORT},
    {0x1002, 0x6862, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_VEGA10|AMD_EXP_HW_SUPPORT},
    {0x1002, 0x6863, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_VEGA10|AMD_EXP_HW_SUPPORT},
    {0x1002, 0x6864, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_VEGA10|AMD_EXP_HW_SUPPORT},
    {0x1002, 0x6867, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_VEGA10|AMD_EXP_HW_SUPPORT},
    {0x1002, 0x6868, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_VEGA10|AMD_EXP_HW_SUPPORT},
    {0x1002, 0x686c, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_VEGA10|AMD_EXP_HW_SUPPORT},
    {0x1002, 0x687f, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_VEGA10|AMD_EXP_HW_SUPPORT},

However I cannot correlate the parts against the Marketing name. Anyone can help?

There's a 687F.4 as well... So far It's probably FE, RX64, RX56 and maybe an upcoming entry-level RX32 - just an assumption but these ID's have been circulating (especially .1) since before FE launch.

http://www.guru3d.com/news-story/device-id-687fc1-surfaces-in-aots-vega-10-aka-rx-490-spotted.html

Here's a small trivia: In the FE presentation brochure included in the box, if you read the small label on the liquid cooled version of FE (the gold one) it does indeed say RX490 on it (YES! I READ IT!!) I'll post a pic to prove my point...

 

[Magic Hate Ball]

There's a 687F.4 as well... So far It's probably FE, RX64, RX56 and maybe an upcoming entry-level RX32 - just an assumption but these ID's have been circulating (especially .1) since before FE launch.

http://www.guru3d.com/news-story/device-id-687fc1-surfaces-in-aots-vega-10-aka-rx-490-spotted.html

Here's a small trivia: In the FE presentation brochure included in the box, if you read the small label on the liquid cooled version of FE (the gold one) it does indeed say RX490 on it (YES! I READ IT!!) I'll post a pic to prove my point...

If we go down by multiples of 8, I'd say that a 40 or 48 CU w/ 4gb of HBM2 could possibly fill in some of the RX580/570 4gb part range, especially if HBCC works properly, then maybe even the 8gb range..

It depends on the cost of the RAM, and how much they can (or need to) salvage from Vega 10 silicon.

 

[Ancalagon44]

Isn't there also a Vega 11 coming?

 

[Qwertilot]

Its possible they decided a bit back that there wasn't much point trying to make it. Where would it go? Even vs AMD's current product stack it isn't that obvious - would it really be expected to truly improve on the 570/80?

Vs NV it'll be ~1060 performance at best and it'd only have a few months before Volta appears and its down to ~1150 tier.

The 56/64 they can at least hope to sell into the compute markets.

 

[Ancalagon44]

Also what if they released a Vega 11 and Polaris 10 outperformed it in either outright performance or performance per watt?

 

[DaQuteness]

Also what if they released a Vega 11 and Polaris 10 outperformed it in either outright performance or performance per watt?

To quote Sheldon from The Big Bang Theory: "If IFs and BUTs were candy and nuts, we'd all have a merry christmas..."

We should really focus on bringing clarity to what is on the table rather than building any further speculation. Volta will shatter Vega's pinky-sized gamer market grasp, that's a given looking at nVidia's history so far, I'd say it is obvious, although I sincerely wish I will have been proven wrong.

It's a real shame it's not more competitive for gamers' sake, but for content creators such as myself, if they fix those shit drivers, it's an easy choice to make going for Vega. Gamers... maybe the 56 and even then it's a bit iffy.

 

[zlatan]

Can you tell more about Primitive Shaders? What it does exactly, and what difference in performance we can see from it?

In theory it can do a lot. One of the biggest problems with the current pipeline is that Microsoft always designed a lot of very inefficient shader stages. Vertex and fragment shaders are fine, but geometry shader was a total failure. Making the primitive assembly stage programmable was a good thing, but how they are did it was bad, and this resulted a lot of load balancing issues on most gaming hardwares. Only Intel has a good implementation, because their design has an awful lot of registers per hardware threads, but this is completely stupid from an engineering standpoint. Domain shader is also very inefficient.
Primitive shader is a general-purpose option to combine and replace the actual stages of the geometry processing. This will allow a more efficient shader execution with much better primitive discard rate and reduced processing overheads.

Personally I would like to see a new graphics pipeline in the future, with primitive, fragment and compute shader. We really don't need that fat and slow domain/geometry shading, and also vertex and hull shader can be replaced with combined surface shading, which is already part of the primitive shader.

 

[DaQuteness]

If anyone is interested in finding out more, this is the Vega whitepaper on it's architecture:

http://radeon.com/_downloads/vega-whitepaper-11.6.17.pdf
http://radeon.com/_downloads/vega-whitepaper-11.6.17.pdf
Hope it helps, it's fascinating to read (if you're into these things of course )

 

[Qwertilot]

To quote Sheldon from The Big Bang Theory: "If IFs and BUTs were candy and nuts, we'd all have a merry christmas..."

We should really focus on bringing clarity to what is on the table rather than building any further speculation. Volta will shatter Vega's pinky-sized gamer market grasp, that's a given looking at nVidia's history so far, I'd say it is obvious, although I sincerely wish I will have been proven wrong.

I really don't know - competition is nice but If you must believe in miracles I'd prefer positive ones

Given V100 the level of ****** up that NV would have to contrive for Volta to not do this for gaming would be thoroughly traumatic to behold. I'd much rather have one tech company executing reliably well than none.

 

[DaQuteness]

In Windows,
I find three Vega part numbers in the driver for the Crimson Relive 17.8.2
687f.1, 687f.2, 687f.3
In Linux

    {0x1002, 0x6860, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_VEGA10|AMD_EXP_HW_SUPPORT},
    {0x1002, 0x6861, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_VEGA10|AMD_EXP_HW_SUPPORT},
    {0x1002, 0x6862, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_VEGA10|AMD_EXP_HW_SUPPORT},
    {0x1002, 0x6863, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_VEGA10|AMD_EXP_HW_SUPPORT},
    {0x1002, 0x6864, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_VEGA10|AMD_EXP_HW_SUPPORT},
    {0x1002, 0x6867, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_VEGA10|AMD_EXP_HW_SUPPORT},
    {0x1002, 0x6868, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_VEGA10|AMD_EXP_HW_SUPPORT},
    {0x1002, 0x686c, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_VEGA10|AMD_EXP_HW_SUPPORT},
    {0x1002, 0x687f, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_VEGA10|AMD_EXP_HW_SUPPORT},

However I cannot correlate the parts against the Marketing name. Anyone can help?

Hi there, I found this list to help you in identifying exactly which is which:

http://developer.amd.com/resources/ati-catalyst-pc-vendor-id-1002-li/

 

[DisEnchantment]

Hi there, I found this list to help you in identifying exactly which is which:

http://developer.amd.com/resources/ati-catalyst-pc-vendor-id-1002-li/

This page is provided as an engineering resource. Updated July 2016.

it is a little outdated. But thanks nonetheless.

 

[DisEnchantment]

I was thinking of what could happen with future VEGA and ZEN CPU+SOC versions. The current ryzen CPUs are really SOC, a system on a chip.
SInce PCIe and IF and possibly GMI can share the same pins and the selection is just configuration of the pins and serdes through configuration registers in the SOC, we might see a future zen system that has by default a 16x PCIe link when using older AMD GPUs or nvidia GPUs and perhaps it is possible to turn the 16x PCIe link into a GMI or IF link when vega 20 is detected by the soc software in the agesa. But that might have to wait until PCIe v5 is in effect because of the higher clock frekwenties and new required PCIe connectors for high clock frequencies.
https://www.extremetech.com/computi...ns-launch-pcie-5-0-2019-4x-bandwidth-pcie-3-0

Indeed. I find the IF the most interesting part of Vega. Also AMD considers Vega as an SoC just like Ryzen.

EPYC repurpose PCIe lanes for xGMI in 2S configuration. There may be possibility of Zen + Vega communication via xGMI. Although the AMD slides shows Vega 20 peer to peer communication.

If we look at AMD's strategy with EPYC, with the CCX being the building block of high core count CPUs for the server market and take the case of Vega Architecture in the near future with IF, it seems to me AMD has a plan with Vega 20.
According to AMD roadmaps Vega 20 is the HPC SKU with 1/2 DPFP. Even with GF 7nm, AMD kept 64CUs, but opted for xGMI. I wonder what AMD could implement with multiple Vega 20 communicating with each other. They may be on to something.
Vega 10 was never designed for HPC according to AMD roadmaps contrary to what a lot of posts in the other thread seems to suggest. It might as well be the proverbial pipe cleaner like Ryzen 7 is for EPYC server SKUs .

Also there is NGG enabling code in the latest 4.15 WIP staging in linux. Not sure what it does.

But, what is Vega 10 x2. It does not seem to me like two Vega 10 slapped together, since the CU count is the same, but BW is doubled. At least not in these Official presentations.

 

[DisEnchantment]

The HBCC is in my opinion a mixture of an IOMMU, an MMU, DMA engine and memory controller.

Exactly.
I mean how different is this from MMU and Virtual addresses for x86 conceptually. It seems very MMU to me.
Application load gazillion bytes of data, Processor loads data from some virtual address not currently in memory, page fault, swap, done. If that paging is from SSD then that is incredible.
I also heard that this functionality cannot be implemented by NVIDIA due to x86 licensing issue. Only Intel can do similar thing. NVIDIA can do it for other arch though.

 

[evilr00t]

I also heard that this functionality cannot be implemented by NVIDIA due to x86 licensing issue. Only Intel can do similar thing. NVIDIA can do it for other arch though.

There seems to be a lot of FUD around nVidia's equivalent to AMD's HBCC (iommu, copy engine, virtual addressing, paging).

The IOMMU and copy engine have been around since before Kepler (unified memory). *see edit below
What's new in Pascal is "49-bit virtual addressing and on-demand page migration"; nVidia's first implementation is Pascal: https://devblogs.nvidia.com/parallelforall/beyond-gpu-memory-limits-unified-memory-pascal/

It doesn't require any x86 license, because Pascal is not an x86 architecture.

For paging to work, OS support is necessary. See this Linux article: https://lwn.net/Articles/679300/
The term Linux uses for this technology is heterogeneous memory management, and it suggests page table formats don't follow the x86 standard on the device. It's also noteworthy to see nVidia, AMD, and Mellanox all on the same email chain; it suggests that HMM extension was developed collaboratively.

Edit: Corrected error - IOMMU has been around since Kepler because that's when unified memory was implemented. Copy engine has been around forever for async data copies - at least Fermi, and possibly Tesla architecture.

 

[William Gaatjes]

Exactly.
I mean how different is this from MMU and Virtual addresses for x86 conceptually. It seems very MMU to me.
Application load gazillion bytes of data, Processor loads data from some virtual address not currently in memory, page fault, swap, done. If that paging is from SSD then that is incredible.
I also heard that this functionality cannot be implemented by NVIDIA due to x86 licensing issue. Only Intel can do similar thing. NVIDIA can do it for other arch though.

Ah, you are mistaking x86 segmented memory model from x86 real and protected mode with the paging system a mmu can do.
The paging an MMU can do is not exclusive to x86.
All cpu and gpu architectures can have an MMU and in practice do have one because it is very convenient to run an OS with use of an MMU where each process have its own private memory space. Also, it is easier and faster to just load up the part of data that is needed instead of loading up all data from memory.
For example ARM:
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0211h/Babbhigi.html

As a sidenote:
To come back to x86, although x86 cpu are still required to start up in x86 real mode, when switching over to x86-64bit long mode,
The segmentation of the memory is no longer present and the cpu can do linear addressing.
https://en.wikipedia.org/wiki/X86_memory_segmentation

Thus, the dividing of memory in pages and the paging of memory is not exclusive to AMD or to the x86 architecture in general.


edit:
extra links ( I looked up on my phone during travel to work)
http://homepages.wmich.edu/~grantner/ece6050/ARM7100vA_3.pdf
https://en.wikipedia.org/wiki/X86-64

 

[DisEnchantment]

For paging to work, OS support is necessary. See this Linux article: https://lwn.net/Articles/679300/
The term Linux uses for this technology is heterogeneous memory management, and it suggests page table formats don't follow the x86 standard on the device. It's also noteworthy to see nVidia, AMD, and Mellanox all on the same email chain; it suggests that HMM extension was developed collaboratively.

This is interesting. Many thanks.

 

[zlatan]

I also heard that this functionality cannot be implemented by NVIDIA due to x86 licensing issue. Only Intel can do similar thing. NVIDIA can do it for other arch though.

Well, they can implement a general memory paging system. Pascal pinned memory is one simple example. Not as general as HBCC, but it works within it's own limitations. They only need x86 if they want direct access to the CPU's page tables. Volta support this, but only if the host CPU uses IBM Power cores.

A general memory paging system is not one big feature. It is more like a set of features or capabilities. And because of this the implementations may vary.

 

[DisEnchantment]

GFX9 Changes in Mesa
[Mesa-dev] [PATCH 3/3] radeonsi/gfx9: implement primitive binning
https://lists.freedesktop.org/archives/mesa-dev/2017-September/168270.html

This increases performance, but it was tuned for Raven, not Vega.
We don't know yet how Vega will perform, hopefully not worse.

[Mesa-dev] [PATCH 00/14] AMD GCN tile swizzle
https://lists.freedesktop.org/archives/mesa-dev/2017-August/164897.html

http://gpuopen.com/unlock-the-rasterizer-with-out-of-order-rasterization

[Mesa-dev] [PATCH 1/2] radeonsi: enable out-of-order rasterization when possible on VI and GFX9 dGPUs
https://lists.freedesktop.org/archives/mesa-dev/2017-September/168873.html
[Mesa-dev] [PATCH 1/2] radeonsi: enable out-of-order rasterization when possible on VI and GFX9 dGPUs
https://lists.freedesktop.org/archives/mesa-dev/2017-September/168858.html

@zlatan : Could you please break these changes down for us? Are these already there on Windows?

 

[maddie]

http://www.digitimes.com/news/a20170908PD210.html
SPIL obtains packaging orders for AMD Vega 11 GPUs

Where will this fit? A HBM2 card to replace Polaris 10? This, to me, is further circumstantial evidence that Vega 10 was expected to have a lot more performance than we're seeing.

 

[ub4ty]

Indeed. I find the IF the most interesting part of Vega. Also AMD considers Vega as an SoC just like Ryzen.

EPYC repurpose PCIe lanes for xGMI in 2S configuration. There may be possibility of Zen + Vega communication via xGMI. Although the AMD slides shows Vega 20 peer to peer communication.

If we look at AMD's strategy with EPYC, with the CCX being the building block of high core count CPUs for the server market and take the case of Vega Architecture in the near future with IF, it seems to me AMD has a plan with Vega 20.
According to AMD roadmaps Vega 20 is the HPC SKU with 1/2 DPFP. Even with GF 7nm, AMD kept 64CUs, but opted for xGMI. I wonder what AMD could implement with multiple Vega 20 communicating with each other. They may be on to something.
Vega 10 was never designed for HPC according to AMD roadmaps contrary to what a lot of posts in the other thread seems to suggest. It might as well be the proverbial pipe cleaner like Ryzen 7 is for EPYC server SKUs .

Also there is NGG enabling code in the latest 4.15 WIP staging in linux. Not sure what it does.

But, what is Vega 10 x2. It does not seem to me like two Vega 10 slapped together, since the CU count is the same, but BW is doubled. At least not in these Official presentations.

TLDR : All of your discussed hypotheticals are already implemented on Nvidia cards, like Radeon cards, it all matters how much you're willing to pay to get them. Pro-line cards have had these features for years and it doesn't appear either Nvidia/Radeon have found it within themselves to stop gimping/disabling them on consumer cards. For this reason, I'm excited about a new entrant into this space to shake both of them up.

Taking a step back and looking at this as software/hardware, what exists today, and what could exist :
Vega (IF) = internal network on vega cards just like it is an internal network on Ryzen CPUs.
EPYC implements IF protocol over a physical wire trace to another EPYC CPU is 2S (2 cpu configuration). You always need a physical wire trace if you plane to take IF off die....

PCI-E physical wire trace is PCI-E. You can't repurpose this trace on motherboards. You can encap a protocol across PCI-E but you still have PCI-E latencies and its still PCI-E at the base layer. So, this cuts down a lot of ifs from your commentary. GPUs already communicate directly to each other. Radeon and Nvidia have had this technology for ages : DirectGMA/GPU-direct. The issue is that both of them restrict this to their pro-line cards. Radeon is no different and does this to. Is it really that much more costly to implement? No. It's likely a firmware/software disable on consumer cards. So, nothing revolutionary happens w.r.t this w/ Vega 20. Nvidia btw already has NV-Link which is equivalent to an IF interconnect between their cards. So, Radeon would only be catching up if they make custom hardware on the motherboard handle IF interconnects between devices. The thing to note is that this requires off chip hardware on the motherboard or it requires a pinout like SLI to wire GPUs together. So, as their competitor (Nvidia) already has this implemented on motherboards/pinouts, none of this, if it occurs in Vega 20, is game changing. It is simply catching up.

That being said, neither Nvidia or Radeon is allowing for these features to be implemented or instantiated on consumer cards. Nvidia at least is clear w.r.t to what features are on which card... Right now, people are looking at Vega as a microarchitecture not understanding that a wealth of features are either hardware disabled or disabled in firmware/software.

TBQH : HSA exists today... You just have higher communication latencies and bandwidth restrictions. If neither Radeon/Nvidia can bother themselves to enable decade old features that pro cards have that cost pennies to implement on consumer cards or a 1 line change in firmware/drivers, I'm not sure it makes sense to flip over backwards thinking Vega20 is going to be the second coming. They're going to strip features out like they always do and you're going to get heavily neutered consumer cards.

BTW - I have a vega card on the way. I also have loads of Nvidia cards. If Vega 10 is a disappointment, if they strip features beyond what I deem acceptable, if the heavily discussed features turn out to be memes, I'll sell it quicker than I ordered it and you can forget about me ever buying another Radeon card.

 

[ub4ty]

There seems to be a lot of FUD around nVidia's equivalent to AMD's HBCC (iommu, copy engine, virtual addressing, paging).

The IOMMU and copy engine have been around since before Kepler (unified memory). *see edit below
What's new in Pascal is "49-bit virtual addressing and on-demand page migration"; nVidia's first implementation is Pascal: https://devblogs.nvidia.com/parallelforall/beyond-gpu-memory-limits-unified-memory-pascal/

It doesn't require any x86 license, because Pascal is not an x86 architecture.

Edit: Corrected error - IOMMU has been around since Kepler because that's when unified memory was implemented. Copy engine has been around forever for async data copies - at least Fermi, and possibly Tesla architecture.

Yeah, it seems the Radeon group takes a lot more artistic license with the way they market industry standard feature-sets especially in regard to their naming conventions and by the way they dont draw clear lines of distinction between pro/non pro card features.

For paging to work, OS support is necessary. See this Linux article: https://lwn.net/Articles/679300/
The term Linux uses for this technology is heterogeneous memory management, and it suggests page table formats don't follow the x86 standard on the device. It's also noteworthy to see nVidia, AMD, and Mellanox all on the same email chain; it suggests that HMM extension was developed collaboratively.

Underneath the surface of this communication is the fact that various companies are trying to maintain pro level pricing for old feature-sets that now have to become common and open source. All of what is detailed here, on this email, and generally under HSA already exists. Only, it exists behind high dollar pro level drivers/firmware and nickel/dime level asics. The timeline for this rolling out isn't restricted by some grand new developments, it's restricted by the various companies deciding they've had a long enough run on pro-level pricing for basic functionality that should have merged into common core hardware, firmware, drivers, and kernels. Funny how Linux Devs say they can enable it with a couple of If statements in their codebase but these manufs seem to be dragging arse on their end of the deal. Why the arse dragging? They're trying to maintain their pro-line margins for as long as they can.

RDMA/Async DMA engines/IOMMU/MMU/Dynamic paging have been around since the beginning of computing. Companies have just strung up arbitrary lines based on these features so they can charge insane amounts of money above consumer level hardware.
The arb is centered around :
Networking : $400 cables, $8,000 Nics (mellanox) - capable of doing RDMA at low latency
GPUs : Remote DMA (RDMA) / GPU direct communication
CPUs : Low latency high throughput internal bus access (take a wild guess as to why this has been delayed)

All of these features exists on pro hardware.. have for many years.. It's just locked behind firmware/drivers/software disables and purposely excluded asics that cost nickles/dimes on consumer hardware. The good thing is :
> if you're crafty enough, you can break down all of these artificial walls today
> Various companies are finally allowing decade old pro features (drivers/firmware) to become available on consumer hardware

 

[Guru]

Vega is so bad at gaming, that I don't see them continuing with it as a consumer product. They are probably going to keep the design for computing and stuff, but its a garbage card for gaming. Hot, big, power hungry and slow.

 

[eek2121]

Vega is so bad at gaming, that I don't see them continuing with it as a consumer product. They are probably going to keep the design for computing and stuff, but its a garbage card for gaming. Hot, big, power hungry and slow.

Stop trolling.

 

[HurleyBird]

Vega is so bad at gaming, that I don't see them continuing with it as a consumer product. They are probably going to keep the design for computing and stuff, but its a garbage card for gaming. Hot, big, power hungry and slow.

Depends how much of the disappointing performance is down to immature drivers, if there are any obvious issues or bottlenecks that can be fixed relatively easily, and how much the market adapts to Vega's new features.

Remember that, from an architectural perspective R600 was <<< G80 and derivatives, yet TeraScale was >>> Tesla (only failing to massively disrupt the market because AMD picked the most unfortunate time to abandon big dies), despite being heavily based on R600.

 

[DisEnchantment]

Videocardz have been spot on with the Vega leaks so far.

2018
- Vega 20 happens to have the xGMI IF which like in EPYC is use in Multi Socket communication across PCIe. With PCIe Gen4 maybe a possibility for this to be used to enable the dual GPUs to behave as a single GPU to the SW doing away with Crossfire which incidentally AMD is also keen to drop support in the future. Much higher DP FP with ECC. Looks tailored for Compute.
-
With Navi tapeout already planned for H2 2017, The likely candidates for Navi memory would have been set. HBM3 or GDDR6?

Seems these slides were on track to large extent after all in the light of AMD's CES Tech Day.

But .. the source code of AMD's drivers also give very nice hints.

https://cgit.freedesktop.org/~agd5f/linux/

Check change logs. Last year long before RR was released there were hints that it is not HBM2 have new IP like VCN etc...