
VK9: Direct3D 9 compatibility layer using Vulkan - desdiv
https://github.com/disks86/VK9
======
AldousHaxley
D3D9 is my all-time favorite 3D API. It was at that sweet spot of being
powerful enough that you could do stunning things with it (the Xbox 360
generation is effectively D3D9-level hardware), and it was simple enough that
amateurs and hobbyists (and high school kids, as I was at the time) could dive
in and get stuff on the screen relatively quickly. D3DX had some handy helper
libraries for loading models, doing transforms, and loading textures. I get
the benefits afforded by subsequent iterations, and nowadays Vulkan and D3D12,
but their interfaces are so optimized toward specialists, and it would be nice
if more was in place to cover that middle ground use case between "I don't
need a full-on 3D game engine, but I don't need to worry about low level GPU
stuff either." Of the new APIs out there, I feel like Metal is the only one
approaching layperson usability, and it's trapped in the world of Mac and iOS.
Of course you can stitch together something that looks like an open source
equivalent of the old D3D9 SDK yourself from things like glm and AssImp, but
it's nice to have all that in one package.

~~~
garaetjjte
Why not OpenGL 3.2+? It is capable of modern effects and pretty easy to use.

~~~
MaulingMonkey
Console developers don't get much choice: You pretty much _must_ use D3D9,
D3D11, GNM(X), etc.

Mobile's not much better: OpenGL ES for Android (which is a far cry from real
desktop OpenGL - to the point that I consider it a completely different
graphics API that just happens to confusingly reuse the names of some
functions.) Maybe Metal for iOS.

Real desktop OpenGL is one of the few graphics APIs I've never been forced to
use - so why spend even a single dev-month porting to it? Even games with
OpenGL render paths may work better using their Direct3D renderers on Linux
via Wine!

Even counting Linux/OS X, at this point I'm not even convinced OpenGL is
actually the more portable API...

~~~
jhasse
I've written an iOS app and the OpenGL code was (except very few ifdefs)
identical to the desktop code. So I wouldn't say that ES is a completely
different API, you can certainly reuse a lot.

~~~
MaulingMonkey
Not even our shaders went unscathed - no rectangular matrix support (mat4x3?
nope!), mandatory precision specifiers (lowp-highp), no Uniform Buffer
Objects. Can't even call glTexImage2D on ES 2 without perfectly fine OpenGL
code failing - because format !== internalFormat is forbidden (read:
documented "must be the same"), and you were a good explicit OpenGL citizen
and asked for something as horrifically complicated as format=GL_RGBA and
internalFormat==GL_RGBA8. Multiple render targets? Are you out of your mind?
We can't have that - goodbye deferred rendering, hello old school forward
rendering!

Even your bread and butter - functions like glUniformMatrix3fv do things like
just outright ignore the transpose parameter. This is extremely well
documented: "Specifies whether to transpose the matrix as the values are
loaded into the uniform variable. Must be GL_FALSE." (
[https://www.khronos.org/registry/OpenGL-
Refpages/es2.0/xhtml...](https://www.khronos.org/registry/OpenGL-
Refpages/es2.0/xhtml/glUniform.xml) )

I swear I've reused more code between D3D11 and PS4 codepaths than between
OpenGL ES and OpenGL codepaths, and the d3d11 and ps4 APIs don't share a
single common function name betwixt them!

I must assume going from OpenGL ES 2 to real OpenGL a bit easier - even if
you're probably giving all the fast paths in the latter a wide berth in doing
so. Or maybe OpenGL ES 3 is a bit closer to real OpenGL. But OpenGL ES 2 vs
desktop OpenGL? They both render triangles, but beyond that, it's a crap-shot,
and a _lot_ of #ifdefs in my experience. Separate files, even. Not just a few.

EDIT: s/codepaths/apis/, finish summarizing my thoughts.

~~~
pjmlp
Yes, calling OpenGL ES "OpenGL" compatible is only true to the ears of those
that never had the "fun" to write portable code across multiple GPUs.

At the end of the day, the code paths, extension support and driver
workarounds are so many that one could just be coding against multiple APIs
anyway.

------
partycoder
Direct3D can be a good API, but Microsoft played dirty to make it succeed, and
that matters.

If you were around those days, Microsoft said that OpenGL on Windows was going
to be put behind a backward compatibility layer, with a performance penalty.
All developers got scared and switched to Direct3D.

For this reason, I don't care if Direct3D is a good API. Direct3D is the
reason of why most games cannot be ported into other operating systems or are
forced to run on WINE (with issues and performance penalty), and is also the
reason of why Windows has a larger market share than it should.

I really hope Vulkan takes off and replaces Direct3D for most uses.

~~~
AldousHaxley
I remember those anxious days before Longhorn's release. MS was making a lot
of weird threats back then. All the "trusted computing" stuff, as well as the
thinly veiled attempts at killing OpenGL on Windows. Despite my above waxing
nostalgic about the API, I haven't built anything with D3D in years, for
precisely the issues you mentioned. API design quality and performance are
important, but they are far from the only factors that go into making such a
decision.

~~~
yuhong
My favorite is how I was able to guess from Intel's claims that the 915
chipset can't support WDDM because it don't have a "hardware scheduler" that
it is probably referring to the "lost devices" in old DirectX that many
programmers likely remember.

Edit: Old Slashdot thread:
[https://slashdot.org/comments.pl?sid=4123465&cid=44660047](https://slashdot.org/comments.pl?sid=4123465&cid=44660047)

------
shmerl
It seems very far from completion in comparison with D3D9 implementation in
Wine. So for now it's just a interesting project, rather than something
practical.

~~~
coldpie
Yeah. Open any source file and you'll see dozens of "not implemented yet"
FIXMEs. This needs a few more years of maturity before it's worth looking at.

------
oneplane
I'm not sure if this means what I think this means, but does this mean that we
can used Direct3D 9 on WINE now with no need to translate it to something else
first?

~~~
mixedCase
It would translate D3D9 to Vulkan like Wine currently translates D3D9 to
OpenGL.

It's different from Gallium Nine.

------
red023
Why should this excite me? Wine already can do DX9 pretty good. And according
to one comment this does not even compare. Who cares about DX9 nowadays?
DX10/11/12 would be very different story. Something like this bringing modern
windows games to linux would be great.

Even greater would be M$ open sourcing DX but that will not happen in the next
few years.

~~~
cwyers
What good would open-sourcing DirectX be without the Windows Display Driver
Model? And how easy would it be to get that working without the NT kernel? And
how interested would the Linux kernel be in supporting this?

~~~
shmerl
_> What good would open-sourcing DirectX be without the Windows Display Driver
Model? And how easy would it be to get that working without the NT kernel?_

Shouldn't be harder than what Wine is already doing. Open sourcing can surely
help in some ways. MS for example already open sourced HLSL parser, so
translation tools can benefit from it.

DX11 support in Wine is progressing quite well.

