Because so many different video cards are made from a handful of chip designs, there is a group of people who like to see whether a lower-end SKU can be unlocked to behave like a higher-end one. In this case, kdtree on the ChipHell forums has apparently flashed the new AMD RX Vega 56 with the vBIOS from an AMD RX Vega 64. Personally, I would find that a little sketchy, given the difference in stream processor count, but they’re the one with the graphics card.
Image Credit: kdtree from ChipHell forums
Turns out, it did something, but it did not magically create an RX Vega 64. The extra 512 shaders are probably disabled at the hardware level, such as with a laser. Your first reaction is probably “well, of course it is…” but, if you remember Polaris, users have software-modified 4GB cards into 8GB cards… so there is some precedence for “maybe AMD put more on the card than they said on the box”.
Oh right, so what did it do? It apparently gave the card a significant overclock. It’s hard to tell under the watermark, but the modified Vega 56 was just a percent or so away from the Vega 64 on 3DMark. I’m guessing a conventional overclock might do the same, but who knows.
AMD/ATI have a long history
AMD/ATI have a long history of being able to use modded BIOSes to unlock lower end cards to higher end ones based on the same GPU. I can remember at least all the way back to the Radeon 9500 being able to be unlocked into a 9700. It doesn’t always work on all cards, as yes sometimes they are lasered, but with some gens some of the early chips were not lasered, only locked out with a bios. (Heck, with the 9500->9700 you could do it with modded drivers, didn’t even need to flash the card) So, I wonder if all the Vega 56’s are lasered off, or just some of them. On another note, it’s sad that you can’t freely mod Radeon BIOSes anymore as I have pretty much always ran at least custom fan profiles and such on my cards.
Look at the RX Vega 64’s ROP
Look at the RX Vega 64’s ROP count at 64 ROPs and now look at the RX Vega 56’s count at the same 64 ROPs and its not hard to figure out that the RX Vega 56 is going to be able to get close to the RX Vega 64 in gaming benchmarks. The RX Vega 56 is damn near the same TMU counts also with the RX Vega 64 having 256 TMUs while the RX Vega 56’s TMU count is 224 a difference of 32 TMUs.
The only major difference between the Vega 56 and Vega 64 is shader counts 3584 to 4096 respectively. And look at the GTX 1080’s ROP/TMU counts at 64/160 and the RX Vega 56 is around that in ROPs(64) and higher in TMUs(224) than the the GTX 1080. So Vega 56 is nearer to the GTX 1080 in the gaming resources parts of the GPU micro-arch. Vega 56 still has an excess of compute relative to the GTX 1080 so maybe with some higher clocks Vega 56 can get closer to the to the GTX 1080 than Vega 64 will ever be able to get to the GTX 1080ti with its 88 to 64 ROP unit count advantage over Vega 64.
All of Nvidia’s TMU counts are low relative to Vega’s with even the GTX 1080Ti having 224 TMUs(same as Vega 56’s TMU count) and its those 88 ROPs in the GTX 1080Ti that put it ahead in the Pixel rates 139.2 GPixel/s compared to the RX Vega 64’s Pixel rate of only 98.94 GPixel/s.
The Titan XP is the only Nvidia SKUs with a TMU count nearer to Vega’s at 240 TMUs for the XP with the Titan XP having even more ROPs at 96 so is no wonder why the frame rates can be higher on the Nvidia flagship GTX 1080TI and Titan XP SKUs, look at those ROP counts.
Vega 10 is most definitely a compute heavy GPU micro-arch design variant and maybe there is room for AMD to maybe trim some more compute from the Vega 10 die and get the overclocks higher and keep the power usage down to better compete on the power usage metric against Nvidia.
There is still rumors that not all of the Vega micro-arch features are fully enabled/optimized in the Vega driver software so there will be more improvments ahead for Vega. There is still no great usage of Vega’s HBCC IP by any games developers and the same is true for that rapid packed 16 bit math in games for now. So Vega’s full feature set is not yet taken advantage of in games/gaming engines currently. The current DX12/Vulkan API conversion/optimization process is not completed either so that’s still a work in progress across the entire gaming industry.
Vega 10 is also a Compute GPU micro-arch to compete with GP100, GP102 in addition to GP 104(See Raja’s Tweets)! So look for some interesting dual Vega SKUs that will use the Infinity Fabric to wire-up dual Vega dies on one PCIe card in a manner similar to the way Epyc’s 4 Zeppelin dies are interfaced on the MCM to function as one logical CPU. That Infinity fabric interfacing ability used for Dual Vega GPU dies is not going to be like any of AMD’s past dual GPU/one PCIe card solutions that suffered from inefficient scaling issues.
“There is still no great
“There is still no great usage of Vega’s HBCC IP by any games developers ”
This is because the function it exposes is something developers have already been doing as standard for many years. The default behaviour for any recent game engine is to cache as many assets as you have into vRAM until you either run out of vRAM or run out of assets. Cached assets get overwritted with active buffers if required. If something cache-misses, it gets loaded from system memory or backing store.
HBCC will not make this any faster. It might make it easier to implement, but with the big caveat that it is a vendor-specific extension. If you already have a working implementation that is cross-platform, why would you ever consider implementing a vendor-specific version that gains you nothing?
That’s a programmer/software
That’s a programmer/software managed caching while Vega’s HBCC IP will put that under the control of hardware and free up the programmers from the often times inefficent task of managing the VRAM caching in the game’s software.
With Vega’s HBCC all that management headache is moved into the GPU’s HBCC/Memory controller with games/gamimg egines simply asking for more VRAM and Vega’s HBCC/HBC-HBM2 IP doing the VRAM virtualization management in the GPU’s hardware.
And what is vendor specifc about any CPU/GPU virtual memory hardware/cache based management solutions for CPUs or GPUs as that is all abstracted away in the hardware/dirvers/firmware/OSs with the programmers able to ask for more VRAM via the DX12/Vulkan/other API calls. You are really not a programmer are you, because what is the difference between Vega’s Virtual Memory in the GPU’s hardware and a CPU’s similar functionality that’s been around for ages.
The Bog Standard gaming script kiddys will not have to worry as their little hands are already held by the gaming engines/games SDKs with some help from the non systems programmers and the systems prgrammers who developed the gaming engines. And Any systems/gaming engine programmers are already jumping for joy at Vega’s HBCC/HBC-HBM2 and virtual VRAM memory managed by Vega’s hardware! And they are saying to themselves that is about time that GPU acquired that ability in their hardware that CPU’s/APUs/SOCs have had for a good long while.
Why are you not complaining about AMD’s x86 CPU virtual memory maagement and Intel’s x86 based virtual memory management being a little different under the hood when every real progeammer knows that any differences in the AMD/Intel CPU virtual memory subsystens are abstracted away at the hardware/firmware/driver and OS level so the programmers do not have to worry about the messy details, and that’s no different for Vega’s hardware/driver/firmware abstraction layers with respect to programmers not seeing or having to worry about what happens at the lower levels to make things work.
The non gaming graphics software will definitely be shifting over to taking advantage of Vega’s HBCC, and so will the games via the gaming engines in relatively short
order. And any Vega Discrete Mobile SKU will really be inline for taking advantage of Vega’s HBCC/HBC-HBM2-cache as they will be coming with many 2GB-4GB of VRAM, so Vega’s HBCC/HBC IP will really shine for discrete mobile Vega SKUs!
This is not the first time that you have tried to spin things using that same flawed logic, and really you are being disingenuous at this point because you can not possibly be that daft.
Thanks for taking time to
Thanks for taking time to enlighten us.
re:”That’s a programmer/software managed caching while Vega’s HBCC IP will put that under the control of hardware and free up the programmers from the often times inefficent task of managing the VRAM caching in the game’s software.”
Yes, the steps programmers must take to manually juggle cache are very laborious afaik.
separately, would the hbcc act as a kind of cache co-processor – accellerate the caching vs alternatives?
whats most exciting to me is the managed, layered cache resources pool.
vega can have; vram, system ram, onboard nvme arrays, system nvme arrays…, and is able to learn patterns of usage & pre-emptively juggle priority cached data to faster cache resources.
So we shouldnt take too much notice of raw speeds of cache pool resources like nvme arrays vs vram, as in theory, hbcc should ensure all reads e.g. are from the fastest resource in the pool.
This is very relevant i think u would agree, when considering fast nvme arrays as gpu cache extenders. Amd claim using spare system memory as hbcc vega cache, the vega card emulates 2-3x the the hbm2 actually installd, w/o apparent perf loss, and vnvme arrays now approach the speeds of system memory to the gpu via the pcie bus.