Vulkan is a GCN low level construct?

[sebbbi]

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?


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

AMDs OpenGL drivers are quite bad. Nvidia on the other hand invests heavily on OpenGL. The difference is even larger than in DirectX 11. Now with Vulkan and DX12 the developer basically writes the biggest part of the traditional driver. Of course this brings AMD and Nvidia closer to each other.

A bad driver doesn't only use more CPU cycles, it doesn't utilize the GPU as well as a good one. A good driver for example can analyze the resource write->read dependency chains to reorder & overlap work (in the same queue). Resource barriers (DX12 and Vulkan) allow the developer to define these resource relations themselves, and perform the transitions in a way that minimizes the GPU idling. I would guess that Nvidia's driver does runtime analysis to perform these things automatically in OpenGL and DX11, resulting in GPU gains (compared to AMD drivers), but at the same time using considerable amount of CPU cycles. Nvidia's DX11 driver has many worker threads doing lots of stuff in background. Who knows how complex optimizations they are running at background.

With DX12 and Vulkan the developer can finally state their intention. The driver doesn't need to be guessing and doing heavy runtime optimizations that eat lots of CPU cycles. This is a big gain for limited TDP platforms such as laptops, mobiles and consoles. And personally I believe that drivers using up to 2 Skylake cores aren't a good lasting solution for desktops either. I'd rather see those CPU cycles used for something else.

 

[Ryan Smith]

With DX12 and Vulkan the developer can finally state their intention. The driver doesn't need to be guessing and doing heavy runtime optimizations that eat lots of CPU cycles

The upside of low-level APIs is that the developer gets to be in control. The bad news is that it's the developer who gets to be in control. With great power comes the ability to do great things, or to blast your foot off.

 

[CarstenS]

Does Doom run under OpenGL on console?

 

[BRiT]

Does Doom run under OpenGL on console?

I don't think either console sports OpenGL. MS does DX11.x and DX12 while Sony does GNMX and GNM.

 

[sebbbi]

I don't think either console sports OpenGL. MS does DX11.x and DX12 while Sony does GNMX and GNM.

OpenGL would be horrible waste of CPU resources on any console platform. There hasn't been a single console in existence with full standards compliant OpenGL implementation. Some consoles have had a limited OpenGL API, but no AAA developer would ever use a limited OpenGL API on consoles as low level APIs always sport significiantly higher performance and offer access for all hardware specific features.

 

[Alessio1989]

Vulkan is a great occasion for mobile drivers: mobile IHVs have a great opportunity to write less lunatic drivers, especially on android ( :
PS: a fairy told me SM6 preview is coming, just be patient... The repo is still private :/ .. But I know devs can ask for invitation ( :

 

[dogen]

A bad driver doesn't only use more CPU cycles, it doesn't utilize the GPU as well as a good one. A good driver for example can analyze the resource write->read dependency chains to reorder & overlap work (in the same queue).

I would guess that Nvidia's driver does runtime analysis to perform these things automatically in OpenGL and DX11, resulting in GPU gains (compared to AMD drivers), but at the same time using considerable amount of CPU cycles.

Interesting.
By this you mean DX12 style "multi-engine" concurrency, right?

 

[seahawk]

That makes no sense, as NV Cards perform better on weak CPUs under DX11. In fact it seems as if the NV Driver creates much less CPU overhead under DX11 and OGL than the AMD driver.

 

[CarstenS]

I don't think either console sports OpenGL. MS does DX11.x and DX12 while Sony does GNMX and GNM.

OpenGL would be horrible waste of CPU resources on any console platform. There hasn't been a single console in existence with full standards compliant OpenGL implementation. Some consoles have had a limited OpenGL API, but no AAA developer would ever use a limited OpenGL API on consoles as low level APIs always sport significiantly higher performance and offer access for all hardware specific features.

Thank you both. I was just wondering why the hell id Software bothered with an OpenGL path in the first place - why I wondered in the first place becomes glaringly obvious in this post at the latest. Must be that they needed to hit their deadline on friday 13th for release and already had that crappy OpenGL path in place.

 

[Simon F]

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.

Can this comparative demo from IMG/PowerVR convince you?

 

[pMax]

Can this comparative demo from IMG/PowerVR convince you?

...wow.

 

[dogen]

That makes no sense, as NV Cards perform better on weak CPUs under DX11. In fact it seems as if the NV Driver creates much less CPU overhead under DX11 and OGL than the AMD driver.

Perhaps the difference in overhead between nvidia and amd is still much larger than whatever difference those optimizations would make. In Doom, it was around 50-60% higher.

 

[DavidGraham]

Still, for the majority of architectures (excluding GCN), Vulkan seems to hurt more than advance, at least when compared to a strong OpenGL/DX11 support:

 

[dogen]

Anyone else see this?

Even in vulkan nvidia isn't nearly as affected by slower CPUs.

 

[Silent_Buddha]

That makes no sense, as NV Cards perform better on weak CPUs under DX11. In fact it seems as if the NV Driver creates much less CPU overhead under DX11 and OGL than the AMD driver.

You've got that backwards. Under CPU limited scenarios (1080p for example) NV cards do better under Vulkan than they do in OGL. That is showing that under OGL, they are significantly more CPU limited than under Vulkan. As you become more GPU bound (higher resolutions, for example) the performance gap closes showing that the GPU is becoming more of a bottleneck than the CPU. Eventually at 4k max settings you'll get no performance difference between OGL and Vulkan on NV because it is almost entirely GPU bound at that point.

The graph by Dogen illustrates this perfectly.

OGL increases in performance due to CPU power much more than Vulkan does showing a greater reliance on the CPU.

In other words, more rendering time is used by the CPU under OGL than under Vulkan.

Regards,
SB

 

[seahawk]

My reply was to a post stating that the NV/Driver would use more CPU power under DX11 and OGL. compared to AMD drivers, which it does not, as it seems not even under Vulkan.

 

[Silent_Buddha]

My reply was to a post stating that the NV/Driver would use more CPU power under DX11 and OGL. compared to AMD drivers, which it does not, as it seems not even under Vulkan.

It would help if you indicated which post you were referring to then. As the post right above yours was responding to Sebbbi's post which was about OGL/DX11 versus Vulkan/DX12 and not AMD versus Nvidia.

The only thing he compared between the two was the "bad" AMD Dx11/OGL drivers compared to the "good" Nvidia Dx11/OGL drivers.

Regards,
SB

 

[seahawk]

Sorry, I understood the post a a comparison between AMD and NV drivers under different APIs, not as a comparison of different APIs.

 

[pharma]

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.
Cheers

Jul 29 2016
Hardware Support
All intrinsics discussed in this article are available on our Kepler, Maxwell, and Pascal GPUs, across our Quadro and GeForce graphics cards as well as on our Tegra K1 and Tegra X1 mobile GPUs.

HLSL for DirectX 11 and DirectX 12
NVIDIA provides a mechanism for using the intrinsics from HLSL in DirectX 11 and DirectX 12.

GLSL for OpenGL and Vulkan
Our drivers expose the warp shuffle and warp vote intrinsics as a series of OpenGL GLSL extensions in addition to the cross-vendor Khronos OpenGL ARB extensions

https://developer.nvidia.com/reading-between-threads-shader-intrinsics

 

[Deleted member 13524]

Anyone else see this?

Don't play 2016 games with 2009 CPUs. Got it.
I'll share that incredibly useful knowledge with all my friends.