NVIDIA "OpenGL 2016" Driver Leaks Out Early, Adds GLSL SPIR-V Extension

[mannerov]

I think the main advantage of the new extension, is that people that port games will now use HLSL->SPIRV translater, instead of HLSL->GLSL

[andre30correia]

It is clear that:
1) OGL games distributed in SPIR-V will only work with OGL state trackers.
2) Vulkan games distributed in SPIR-V will only work with Vulkan front drivers.
3) OCL apps distributed in SPIR-V will only work with OCL state trackers.
4) Vulkan games distributed in SPIR-V can be made with various languages like GLSL - HLSL and even DotNet.
5) There are automated "basic" converters (source based), from D3D to OGL and from both to Vulkan.

EDIT: I also propose to Companies like Feral to stop porting games from D3D9 to OGL, it is unnecessary (Gallium Nine). They should port the D3D11-only games that are less restricted and they do not exist on Linux.

gallium nine is a wast of time, we need native or ported games and wine, wine need to die

[duby229]

gallium nine is a wast of time, we need native or ported games and wine, wine need to die

No it just needs officially forked so that somebody with common sense can make management decisions. The guys making decisions for that project right now are morons. Like, "Lets implement CSMT", which increases wines overhead proportionally with the number of cores your CPU has. Completely retarded in a day and age when reducing overhead and eliminating CPU bottlenecks is the entire point.

[artivision]

gallium nine is a wast of time, we need native or ported games and wine, wine need to die

Wine is a Linux library. If the game is Wine Platinum, then it's a native game. Gallium Nine is a Linux library and a lot faster than "Ported".

[mannerov]

No it just needs officially forked so that somebody with common sense can make management decisions.

Since you know better, what do you think they should do as priority ? (btw, merging to wine staging is a priority for them, and it's WIP. CSMT is not a priority, just an experiment)

The guys making decisions for that project right now are morons.

...

Like, "Lets implement CSMT", which increases wines overhead proportionally with the number of cores your CPU has. Completely retarded in a day and age when reducing overhead and eliminating CPU bottlenecks is the entire point.

I don't think you get really what's the purpose of csmt. d3d9 is a single-threaded API. However it can work with multithread if you pass a flag.
The specification of this flag is that the api calls will be protected by some mutexes to force thread-safety.

CSMT is "have a thread that does all the internal api calls (GL for wine d3d->gl, gallium for nine), so that you return the fastest possible from d3d calls". When you do some d3d call, the parameters will be saved, and the call will be sent to the other thread. You return from the d3d call before the gl call is executed. This can be done, because the d3d calls need almost no validation, so you don't need to know what the ogl calls will return, to return the correct d3d value to the caller.

for wine d3d->gl, it makes sense to use csmt because GL calls are slow (validation, etc).
Using csmt makes thus single-threaded apps a bit faster. However for multithreaded apps it makes a bigger difference, because the mutexes are released much faster, preventing all the game threads from being blocked for one gl call.

There is additionnal overhead to save the parameters of the d3d calls, to treat them in another thread, but that's certainly not proportionnal to the number of cpu cores, just proportionnal to the number of api calls. Since the gl calls are slower than that additionnal overhead, it is a gain for wine d3d -> gl

For gallium nine, the gallium calls overhead is much lower, and so using csmt is not a gain as is. The reason is not that the overhead of csmt is bigger than the cost of the gallium calls. The reason is that if you have some call that must return a value (for example you lock a surface), you need to wait all previous recorded calls to finish.
However if implemented clever, you do not need to do this for buffer and texture locks, etc. Thus with clever implementation you should get a gain.

Also please note that Windows d3d9 has an equivalent of CSMT. The clever one that doesn't block for locks.

[artivision]

Since you know better, what do you think they should do as priority ? (btw, merging to wine staging is a priority for them, and it's WIP. CSMT is not a priority, just an experiment)



...



I don't think you get really what's the purpose of csmt. d3d9 is a single-threaded API. However it can work with multithread if you pass a flag.
The specification of this flag is that the api calls will be protected by some mutexes to force thread-safety.

CSMT is "have a thread that does all the internal api calls (GL for wine d3d->gl, gallium for nine), so that you return the fastest possible from d3d calls". When you do some d3d call, the parameters will be saved, and the call will be sent to the other thread. You return from the d3d call before the gl call is executed. This can be done, because the d3d calls need almost no validation, so you don't need to know what the ogl calls will return, to return the correct d3d value to the caller.

for wine d3d->gl, it makes sense to use csmt because GL calls are slow (validation, etc).
Using csmt makes thus single-threaded apps a bit faster. However for multithreaded apps it makes a bigger difference, because the mutexes are released much faster, preventing all the game threads from being blocked for one gl call.

There is additionnal overhead to save the parameters of the d3d calls, to treat them in another thread, but that's certainly not proportionnal to the number of cpu cores, just proportionnal to the number of api calls. Since the gl calls are slower than that additionnal overhead, it is a gain for wine d3d -> gl

For gallium nine, the gallium calls overhead is much lower, and so using csmt is not a gain as is. The reason is not that the overhead of csmt is bigger than the cost of the gallium calls. The reason is that if you have some call that must return a value (for example you lock a surface), you need to wait all previous recorded calls to finish.
However if implemented clever, you do not need to do this for buffer and texture locks, etc. Thus with clever implementation you should get a gain.

Also please note that Windows d3d9 has an equivalent of CSMT. The clever one that doesn't block for locks.

NO - NO and NO. D3D9 is multi-threaded. I play single-thread ports from consoles like FFXIII, but I play multi-threaded MMO like Tera to. CSMT have nothing to do with D3D at all. OGL is single-threaded except if you have a game-internal thread engine or your drivers have threaded_optimizations like Nvidia. CSMT is an engine that takes a dual-thread D3D9 game and work it upon a dual-thread OGL stream. There is no chance that a single-thread game like FFXIII will become dual-threaded with CSMT, I have test it - NO CHANCE.

[duby229]

NO - NO and NO. D3D9 is multi-threaded. I play single-thread ports from consoles like FFXIII, but I play multi-threaded MMO like Tera to. CSMT have nothing to do with D3D at all. OGL is single-threaded except if you have a game-internal thread engine or your drivers have threaded_optimizations like Nvidia. CSMT is an engine that takes a dual-thread D3D9 game and work it upon a dual-thread OGL stream. There is no chance that a single-thread game like FFXIII will become dual-threaded with CSMT, I have test it - NO CHANCE.

Yep. That's exactly right. Which is why command stream submission should be handled by the device drivers.

MS lost. Directx can be re-implemented natively - legally now. It's the right way to do it. It has been ever since MS lost that lawsuit. Why the wine devs refuse to recognize that is beyond me.

[mannerov]

NO - NO and NO. D3D9 is multi-threaded. I play single-thread ports from consoles like FFXIII, but I play multi-threaded MMO like Tera to. CSMT have nothing to do with D3D at all. OGL is single-threaded except if you have a game-internal thread engine or your drivers have threaded_optimizations like Nvidia. CSMT is an engine that takes a dual-thread D3D9 game and work it upon a dual-thread OGL stream. There is no chance that a single-thread game like FFXIII will become dual-threaded with CSMT, I have test it - NO CHANCE.

You haven't understood what I meant.

Let me repeat: "d3d9 is a single-threaded API. However it can work with multithread if you pass a flag."

That doesn't prevent apps from being multithreaded and using the api in a multithreaded way, but there's a big difference with a real multithreaded api like vulkan as you see:

Every call to the d3d9 api (except the C++ refcount functions) is protected by a mutex: Only ONE thread at a time will be inside a d3d9 call.

Typically a d3d9 multithreaded apps will distribute graphic work like that:
. main thread does all the draw calls
. several threads do compute and fill the vertex buffers (where the coordinates of what to draw, and the data associated are stored).

Filling a vertex buffer means 'call the d3d9 api buffer Lock function' - fill the buffer - 'call the d3d9 api buffer Unlock function'

Multithreaded apps working like that do not have slowdowns because of the mutexes, because the Lock and Unlock calls are very fast. What is slow is filling the buffer.


The reason multithreaded apps do not work well with opengl is because a gl context can be current in only one thread. Unfortunately the switching of the context from a thread to another costs a bit (whereas for d3d9 there is no need for switch), and that kills performance if app is multithreaded.
However with recent gl extensions, there is tricks to enable multithreaded apps to work better (you can lock once and never unlock, for example).

Vulkan is a real multithreaded API, because there is no mutexes. You can prepare draw calls commands in different threads.