Direct3D 9 Over Vulkan Hits New Milestone

[starshipeleven]

unapproved post for darkbasic

D3D command stream patches for testing (initial commit) https://www.winehq.org/pipermail/win...er/101106.html

[starshipeleven]

second unapproved post for darkbasic

It seems that piece of shit of forum software called vBullettin dislikes the links to wine's mailing list.

[eydee]

Gallium Nine with CSMT activated is now better than the native performance: http://www.gearsongallium.com/?p=3522

In a special corner case in a game no one has ever heard of... This isn't about marketing, these are open source projects people do in their free time.

[haagch]

What the hell is Gallium Nine with CSMT? Never heard about it...

I think just using (more?) threads for the direct3d9 part: https://github.com/iXit/Mesa-3D/commits/csmt

[andrebrait]

I actually think this project is VERY interesting. The whole point of having a low level API such as Vulkan is to have a driver that's pretty minimal (as in Vulkan drivers are far, far simpler than OpenGL/D3D ones), aside from the performance boost that comes with having more control over the hardware.

Implement higher-level APIs using lower-level ones is interesting in the same way that implementing a Python interpreter in C is more interesting than writing it in x86 assembly. You got portability and code that's much more readable. C compiler programmers care about C, the Python folks care about implementing their interpreter in C and that's it. It's the whole point of having different levels os abstraction. I know this is a far-fetched example, but I think it suits this specific case well...

By implementing D3D9 (or any higher-level API) in a low-level one you got portability (because it will be able to run in any platform that has a Vulkan driver for it), the drivers get slimmer (because if the higher-level functions are implemented over the low-level API, the drive only has to implement the low-level API), potentially easier to debug, and that's only the beginning. If done right, performance might even end up being better than the native implementation! We get to see this with LLVM (which is comparable if seen from the "is able to compile to bytecode" and "is able to compile bytecode to machine code" POV, though I know compiling code having an IR in the middle is different from having Vulkan in the middle).

[blackout23]

You'd probably have to implement all the game specific optimizations and driver heuristics that are usually part of the DirectX driver into it to make it reasonably fast.

[log0]

I actually think this project is VERY interesting. The whole point of having a low level API such as Vulkan is to have a driver that's pretty minimal (as in Vulkan drivers are far, far simpler than OpenGL/D3D ones), aside from the performance boost that comes with having more control over the hardware.

Implement higher-level APIs using lower-level ones is interesting in the same way that implementing a Python interpreter in C is more interesting than writing it in x86 assembly. You got portability and code that's much more readable. C compiler programmers care about C, the Python folks care about implementing their interpreter in C and that's it. It's the whole point of having different levels os abstraction. I know this is a far-fetched example, but I think it suits this specific case well...

By implementing D3D9 (or any higher-level API) in a low-level one you got portability (because it will be able to run in any platform that has a Vulkan driver for it), the drivers get slimmer (because if the higher-level functions are implemented over the low-level API, the drive only has to implement the low-level API), potentially easier to debug, and that's only the beginning. If done right, performance might even end up being better than the native implementation! We get to see this with LLVM (which is comparable if seen from the "is able to compile to bytecode" and "is able to compile bytecode to machine code" POV, though I know compiling code having an IR in the middle is different from having Vulkan in the middle).

I see this being continuously repeated on phoronix. You will have a hard time even getting close to native perf. Vulkan is all about immutable objects (doing things up front) and threading, D3D9/OpenGL not so much.

See: http://gpuopen.com/wp-content/upload...ns_learned.pdf

[nomadewolf]

2020... with 75% of graphics performances...
Dx9 is not the only thing to run games, there is inputs, sound, ia, interfaces...

This project is a good thing but need to be followed and in link with more others projects (sdl for example)

I'd like to believe that 2020 hardware will have no issues dealing DX9 stuff, even with 25% impact on performance...

[AsuMagic]

" D3D command stream management", see patches here:
https://www.winehq.org/pipermail/win...er/101106.html

That's weird, because from my knowledge and according to that mail it's only supposed to affect wined3d, aka not gallium nine, doesn't it?

[birdie]

What a waste of human resources! Wine already has D3D 9.0c->OpenGL conversion implemented at 95% and what we really need is proper support for D3D11/12 - the area which is only barely touched by Wine.