Vulkan is a GCN low level construct?

[DavidGraham]

You have ~60 million present consoles and their 2017 follow-ups all confirmed to be using GCN but you think developers should abstain from using all performance-enhancing features available to them because AMD may eventually someday in the future switch architectures in the PC space.
I don't even..

Yes of course, Vendors will stop supporting an API that does nothing to benefit their hardware, If for example Intel and NVIDIA decided against an API, you think developers would bother with it? especially those APIs that require more work from the developers (especially on PC). When the threshold of architectural changes reaches a point, developers will simply have to drop old architectures when using the supposedly "low level APIs", which is another incentive for vendors to drop the support for them, if their harmful effect remained consistent. Or at the very least sideline them in favor of other high level APIs that are more reliable.

What havoc are you talking about? There's not a single DX12/Vulkan benchmark out there, where Nvidia loses any significant amount of performance that's outside margin of error.

See gamegpu tests with Vulkan in Doom, Kepler cards takes a massive hit with Vulkan.

That's assuming there is a problem in the first place. Expect a max 10% bump in Pascal performance when they enable and fine tune async compute. Expect 0% bump on anything older.

That's the problem right there, all low level optimizations have been restricted to Async Compute, as if this is the only untapped potential in all hardware out there, which sounds very hard to believe, it's like some companies are doing with high level code what developers with low level access can't.

It's blatantly obvious Vulkan -right now- is a GCN low level construct. and thus can barely benefit any other architecture or vendor.

 

[Ext3h]

It's blatantly obvious Vulkan -right now- is a GCN low level construct. and thus can barely benefit any other architecture or vendor.

Far from being true. The Vulkan API actually allows to accurately represent a huge variety of hardware platforms, not only GCN. Whether the game developers actually comprehend the different platforms well enough to address them properly, and if the hardware vendors are actually willing to both implement the API as low level as intended, as well to give out the necessary specs to utilize it properly, is an entirely different matter.

 

[Anarchist4000]

It's blatantly obvious Vulkan -right now- is a GCN low level construct. and thus can barely benefit any other architecture or vendor.

Guess AMD is poised to take over the entire mobile market then since Google adopted Vulkan for Android?

 

[DavidGraham]

Far from being true. The Vulkan API actually allows to accurately represent a huge variety of hardware platforms, not only GCN. Whether the game developers actually comprehend the different platforms well enough to address them properly, and if the hardware vendors are actually willing to both implement the API as low level as intended, as well to give out the necessarily specs to utilize it properly, is an entirely different matter.

Which why I said "benefit" not "support", the API can run on many architectures, but can it actually result in performance/visual gain?

Guess AMD is poised to take over the entire mobile market then since Google adopted Vulkan for Android?

We've yet to see it's implementation, and whether this will carry over to other operating systems or not.

 

[CSI PC]

Which why I said "benefit" not "support", the API can run on many architectures, but can it actually result in performance/visual gain?


We've yet to see it's implementation, and whether this will carry over to other operating systems or not.

Part of the strength of Vulkan for AMD is extensions around GPUOpen/Shader Intrinsic Functions.
In theory Nvidia could also create their own extension, although I am not too sure how flexibile their Intrinsic Function is.

That said, there is still a fundamental strength even here for AMD, and that is the synergy of these functions with consoles that has the AMD hardware - one reason why we have GPUOpen now and also Mantle before it exist.
It makes life easier for the developers and also ties in optimised low-level functions between all platforms when it comes to the game-rendering engine, resulting in greater benefit for AMD.

Nothing wrong with that IMO as it is something both manufacturers try to do, what will be interesting is how Nvidia can respond to this while as for now it puts them a bit on the backfoot for these latest games/and games in development, but this level of adoption will still take a bit of time from a broader perspective, albeit it seems to be gaining momentum for AMD.
Cheers

 

[seahawk]

See gamegpu tests with Vulkan in Doom, Kepler cards takes a massive hit with Vulkan.

They would take a hit if they would perform clearly worse under Vulkan than under OGL, which they do not.

 

[DavidGraham]

They would take a hit if they would perform clearly worse under Vulkan than under OGL, which they do not.

Oh, but it did, Kepler lost 70% of it's fps from the switch to Vulcan.

Part of the strength of Vulkan for AMD is extensions around GPUOpen/Shader Intrinsic Functions.
In theory Nvidia could also create their own extension, although I am not too sure how flexibile their Intrinsic Function is.

And how is that any different from OGL extensions? I thought extensions were one of the reasons OGL never had a wide adoption in games in the first place! Despite Google using (OGL ES) for Android.

It makes life easier for the developers and also ties in optimised low-level functions between all platforms when it comes to the game-rendering engine, resulting in greater benefit for AMD.

It does, but not very much, developers will still invest significant time and resources to work that into PC games.

A counter argument could be used that such reliance on GCN and it's related functions could cost AMD a great deal of it's competitiveness, they could stick with GCN for far too long just to reap the limited benefits of cross platform development.

 

[CarstenS]

Oh, but it did, Kepler lost 70% of it's fps from the switch to Vulcan.

The Kepler model with enough RAM only loses 1 out of 66 fps. IIRC we have seen memory capacity issues with low level APIs before.

 

[CSI PC]

It does, but not very much, developers will still invest significant time and resources to work that into PC games.

A counter argument could be used that such reliance on GCN and it's related functions could cost AMD a great deal of it's competitiveness, they could stick with GCN for far too long just to reap the limited benefits of cross platform development.

They do not have to invest a significant time to implement GPUOpen/extension related type functions, Shader Intrinsic Function is such one and was implemented in Vulkan extension and used in Doom...
This is the perfect way to optimise AMD hardware from a cross-platform perspective, consider why Mantle was 1st created.
To quote Bethesda (who also work closely with Nvidia on other games) for Doom:

When can you expect most notable gains with Vulkan?

Biggest expected gains are with AMD cards – not only due to Vulkan, but also due to AMD specific GPU low level optimization. This was achieved via extensions that AMD made specifically available for Vulkan, in particular AMD Intrinsics. Other thing is that Async Compute is immediately available for AMD cards.

TBH I am not sure what you are critical about with the optimisation.
Anyway my post was in response to you saying:

Which why I said "benefit" not "support", the API can run on many architectures, but can it actually result in performance/visual gain?


We've yet to see it's implementation, and whether this will carry over to other operating systems or not.

And the answer is a definite yes with the approach AMD can take with the synergy between their PC GPUs and consoles, all due to the latest extensions and GPUOpen, of course as well Async Compute but too much focus on that for performance gains IMO.
As I said Nvidia could possibly implement their own Intrinsic Functions if it is flexible enough.
Cheers

 

[Anarchist4000]

Intrinsics work for DX12 as well as Vulkan. While the intrinsic functions do help AMD performance, I'd imagine they have far more to do with allowing devs to easily port code from consoles than providing an unfair advantage. I'm sure devs would support Nvidia intrinsics where possible.

Mobile IHVs have done a lot with Vulkan from what I've heard, but it's still early. It's difficult to call it a GCN construct, although GCN was designed for the model.

 

[seahawk]

Oh, but it did, Kepler lost 70% of it's fps from the switch to Vulcan.

Only the 780 3GB does, the 770 4GB does not.

 

[DavidGraham]

The Kepler model with enough RAM only loses 1 out of 66 fps. IIRC we have seen memory capacity issues with low level APIs before.

3GB Kepler appear to lose fps due to VRAM, 3 GB 7970 doesn't. Why?

 

[CarstenS]

Obvious answer that does not get us anywhere: Memory management. I could as well write: No idea.

 

[BRiT]

3GB Kepler appear to lose fps due to VRAM, 3 GB 7970 doesn't. Why?

Lazy Device Driver Devs in one camp but not the other?

 

[seahawk]

id software said that the Vulkan rendering path for CGN is more mature than for the Geforces.

 

[Rodéric]

id software said that the Vulkan rendering path for CGN is more mature than for the Geforces.

That a nice way to say that GCN is more mature than current nVidia architecture. ;p

 

[sebbbi]

That's the problem right there, all low level optimizations have been restricted to Async Compute, as if this is the only untapped potential in all hardware out there, which sounds very hard to believe, it's like some companies are doing with high level code what developers with low level access can't.

It's blatantly obvious Vulkan -right now- is a GCN low level construct. and thus can barely benefit any other architecture or vendor.

Both DX12 and Vulkan focused around reducing the CPU bottleneck (new binding model, new resource management model). Big CPU gains are clearly visible in DX12/Vulkan CPU benchmarks. Id actually said that with Vulkan Doom should run smoothly on a dual core CPU (OpenGL requires a quad).

Compute queues were one of the few features that boost GPU performance. Multithreaded command list recording was needed for proper multithreaded work submission and manual resource management needed exposed copy queue. It was natural to also expose the compute queues.

GPU performance improvements will come later. See Microsoft's Shader Model 6.0 presentation. Lots of goodies are coming soon. I am sure Vulkan will evolve similarly (as OpenCL 2.1 already supports some SM6.0 stuff).

 

[Deleted member 13524]

The thread title is hilarious.

I wonder what PowerVR, ARM Mali, Qualcomm and Vivante engineers have to say about this "Vulkan is a GCN construct" statement.

For example, we’ve used Vulkan in our Gnome Horde demo and saw a 10x performance improvement vs. OpenGL ES for certain workloads

Or even nvidia for that matter:

 

[DavidGraham]

Both DX12 and Vulkan focused around reducing the CPU bottleneck (new binding model, new resource management model). Big CPU gains are clearly visible in DX12/Vulkan CPU benchmarks. Id actually said that with Vulkan Doom should run smoothly on a dual core CPU (OpenGL requires a quad).

We've seen how GCN still benefited greatly from Doom's Vulkan even with Async disabled, so does these benefits come from merely relieving the CPU overhead?

GPU performance improvements will come later. See Microsoft's Shader Model 6.0 presentation. Lots of goodies are coming soon. I am sure Vulkan will evolve similarly (as OpenCL 2.1 already supports some SM6.0 stuff).

I think Shader Intrinsics are projected to become part of SM6, are they not?

id software said that the Vulkan rendering path for CGN is more mature than for the Geforces.

Where?

 

[MDolenc]

We've seen how GCN still benefited greatly from Doom's Vulkan even with Async disabled, so does these benefits come from merely relieving the CPU overhead?

Not necessarily just CPU overhead. There are shader intrinsics as well which they use and will simplify their shaders.

I think Shader Intrinsics are projected to become part of SM6, are they not

Shader inrtinsics are just a fancy word for shader instructions that are not part of DX HLSL or OpenCL/SPIR-V. At least some of that is coming with SM6 yes.

Where?

They did mention this in their FAQ:

Asynchronous compute is a feature that provides additional performance gains on top of the baseline id Tech 6 Vulkan feature set.

Currently asynchronous compute is only supported on AMD GPUs and requires DOOM Vulkan supported drivers to run. We are working with NVIDIA to enable asynchronous compute in Vulkan on NVIDIA GPUs. We hope to have an update soon.