Vega/Navi Rumors (Updated)

[zinfamous]

Didn't Raja state explicitly in the AMA that there was no need for developer effort to make full use of Vega?

Not all features, but some will absolutely require developer effort, and he explicitly mentioned this about one or two of those features, after talking about it...I honestly forget which ones but 100% certain he said this in some of the quoted information or links here over the last week. But I have so far come away with the impression that there will be less developer intervention needed to fully exploit Vega than I previously assumed there would be.

And after yesterdays comments, putting together these two points:

--Previous game demos were of Vega Frontier
--RX Vega will be faster, and cheaper

Makes me happy. I'm only disappointed in the as-yet-unknown revised timeframe. And yeah...no BS about "AMD never explicitly said RX Vega would be alter than Q2!" They never really squashed what was very much assumed by their claims, either. I understand delays and all that, and whatever they have internally going on that they can't make explicit announcements, but it is frustrating to get no real info for so long. I think more than anything else, this probably due to HBM delays to a small degree, but very much due to optimizing RX Vega drivers with the small teams that they have to work with. It could also be that Su moved the release schedule around from an earlier timetable, to get the high end, high margin parts out first to exploit a segment that nVidia can't actually compete in right now, with Vega FE. Shocking that seems to be the case, but I think that is what they realized any may have pivoted resources away from RX. (Or Vega itself was always "Industry first," and their overall GPU strategy of midrange/low end marketshare first was 100% met with Polaris)

 

[Malogeek]

I honestly forget which ones but 100% certain he said this in some of the quoted information or links here over the last week.

Primitive Shaders is one of those.

 

[Elixer]

It's not just going to be drivers, because they've let "Pro" users use either the Pro or the "Gaming" drivers.

I'm guessing it's going to be higher clocked 8GB cards vs lower clocked 16 "Pro" versions.

Don't think the clocking will be the only difference.
Pro should have some kind of ECC & Hardware virtualization. I am guessing this needs to be enabled in the firmware.

Since there almost always is a performance penalty for enabling ECC, that is where another difference could be.

 

[CatMerc]

Primitive Shaders is one of those.

He mentioned those WON'T require developer effort.

 

[Malogeek]

He mentioned those WON'T require developer effort.

Then I stand corrected if that is the case. Everything I had read over the last few months indicated it could be something developers can utilize but would require working with them specifically. It's probably somewhere in the middle

 

[Glo.]

He mentioned those WON'T require developer effort.

The engines have to be redeveloped to use the features. In current state, you will not be able to use those features. Two parts of Raja's statements:

And some of Vega’s features, like our High Bandwidth Cache Controller, HBM2, Rapid-Packed Math, or the new geometry pipeline, have the potential to really break new ground and fundamentally improve game development. These aren’t things that can be mastered overnight. It takes time for developers to adapt and adopt new techniques that make your gaming experience better than ever. We believe those experiences are worth waiting for and shouldn’t be rushed out the door. We’re working as hard as we can to bring you Radeon RX Vega.

So you need to develop methods that utilize those features.

Second one:

The new geometry pipeline in Vega was designed for higher throughput per clock cycle, through a combination of better load balancing between the engines and new primitive shaders for faster culling. As a programmer you shouldn’t need to do anything special to take advantage of these improvements, but you’re most likely to see the effects when rendering geometrically complex scenes that can really push the capabilities of the hardware.

 

[CatMerc]

The engines have to be redeveloped to use the features. In current state, you will not be able to use those features. Two parts of Raja's statements:

So you need to develop methods that utilize those features.

Second one:

He means that in order to fully take advantage of what those features allow, you need to change how you do things. So for example you can use more high resolution textures and have higher draw distances with HBCC. It will benefit you regardless, but the real good things happen when you actually work with these features.

As for the geometry pipeline, you can use more geometry packed scenes, as what isn't visible will be culled away.

RPM is the only feature that I'm fairly certain only gives a benefit when actually used by devs.

 

[Mopetar]

RPM is the only feature that I'm fairly certain only gives a benefit when actually used by devs.

That one doesn't seem particularly difficult to implement though. Just figure out what can be done fine with 16-bit floating points and have it conditionally do that if using Vega and default to FP32 for everything else. The only real difficulty comes in knowing when and when not to use FP16. Depending on the game it could be negligible or a solid performance bump.

 

[geoxile]

The engines have to be redeveloped to use the features. In current state, you will not be able to use those features. Two parts of Raja's statements:

So you need to develop methods that utilize those features.

Second one:

At least in the case of the new geometry improvements, it sounds like he's saying Vega's geometry engines should give improvements with the way existing game (engines) are already designed. What I inferred from that is that the feature implementations are handled by the drivers and shouldn't require low-level hardware-specific tricks to utilize.

 

[Valantar]

That one doesn't seem particularly difficult to implement though. Just figure out what can be done fine with 16-bit floating points and have it conditionally do that if using Vega and default to FP32 for everything else. The only real difficulty comes in knowing when and when not to use FP16. Depending on the game it could be negligible or a solid performance bump.

Now I don't know anything at all about game development, but that doesn't sound like a trivial task to me.

 

[T1beriu]

HBCC needs developer support, it's not plug & play.

Well, I don't think HBCC needs any SW modification (driver only)

We had a demonstration of HBCC on DE:MD at February and now on RotTR. Have been those games modified? I quess not.

I think not as well, but special circumstances (2GB VRAM limit) have been created to show its use.

You misunderstood him. It will have a benefit regardless

Why put a VRAM constraint on RotTR if it will have regardless benefits?

That's what Raja said in this interview.

Have I misunderstood him again?

Some of Vega’s features, like our High Bandwidth Cache Controller, HBM2, Rapid-Packed Math, or the new geometry pipeline, have the potential to really break new ground and fundamentally improve game development. These aren’t things that can be mastered overnight. It takes time for developers to adapt and adopt new techniques that make your gaming experience better than ever.

Source: We are Radeon Technologies Group at AMD AMA

LE: CatMerc, just saw your answer.

 

[Mopetar]

Now I don't know anything at all about game development, but that doesn't sound like a trivial task to me.

I haven't done any game development specifically, but from a general coding perspective it's not difficult to use one type instead of another. The only catch is knowing when 16-bit floating point math won't be sufficient, which I expect developers have a better understanding of. The only reason to use FP32 everywhere is that FP16 couldn't be run any faster.

If they're lazy, just code anything not needing the added precision as FP16 and if the GPU doesn't have RPM-like features it will just get run automatically on the 32-bit hardware.

 

[Valantar]

I haven't done any game development specifically, but from a general coding perspective it's not difficult to use one type instead of another. The only catch is knowing when 16-bit floating point math won't be sufficient, which I expect developers have a better understanding of. The only reason to use FP32 everywhere is that FP16 couldn't be run any faster.

If they're lazy, just code anything not needing the added precision as FP16 and if the GPU doesn't have RPM-like features it will just get run automatically on the 32-bit hardware.

Doesn't switching to fp16 entail a drop in visual quality due to the lower precision of the calculations? I suppose it wouldn't be visible in quite a few cases, but wouldn't that essentially require developers to go over pretty much every situation in which fp32 calculations are used significantly and check if fp16 would be sufficient in that specific scenario? I get that the implementation itself might not be a huge undertaking, but the process seems long and slow for me. Of course, your 'lazy' approach avoids this.

 

[richaron]

Doesn't switching to fp16 entail a drop in visual quality due to the lower precision of the calculations? I suppose it wouldn't be visible in quite a few cases, but wouldn't that essentially require developers to go over pretty much every situation in which fp32 calculations are used significantly and check if fp16 would be sufficient in that specific scenario? I get that the implementation itself might not be a huge undertaking, but the process seems long and slow for me. Of course, your 'lazy' approach avoids this.

No. In many cases a calculation is suited to floating point maths, but not all of these require "precise" FP maths. Hence why double precision (64b) is kept up the sleeve for "pro" cards, and up until now the plebs were stuck with single precision (32b). But single precision is still more precise than needed for many tasks, like physics and lighting in game.

So now 16b, half precision, is now an important thing. Actually very useful for on-the-fly pretty effects in a game that can run twice as fast as indistinguishable 32b effects. And half precision is apparently useful for other sciencey stuff also.

Edit: Like most things in life the implementation of fp16 should be trivial for people intimate with the low level functioning of the engine. Of course most game "Dev's" are spending their time modeling maps and characters, working on textures, or tweaking gameplay and the UI. But I don't think that should be an argument against the implementation of fp16.

 

[Valantar]

*snip*

Very informative post, thanks!

 

[Mopetar]

Doesn't switching to fp16 entail a drop in visual quality due to the lower precision of the calculations?

You wouldn't use it for everything, but for some effects it doesn't matter. If you're doing some particle emission for sparks, small explosions, and other localized stuff, then it's probably fine to switch to FP16. Even if the lack of precision did produce noticeably different results than if 32-bit floating point operations were used, they might not be any worse, just different. If a game has a lot of effects like that, using FP16 would allow them to theoretically have twice as many in the same time frame.

I don't think it's going to lead to massively higher average frame rates as there are likely other limiting factors in the frame rate. What I expect is that it probably increases minimum frame rates or prevents sudden frame time spikes if there are a lot of effects happening suddenly all at once.

 

[Ajay]

Edit: Like most things in life the implementation of fp16 should be trivial for people intimate with the low level functioning of the engine. Of course most game "Dev's" are spending their time modeling maps and characters, working on textures, or tweaking gameplay and the UI. But I don't think that should be an argument against the implementation of fp16.

It won't be 'trivial' because it's just not a matter of refactoring. This would require using more mixed types in the code. In some number of cases, getting a benefit out of it may require alteration of an algorithm to get the highest performance. PITA. Not a problem writing a new engine, that's a different ball game.

 

[Kenmitch]

I'm not into the software side of things and don't really know anything about coding.

Stepping outside the gaming arena fp16 performance carries a premium it looks like.

As for why NVIDIA would want to make FP16 performance so slow on Pascal GeForce parts, I strongly suspect that the Maxwell 2 based GTX Titan X sold too well with compute users over the past 12 months, and that this is NVIDIA’s reaction to that event. GTX Titan X’s FP16 and FP32 performance was (per-clock) identical its Tesla equivalent, the Tesla M40, and furthermore both cards shipped with 12GB of VRAM. This meant that other than Tesla-specific features such as drivers and support, there was little separating the two cards.

article http://www.anandtech.com/show/10325/the-nvidia-geforce-gtx-1080-and-1070-founders-edition-review/5

Is AMD going after this market?

Seems like with software support AMD could somewhat cut off nvidia's gravy train.

 

[IllogicalGlory]

Why put a VRAM constraint on RotTR if it will have regardless benefits?

I don't think the benefits will be that noticeable unless you're VRAM limited. Hopefully there will be benefits (even 10% higher minimums than without would be good), but it's clear that with ample memory the benefit isn't enough for a demo. That doesn't mean that it isn't working subtly in the background in a wide range of situations.

 

[Glo.]

Just a thought. What if AMD delayed RX Vega architecture based GPUs to this year, because of HDMI 2.1 Spec release in Q2 2017?

It allows for 4K@120 Hz and 8K@Hz with HDR, both with HDR.

 

[Krteq]

I don't think so. Display controller block is a part of GPU and it can't be modified so easily... but you can add functionality by driver (like in case of DP).

 

[zlatan]

He mentioned those WON'T require developer effort.

Some will need, some will not.

HBCC won't need developer effort on a legacy API, and may not need on an explicit API, but in D3D12/Vulkan this is highly depends on how the application works.

Primitive shader will need a lot of developer effort, because the main reason to use it is to create a fully custom graphics pipeline.

The new geometry pipeline and the new rasterizer won't need any developer effort. These will just works.

Packed math will require a little developer effort to work. There is an extension for this in OGL and Vulkan, and a GPUOpen header for D3D12.

As far as I remember these are the publicly disclosed Vega features.

 

[CatMerc]

Some will need, some will not.

HBCC won't need developer effort on a legacy API, and may not need on an explicit API, but in D3D12/Vulkan this is highly depends on how the application works.

Primitive shader will need a lot of developer effort, because the main reason to use it is to create a fully custom graphics pipeline.

The new geometry pipeline and the new rasterizer won't need any developer effort. These will just works.

Packed math will require a little developer effort to work. There is an extension for this in OGL and Vulkan, and a GPUOpen header for D3D12.

As far as I remember these are the publicly disclosed Vega features.

https://www.reddit.com/r/Amd/commen...re/dhqpowf/?context=3&st=j30334u0&sh=f48d2583

The new geometry pipeline in Vega was designed for higher throughput per clock cycle, through a combination of better load balancing between the engines and new primitive shaders for faster culling. As a programmer you shouldn't need to do anything special to take advantage of these improvements, but you're most likely to see the effects when rendering geometrically complex scenes that can really push the capabilities of the hardware.

 

[w3rd]

Just a thought. What if AMD delayed RX Vega architecture based GPUs to this year, because of HDMI 2.1 Spec release in Q2 2017?

It allows for 4K@120 Hz and 8K@Hz with HDR, both with HDR.

Yep, I have mentioned this several times. That is why Big Vega has no reason to debut and not in people's hands.

 

[Headfoot]

Yep, I have mentioned this several times. That is why Big Vega has no reason to debut and not in people's hands.

Source? Or just more shoot from the hip speculation?