AMD Vega Hardware Reviews

[3dilettante]

AMD's sights are set higher than page fault handling, at least for non-gaming models. The controller and page management has to carry across multiple memory types, such as the SSD model, system paging, and possibly remote memory pools.
The disparate latencies, access patterns, and possibly endurance are part of AMD's research into managing replacement and migrating between tiers.

Gaming's limited use case would fall readily out of that.

 

[silent_guy]

HBCC should just work. It's just a 4K page faulting mechanism from what I've seen.

It may be just that from a HW point of view (if so, why the big deal? Is it any different than virtual memory on Pascal?), but can that be transparently integrated into, say, a DX driver that may not have that kind of support?

 

[CarstenS]

It may be just that from a HW point of view (if so, why the big deal? Is it any different than virtual memory on Pascal?), but can that be transparently integrated into, say, a DX driver that may not have that kind of support?

„Pascal is still running on a maxwell driver path“.

 

[Anarchist4000]

It may be just that from a HW point of view (if so, why the big deal? Is it any different than virtual memory on Pascal?), but can that be transparently integrated into, say, a DX driver that may not have that kind of support?

The big deal "should" be that Vega is passing all memory pointers through a virtual page table on par with a CPU without having to interrupt the CPU. In the case of Volta, page counters were mentioned. So beyond paging in data, it should be able to evict data efficiently and likely with better granularity. Really need a better idea what the definition of "page" means. Migration is easy, evicting and managing would be another question. It remains to be seen what kind of stalls these accesses may trigger.

 

[pharma]

Don't remember this being on the Vega Frontier Product web page.

DRIVER DOWNLOAD
Unlock the full potential of the Radeon™ Vega Frontier Edition with Radeon™ Pro Software
The Radeon™ Vega Frontier Edition is designed to empower Pioneers. Those who are not afraid to lead. To properly enable you, we are providing more driver options than ever before. You can choose between compute specific drivers for ROCm, and graphics drivers that allow you to both create using Radeon™ Pro workstation capabilities and game.

• I Am Focused on Compute Workloads
  The ROCm driver will be available for users on June 29th.
• I Am Focused on Workstation Workloads
  If you are a workstation user on a Windows® platform, get your driver here.
  If you are a workstation user on a Linux® platform, get your driver here.
• I Am Focused on Game Development Workloads
  Radeon™ Vega Frontier Edition introduces “Gaming Mode”. This allows you to switch from Radeon™ Pro Settings to Radeon™ Settings where you can access gaming features for playtesting and performance optimization.
  If you are focused on game development on a Windows® platform, get your driver here and switch to “Gaming Mode.”
• I Just Want to Game
  If you want to game on a Windows® platform, get your driver here and switch to “Gaming Mode.”

https://pro.radeon.com/en-us/product/radeon-vega-frontier-edition/

 

[Kaotik]

Don't remember this being on the Vega Frontier Product web page.

https://pro.radeon.com/en-us/product/radeon-vega-frontier-edition/

It's been there since launch I think?
Regardless, all the Windows-links direct to one and same driver.

 

[Malo]

It's been there since launch I think?
Regardless, all the Windows-links direct to one and same driver.

Yep definitely all there since day 1 of FE launch.

 

[CarstenS]

I think, he might have referred to this:
„Unlock the full potential of the Radeon™ Vega Frontier Edition with Radeon™ Pro Software“

 

[Kaotik]

I think, he might have referred to this:
„Unlock the full potential of the Radeon™ Vega Frontier Edition with Radeon™ Pro Software“

The whole shebang has been there the whole time, and Radeon Pro Software is the default mode for the drivers (which are just one and the same set anyway)

 

[CarstenS]

The whole shebang has been there the whole time, and Radeon Pro Software is the default mode for the drivers (which are just one and the same set anyway)

Yet it says „unlock the full potential“, not „use it in Fiji-Fallback mode for the time being“.

 

[Alexko]

What bugs me is that (as far as I understand) Vega's ISA is different from Fiji's or Polaris's, which means that it should at least have a new shader compiler to even work at all. And yet, I don't really see any clear indication that it benefits from it, even though nCUs are supposed to have higher IPC. Could that be contingent upon the proper function of new front-end features?

 

[Kaotik]

Yet it says „unlock the full potential“, not „use it in Fiji-Fallback mode for the time being“.

Would any company ever say that even if true?

 

[CarstenS]

Would any company ever say that even if true?

They would not state the opposite of what it says there, but the line being there clearly implies, that the driver is not seen by AMD as something barely functioning and in dire need of an update.

What bugs me is that (as far as I understand) Vega's ISA is different from Fiji's or Polaris's, which means that it should at least have a new shader compiler to even work at all. And yet, I don't really see any clear indication that it benefits from it, even though nCUs are supposed to have higher IPC. Could that be contingent upon the proper function of new front-end features?

The nCUs have a (at least) 2× higher IPC. They can do quad-rate INT8 whereas earlier ones could do a maximum of double-rate FP16.

 

[AnomalousEntity]

I don't think PC games use INT8, or even FP16 math much in their shaders. So the gains to be had from this IPC improvement would be pretty small. It's mainly for compute and machine learning. The only way to get more FP32 ALU thoughput now is to either have more shader cores or increase the clock frequency. Although a new shader compiler with a new arch can improve many things like better packing of instructions and reduced branch penalty but then again with new arch software (driver/compiler) needs more time to mature. Especially TBDR architectures rely heavily on drivers to create dependencies between render-targets and caching/flushing intermediate tiles.

 

[Alexko]

I think a lot of developers, @sebbbi included, would argue that FP16 does have a good deal of value for shaders—I don't really know about INT8.

But I was thinking about "standard" FP32. Unless AMD was being misleading when they claimed IPC improvements, that was for FP32 code. Yet I don't see that improvement at this point.

 

[Geeforcer]

http://www.pcgameshardware.de/AMD-Radeon-Grafikkarte-255597/Specials/Vega-10-HBM2-GTX-1080-1215734/
There's one, it should be mentioned more or less directly in all articles about the AMD's Doom-demos at Tech Summit last December

I would guess it comes mostly down to similar configuration units wise in the GPU and HBM-memory controllers oppose why "fiji-based" rather than "polaris-based"

edit: and here's the reddit post suggesting Fiji-drivers
edit: ffs autoparsing all the reddit links
reddit.com /r/Amd/comments/6kdwea/vega_fe_doesnt_seem_to_be_doing_tiled/

Thanks for the links. It's hard for me to imagine that AMD would have not put significant resources into developing software for the new architecture to ship with the product. Shipping something largely non-functioning is not only a slap in the face of the paying customers but also contradicts the cards stated purpose.

As for the reddit post, I personally don't recall there being any sort of flurry of software patches associated with Maxwell's TBR rasterizer... in fact the whole thing was so seemless it took specialized tool to even prove it was there.

 

[Love_In_Rio]

Maybe tiling is broken in the FE silicon and thats why RX Vega is late, maybe there has been a chip fix/reespin?.
Would be a logical explanation for marketing silence (i dont buy if it was drivers they couldnt comment on it as FE owners would end up taking advantage of them also).This, or the chip is really bad of course.

 

[CarstenS]

But I was thinking about "standard" FP32. Unless AMD was being misleading when they claimed IPC improvements, that was for FP32 code. Yet I don't see that improvement at this point.

It was exactly this slide, where they even showed the multiple issue of FP16/INT8 ops:
http://www.pcgameshardware.de/Vega-...NCU-HBCC-Vorstellung-1217460/galerie/2685977/
As far as bulletin points go, I do not think this is more misleading than any other marketing slide. The asterisk pointing at the endnotes only leads to a remark that a CU and an NCU consist of 64 shader and that Radeon/Fire Pro employ multiple CUs.

 

[3dilettante]

The nCUs have a (at least) 2× higher IPC. They can do quad-rate INT8 whereas earlier ones could do a maximum of double-rate FP16.

In terms of IPC, there is one I for a packed Instruction, unless we want to say the addition of 8-bit packed instructions to x86 caused CPUs to get 8x the IPC.
If that is what AMD meant in that IPC slide, then it is misleading given the general usage.

 

[CarstenS]

I don't follow?