New Upcoming ATI/AMD GPU's Thread: Leaks, Hopes & Aftermarket GPU's

That could because there not getting good yield right now out of new HBM2 or there just producing small quantities in short batch runs.
My guest is when more companies start making used of HBM2 or HBM3 the cost will go down

 

AMD Vega Dual GPU Liquid Cooled Graphics Card Spotted In Linux Drivers (LEAK)

A liquid cooled dual GPU Radeon RX Vega graphics card has been spotted in a brand new Linux driver released by AMD yesterday. Linux drivers have consistently proven to be an invaluable source of information regarding the company’s upcoming next generation Vega graphics products.
The just released update to the open-source Linux graphics driver stack contains some very revealing code pertaining to the company’s latest and greatest graphics chips.

First things first, let’s take a look at the code.

: table->Tliquid1Limit = cpu_to_le16(tdp_table->usTemperatureLimitLiquid1);

: table->Tliquid2Limit = cpu_to_le16(tdp_table->usTemperatureLimitLiquid2);

The two lines of code above have been added to AMD’s Linux open-source driver stack yesterday, alongside two brand new Vega device IDs.
The new Vega 10 IDs are 0x6864 and 0x6868 and seeing as how they’ve been added this close to launch the new IDs very likely pertain to actual finalized or near finalized Vega graphics boards.
Now, back to the dual GPU Vega board. Digging deeper into the Vega 10 power management and temperature sensor code reveals another gem.

: table->FanGainPlx = hwmgr->thermal_controller. advanceFanControlParameters.usFanGainPlx
: table->TplxLimit = cpu_to_le16(tdp_table->usTemperatureLimitPlx);

What you’re looking at is code specific to a PLX chip, found in the Vega 10 code stack. A PLX chip is an ASIC that splices PCIe lanes to bridge multiple components. They’re used in dual GPU graphics boards to connect the two graphics processors together and then drive that signal to the PCIe slot.

In other words, get ready for a brand new Radeon Pro Duo flagship graphics board from RTG. This time powered by the all new Vega 10 GPU. AMD is set to take the covers off Vega at an event on May 16th, less than a week from now.

Vega Architecture Key Features

– 2x Peak FP16 Throughput/Performance Per Clock
– 2x FP32 Performance/Watt, 4x FP16 Performance/Watt
– High Bandwidth Cache
– 2x Bandwidth per pin
– 8x Capacity Per stack (2nd Generation High Bandwidth Memory)
– 512TB Virtual Address Space
– Next Generation Compute Engine
– Next Generation Pixel Engine
– Next Generation Compute Unit optimized for higher clock speeds
– Rapid Packed Math
– Draw Stream Binning Rasterizer
– Primitive Shaders

===

So we can Have:

VEGA Duo
Big VEGA WC
Big VEGA Air x3/x2
VEGA Nano & VEGA Pro

New Tables in Guru3D Games Benchmarks?

1st VEGA Duo
2nd Big VEGA WC
then rest...

====UDP. some VEGA stuff=====

FreeSync 2, Chill, HDR, High Bandwidth Cache Controller, and Rapid Packed Math!

AMD has not long released their RX 4xx refresh with the RX 5xx series of graphics cards. That release saw all their new cards offing support for Radeon Chill, HDR, and FreeSync 2. Therefore, you can expect all these features and more to be a big part of Vega cards.
With FreeSync set to become the dominant standard due to its open-sourced nature, there’s certainly a few more things to look forward to with these new cards.

One of the most important changes is the new High Bandwidth Cache Controller. As you know, GPUs nearly always feature a VRAM cache to store their working data. However, the amount of memory available and the all important bandwidth are both limited; this is where the HBCC comes in. As a smart controller, it better optimises the VRAM to store only required materials and tosses out the useless ones.

It optimises the transfers to make the use of the limited bandwidth, which builds on top of early technology used with Fiji where AMD was able to stretch out the 4GB of HBM2 to match even 6GB or more Nvidia GPUs. Most importantly of all, AMD is claiming 50% improved AVG FPS and a doubling of the MIN FPS.

Rapid Packed Math allows Vega to switch on the fly from FP32 workload to FP16 workload. For features like hair, TressFX will now allow the use of FP16, effectively doubling performance relative to regular FP32, which allows for doubling of on-screen objects, in this case, hair. Since hair modelling doesn’t need to be 100% accurate in most cases, this should either reduce the impact of TressFX or allow for more hair.

Some slides there

Spoiler

https://www. e()teknix.com /amd-radeon-rx-vega-graphics-cards-what-we-know-so-far/

When is AMD Vega Released?

Firstly, AMD Vega is on track for a Q2 release in 2017, so this would line up with our current understanding that the hardware would be ready and revealed at Computex 2017, which runs from 30th of May to the 1st of June in Taiwan, and ******* will be there to catch the latest. Therefore, it means that we don’t have long to wait, and this would also mean a launch sometime shortly after the show in June or July.

“AMD’s “Vega” GPU architecture is on track to launch in Q2, and has been designed from scratch to address the most data- and visually-intensive next-generation workloads with key architecture advancements including a differentiated memory subsystem, next-generation geometry pipeline, new compute engine and a new pixel engine,” said AMD.

Recent rumours do suggest there will be supply issues at launch. This is most likely due to HBM2 manufacturing being difficult, and we expect production would improve, but big hardware changes like this often lead to this problem.

It’s also believed that we could see an event this month, on the 16th of May, revealing some new hardware.

“AMD will finally be disclosing more information about its next generation CPU & graphics architectures Vega, Navi and Zen+ in 10 days,” WCCFTech’s Khalid Moammer reports. “The company is set to unveil its long-term CPU & graphics roadmaps for 2017 and beyond in a little over a week, sources close to AMD have told us.”

How much will Vega Cost?

While it’s currently unknown exactly how much Vega cards will cost, we will update you as soon as we do. However, what we do know is that these will represent the best cards AMD has to offer. As a result, you can expect them to be priced to reflect that. Most important of all, will they be cheaper or more expensive than Nvidia options? We think they’ll be a little more affordable, at least going on what we’ve learnt from past launches.

 

Whilst i'm very wary of a dual GPU card, I am interested to see how it goes. Still waiting to see how game devs implement it into games in Vulcan and DX12. Hopefully they decide to give it the support it deserves and the past issues of SLI/Crossfire will be a thing of the past. Only then would I consider one for my PC.

 

Unless 3Dfx make a come back there no way on this god green earth would I touch Dual GPU or SLi or Crossfire they just a trouble maker LoL

 

The only way I would ever consider one would be if they were a CCC-like design and appeared as a single card.

 

Supposedly mGPU is a lot different to SLI/Crossfire. The Devs now code for individual engines and games. So in theory you could eliminate scaling and stutter issues that plague both Crossfire and SLI.

 

That would be the ideal situation. I am intrigued to see if game Devs do consider putting an effort into this. That will end up being the telling answer to if multi GPU has a future at all.

 

Silicon on silicon (like HBM) will be NaVi
Best Navi will have 4xGPU? on one board and it will count as one !

 

Really. Wow where did you read that.

 

Just my thoughts on so called scalability
And we have HBM + 2D & 3D Stacks going X-Y + Z
It's logical dear Watson

Now we have DX12 & Vulcan, thx to that we have 2,3 etc. GPUs count as one...

 

I'm just speculating here so don't take this as anything serious.

Given that Navi's tagline is next-gen memory and that Vega's had a lot of focus on it's memory controller and scheduler, it could be reasonable to imagine if AMD are going to go multiple GPU route that AMD might come to develop a highly advanced memory controller and schedular which could dynamically use multiple GPUs without the need to copy the vram across each GPU.

 

I would imagine using the hbm as a cache like amd has stated would make it much easier to implement a dynamic multigpu Tiled frame rendering solution which wouldn't have many of the problems associated with AFR and scale lot better than SFR (would look something like this)

 

AMD can still develop thin (in number of lanes) high clocked interconnect between certain parts of GPU. And simply build one GPU made of several smaller silicons (each would not work by itself) connected by this method.

And maybe Infinity Fabric is actually step towards this as AMD seems to be able to stretch it as much as they need to.

Tile based renderers have only one problem and that is rendering pipeline composition. Today, there is a lot of information which has to be available for entire frame before next phase of rendering can begin and at the end you have often additional passes of post processing. If engine uses pre-rendering for several frames that wait times would be reduced, but still there will be much higher loss of computation time than if AFR was used.
PowerVR is still giving it some resources, but mostly by using additional workloads which are well efficient with tiled rendering (like reflection raytracing).

 

I would think that the HBM cache idea would be great for mGPU.
With any multi gpu setup, one would be controlling the output, and stuff, and possibly farming out the work to the extra gpu(s), whilst then doing some of the work as well.
It could reserve some of its HBM for a cache, or for a lookup table for the other gpu(s) Memory, so it could access it directly, without having to copy it.

edit : AMD's current memory controller is pretty intelligent, so i don't think it would be impossible. Much better for Single card mGPU though.

 

This is true, I suppose the real question now is how extensive are the High bandwidth cache controller's capabilites,whether or not it can access another gpus memory, and fast enough to make it more feasible.

 

High Bandwidth Cache Controller is not miracle. Its effect in true multi-gpu memory access will be very small. It is basically replacement of IMC used in Fiji (because that was usual IMC adapted to HBM and did not have many optimizations). Its main benefit is that it can load much smaller chunk of data and therefore it does not waste as much bandwidth as before + Additional Cache exclusively used by it. Another Vega change is that everything what needs to use a lot of memory is now going not only through its L1, but all those things share L2 (before, some bandwidth hungry parts had no access to L2 and went directly to IMC => wasting bandwidth).
That's actually reason why AMD can claim that in worst case scenarios when previous GPUs choked on any kind of bandwidth, new ones will potentially double those minimum FPS.
= = = =
To multi chip solutions:
I more of think about connection between GPUs by Infinity Fabric. I do not know any details of it, if it consists of 256 or 512 lanes. But 2 silicons on interposer or above each other can be connected by it to effectively create one physical GPU.

Here I cook from Water:
I imagine it as Central part of GPU: Command Processor, ACEs, HBCC + HBC, L2, Display Controller would be on central silicon.
Then Infinity Fabric around to connect other silicons which would consists of exactly one Shader Engine: Geometry Processor, Rasterizer, 4x RB, 16x NCU, L1

Pretty much extensible to infinity (performance limited by number of ACEs in central silicon and actual physical extensibility by interposer size).
Only issue would be that signaling may potentially limit clock. But considering clock at which Infinity Fabric ticks in CPU, I think it is quite safe to consider it as non-limiting factor.

 

the imc in vega can already access ssd cache onboard, its not a big stretch to allow it to access other, onboard, gpus memory?
with a penalty, but how big ?
im thinking pro-duo/pro-quadro here, not over pcie
edit: well, maybe over an onboard pcie switch.

 

I agree with you.
I see the biggest problem for multi gpu being latency/synchronization and if the hbcc simplifies and reduces latency for cross gpu talk, it would help a fair bit thats all I was getting at.
No miracles lmao.

The main reason I think amd may be going the route of tiled rendering is that the ps4 pro implements specialised hw to reduce the performance impact of checkerboard rendering(one of the post-polaris features it has).

 

Infinity Fabric on Ryzen has basically the bandwidth of the memory controller. If we apply the same principle with an HBM GPU, the latency issues would be minimized. I guess that they could do exactly as they're doing with Ryzen, and in the way you mentioned. A "GXC" could be 1024 shader engines, and the "big" command processor and the memory controller can be part of the fabric, and not of the "GXC". You could then basically scale those GXCs as much as you would like. In the end, it's either that or 810mm2 chips when NVIDIA themselves admit that they'll have to go through multiple wafers just to get one functioning.

 

https://compubench.com/device.jsp?benchmark=compu20d&os=Windows&api=cl&D=AMD+6864:00&testgroup=info

Here we have a 1600mhz 16gb hbm2 Vega then hooray?