Alongside the big Radeon Software Crimson ReLive 17.7.2 release, AMD pushed out a new developer tool to profile performance on AMD GPUs. First and foremost, it’s only designed to work with the newer graphics APIs, DirectX 12 and Vulkan, although it supports many operating systems: Windows 7, Windows 10, and Linux (Ubuntu 16.04). It doesn’t (yet) support Vega, so you will need to have a 400-, 500-, or Fury series GPU. I expect that will change in the near future, though.
So what does it do? These new graphics APIs are low-level, and there’s a lot going on within a single frame. Other tools exist to debug thing like “which draw call is painting a white blotch over part of my frame”, with AMD recommending RenderDoc. Radeon GPU Profiler is more for things like “did I feed my GPU enough tasks to mask global memory access latency?” or “what draw call took the longest to process?” Now that a lot of this is in the hands of game developers, AMD wants them to have the tools to efficiently load their GPUs.
While the software is freely available, it’s not open source. (You will see a “Source code” link in the release section of GitHub, but it’s just a Readme.)
I want to see this for Vega
I want to see this for Vega when it arrives to see if the Vega enabled profiler can map out the movement of any textures/mesh/other/data stored in regular system DRAM, or even paged SSD/Hard-drive VM swap file memory, as it is moved into the HBM2/HBC by Vega’s HBCC. Vega’s new HBCC/HBC/HBM2 features/IP are very different from any of AMD’s previous GPU micro-archs.
AMD advertised that even for Vega GPUs with small amounts of HBM2, that Vega’s HBCC, HBC/HBM2 would allow even those Vega SKUs with say 4GB or less of HBM2 to leverage system DRAM and even SSD/Hard-drive paged memory for Texture/Mesh/Other data stores allowing the games to utilize larger than 4GB VRAM and have the HBCC manage the movement of those secondary levels of texture/mesh/other data stores movement into and out of the HBM2/HBC.
So for laptop with a discrete mobile Vega SKU that HBCC/HBC/HBM2 combination can manage large amounts of textures/mesh/other data that may be larger than the Vega based discrete mobile GPUs HBM2 video-RAM size.
AMD demonstrated this in one of their previous Vega showings some months back by taking a desktop Vega Engineering Sample and reducing its HBM2 size in the Firmware/Driver software and gaming with the reduced HBM2 with little adverse reduction of gaming performance on the the games being played.
So for discrete mobile Vega SKUs that HBCC HBC/HBM2 IP is going to benefit laptop gaming more so than for desktop gaming GPU SKUs which usually have larger video RAM allotments.
All this new Vega HBCC/HBC/HBM2 IP is there to allow the Vega NCUs/TMUs/ROP/etc. to mostly work more efficiently from the HBM2/HBC VRAM while Vega’s HBCC manages that data movenment in the background more effenciently with little extra programmatic effort required from games developers.
Yep, HBCC the most exciting
Yep, HBCC the most exciting thing about vega, & it barely gets heard over the shrill shills tales of gaming woes.
Totally exciting I agree.
Totally exciting I agree.
More broadly, another answer to why we are perennially short of premium memory is that we are so wasteful of it.
As you say, if Fabric & hbcc work as intended, we can all get by with less & lesser ram with the help of nvme.
AMD are placing a focus on prefetch & tiered levels of cache, much as a cpu does, into L1, L2, L3 etc., & adding an L4, 5, & 6 so to speak, and hbcc is the dedicated processor to manage these disparate cache resources.
Its particularly exciting for apuS, as the slow and dumb legacy pci bus link for processors and cache can be bypassed by infinity fabric.
Profiling GPUs is an act of
Profiling GPUs is an act of siliconism.
That is so PC of you to say.
That is so PC of you to say.
At least it will operate
At least it will operate within its safe-space.
U r so right. What happens in
U r so right. What happens in vega should stay in vega.
What is the GPU?
Formed from
What is the GPU?
Formed from the Cheka, the original Russian state security organization, on February 6, 1922, it was initially known under the Russian abbreviation GPU—short for “State Political Directorate under the NKVD