• Competitor rules

    Please remember that any mention of competitors, hinting at competitors or offering to provide details of competitors will result in an account suspension. The full rules can be found under the 'Terms and Rules' link in the bottom right corner of your screen. Just don't mention competitors in any way, shape or form and you'll be OK.

***The Official Vulkan API Thread***

Directx 12 / Vulkan will differ from previous apis through building state in multiple threads and writing data to the GPU in more direct ways(less cpu->gpu copying) and pushing of data from cpu to gpu using multiple threads.

The building of the state will include more and more complex state structures on the CPU side, before passing them to the GPU (via multiple CPU threads/cores).

The more data that can be passed from the CPU to the GPU per call, obviously less driver overhead, but also more opportunities for optimisation at the driver level.

Now DirectX is object oriented and already uses large state structures to set state before a draw call.

Old OpenGL uses much simpler calls to maintain a "state machine", which makes it much more difficult to multithread and optimise.

So basically the pros of Dx12/vulkan will be:
More direct data transfer from cpu to to gpu via multiple threads(vertex data, textures, etc).
More direct state data transfer cpu->gpu(shaders, shader uniforms)

In fact, it looks like the way data will be addressed in shader languages could be completely changed.

Cons (for the devs)
New shader language?
Working with a much lower level and complex API. A lot more work for multi-thread synchronisation.

The cons aren't really cons for the devs, 'cause they love new **** and a challenge.

Personally, I can't wait until the final spec, headers and drivers are released.

Edit Mantle:
Looking at some of the function names in the Mantle dll, some of this **** could have been implemented at a guess, but we will never know because there was never a public SDK.
 
Last edited:
Mauller said:
Just watching the video, but from this and other sources, it is looking like a lot of vulkan is based on the mantle spec. Parts looking like they are cut and shut, from a lot of the api calls using the same names, but with a different namespace.
Click to expand...

Would be interesting to know what % of code was lifted from Mantle without being touched (other than naming obviously).

I think Vulkan is a good thing for everyone and it already seems to have overcome my biggest concern with Mantle and that's that it only worked on AMD hardware (for whatever reason). I think if the API is going to be successful it needs to run on all vendors, which I just didn't see Mantle doing even if it's because Intel and Nvidia (understandably) didn't want to put any reliance on a competitor's product. With it being controlled by the Khronos group, hopefully one vendor won't have enough influence on it to make it give their product the advantage.


Cambofrog said:
Directx 12 / Vulkan will differ from previous apis through building state in multiple threads and writing data to the GPU in more direct ways(less cpu->gpu copying) and pushing of data from cpu to gpu using multiple threads.

The building of the state will include more and more complex state structures on the CPU side, before passing them to the GPU (via multiple CPU threads/cores).

The more data that can be passed from the CPU to the GPU per call, obviously less driver overhead, but also more opportunities for optimisation at the driver level.

Now DirectX is object oriented and already uses large state structures to set state before a draw call.

Old OpenGL uses much simpler calls to maintain a "state machine", which makes it much more difficult to multithread and optimise.

So basically the pros of Dx12/vulkan will be:
More direct data transfer from cpu to to gpu via multiple threads(vertex data, textures, etc).
More direct state data transfer cpu->gpu(shaders, shader uniforms)

In fact, it looks like the way data will be addressed in shader languages could be completely changed.

Cons (for the devs)
New shader language?
Working with a much lower level and complex API. A lot more work for multi-thread synchronisation.

The cons aren't really cons for the devs, 'cause they love new **** and a challenge.

Personally, I can't wait until the final spec, headers and drivers are released.
Click to expand...

One con could be that based on Mantle we could be waiting months for multi GPU support. AMD guys are probably used to waiting months to get multi GPU support working, but could come as a shock to Nvidia owners :)
 
Last edited:
GoogalyMoogaly said:
One con could be that based on Mantle we could be waiting months for multi GPU support. AMD guys are probably used to waiting months to get multi GPU support working, but could come as a shock to Nvidia owners :)
Click to expand...

The need to explicitly write a "multi-gpu rendering system" into the game engine, is a feature of the "low abstraction" API's. This will be no different for Directx 12, The engine will need the support coded into it, But as time goes on, more reference code for this, as well as people with experience in doing this, will increase.

But with the support being in the engine, as well as the game engine directly controlling all of the GPU's in the system, the developers will have far better control over the rendering, meaning the performance is often superior to the current driver based implementations.

Current Multi-gpu rendering systems, run on top of directx from within the driver, the engine has no input except for the odd few extensions which help with frame synchronisation.
 
GoogalyMoogaly said:
One con could be that based on Mantle we could be waiting months for multi GPU support. AMD guys are probably used to waiting months to get multi GPU support working, but could come as a shock to Nvidia owners :)
Click to expand...

OpenGL/Vulkan only supplies a spec and no implementation. Any Implementation depends on GPU hardware vendors in collaboration with OS/CPU vendors.

Directx has a top level interface implemented in code my Microsoft.
DirectX calls into a driver which must fit the interface specified by Microsoft, but the driver has to implemented in code by a GPU hardware vendor in collaboration OS/CPU vendor .

AMD/ATI has had notoriously bad drivers for OpenGL in the past, especially for non Windows systems.

Edit: Enabling the validation layer in Vulkan. The validation layer is probably similar o the top level DirectX code before it calls in to the driver.

So when developing/debugging for Vulcan enable validation layer.
When ready for release code, disable validation layer. Awesome.
 
Last edited:
Cambofrog said:
Edit: Enabling the validation layer in Vulkan. The validation layer is probably similar o the top level DirectX code before it calls in to the driver.

So when developing/debugging for Vulcan enable validation layer.
When ready for release code, disable validation layer. Awesome.
Click to expand...

The validation layer essentially shows you what is going through the API layer and where it is going, what calls are being made etc. It is quite a bit different to what Directx does.

It mainly helps in the debugging of code.
 
Now that we're hearing about MS and NVIDIA colluding to make various DX12 features exclusive to NVIDIA / tailored specifically to them (in order to undermine Vulkan / Mantle / AMD and retain DX's primacy), I seriously hope Valve don't support DX12 at all on first party titles ... indeed, it'd save them a lot of largely pointless effort as the number of users on W10 will be such a small % for several years.
 
pmc25 said:
Now that we're hearing about MS and NVIDIA colluding to make various DX12 features exclusive to NVIDIA / tailored specifically to them (in order to undermine Vulkan / Mantle / AMD and retain DX's primacy), I seriously hope Valve don't support DX12 at all on first party titles ... indeed, it'd save them a lot of largely pointless effort as the number of users on W10 will be such a small % for several years.
Click to expand...

Where is this information about collusion? From what I know, DX12 was having some features that are not supported "in hardware" for current cards, but possible software implementations.

Personally, I believe DX12 was being worked on for a while, just not in the same "low abstraction" form that it ended up. Mantle was what kicked them in gear, they already had "low abstraction" versions of dx to work from, the ones used on xbox, etc.
 
pmc25 said:
Now that we're hearing about MS and NVIDIA colluding to make various DX12 features exclusive to NVIDIA / tailored specifically to them (in order to undermine Vulkan / Mantle / AMD and retain DX's primacy), I seriously hope Valve don't support DX12 at all on first party titles ... indeed, it'd save them a lot of largely pointless effort as the number of users on W10 will be such a small % for several years.
Click to expand...

wIn10 being a free upgrade for 70% of current windows users... yeah I'm sure uptake will be low for gamers...
 
TwsT said:
openGL a cheaters paradise :)

some of those open GL cheats were disgusting and undetectable
Click to expand...

Vulkan is not OpenGL though :P

The varied and poor implementation of OpenGL, does not help with those issues overall.

I Just want Demo's, Benchmarks and drivers out already :P

Will be interesting to see if people try to remake older source games in Source 2, using the Vulkan version, will be interesting to see how many explosions and physics objects you can make in Gmod, on source 2 with vulkan. :P
 
Vulkan Session I Part I

http://www.ustream.tv/recorded/59559306

GDC_2015_Vulkan_Thanks_AMD.png
 
Very poor picture quality and sound level on the Vulcan session part 1.

Keys points:
Unified model for desktop and mobiles.

More opportunities for devs to use multi-threading.

Reduced CPU overhead using layers. The validation layer can by enabled (increased CPU overhead) during development and debugging, then disabled (decreased CPU overhead) for the final release code.

Khronos thanks AMD for giving Mantle specs which Vulkan uses as base for it's spec.

EDIT:
paraphrase: "committees are very good at improving and building on existing specs. Not good at building them from the ground up, but good at improving them".

Make of that what you will :p

Going to watch part 2 now, which is going to show some pseudo code. Don't know if it will be readable with that picture quality though.:(
 
Last edited:
You must log in or register to reply here.
Back
Top Bottom