For Those Interested In Direct3D Over Gallium3D

[phoronix]

Phoronix: For Those Interested In Direct3D Over Gallium3D

There still is great interest and discussion among many users interested in Direct3D 10 and 11 being natively implemented on Linux using a new state tracker that was published this week for the Gallium3D driver architecture. It seems some Wine developers are still in opposition to this effort even though their Direct3D 10 implementation within Wine is still very limited in terms of translating the calls to OpenGL and their Direct3D 11 support really hasn't taken off...

http://www.phoronix.com/vr.php?view=ODYzMA

[Svartalf]

Michael, I suspecting that the resistance is due to the risks inherent to doing the state tracker. Doing a translation to the OpenGL layer is likely to not have nearly as many gotchas with Patents as the state tracker would.

It's a nifty thing, yes. But it's ill advised as it's litigation bait moreso than anything WINE might be about doing.

[cl333r]

Not grumpy, but are we going to get this type of articles/propaganda every few days from now on?
I thought we had enough of Mono, and when Fedora dropped it and Ubuntu started going this way too (by getting Vala and D as decent replacements) - I thought we're becoming "free" again. But now we have to deal with another Microsoft "intellectual" "property" threat, not to mention that OpenGL is competitive even with D11, it's even better if you consider that smartphones etc. support OpenGL (ES 2.0), not D2D/D3D.
To me, effort must be committed towards qualitative open-source OpenGL 3.3/4.1 support rather than giving Microsoft another good reason to claim Linux infringes on its patents and hence all users must pay to Microsoft. I wouldn't be surprised if Luca Barbieri is getting fat checks from Microsoft directly or indirectly because (a) he (or his team) called OpenGL much worse than D2D/D3D while knowing it's no longer true with the advent of OpenGL 3x/4x and (b) being _so_ eager to implement D2D/D3D despite serious concerns which he denies as if he was a qualified lawyer. He behaves a lot like Miguel de Icaza.., not flaming, just using common sense to judge what's going on.

[Smorg]

I'm confused with the comment in the previous article about direct3d being a better API than opengl. Back when I did some opengl programming (pre DX10 days) just about everybody seemed to prefer opengl. Maybe things have changed since then. If opengl has any shortcommings the correct solution IMO wouldn't be to throw it away and adopt direct3d, where the specification is bound by the decisions made by Microsoft's reference implementation.

[3vi1]

@cl333r:

Mono is a different situation all together: It includes library code that Microsoft actually wrote. Few people want to get elbow deep into it and have MS "extend" the library APIs like they constantly do and then not open source the new versions in order to "extinguish" the competition.

But back to the D3D subject: Can anyone tell me what's so different, legally, between writing a directx-replacement DLL that passes calls to the Gallium state tracker vs. one that uses an OpenGL backend? Both are dlls that implementat the API, and neither use the MS-written headers or reverse engineering (right?). If one's infringing (which I don't believe to be the case), why wouldn't both be? I seriously would like to know.

[TemplarGR]

There is a reason D3D is better currently than OpenGL: It is more widely used. The point of using a computer is actually running some programs(or games), not just having libraries standing idle, even if they are the best of their class...

It is obvious Wine developers do not want this code because of their ego. They can't stomach the fact that one guy beat them to it.

Patents fears are pure BS. Those claiming potentialy patent infringement of a single API are those who have implemented the entire OS's apis... If this tracker violates patents, so the whole Wine project...

I believe Wine devs should embrace this.

PS: Mono is fine, stop spreading FUD please...

[pingufunkybeat]

Just wait until Microsoft pulls an SCO and asks for 10% of each RedHat, SUSE and Ubuntu purchase.

IBM slaughtered SCO because SCO had no case at all. Microsoft does hold plenty of patents. Any distribution shipping this code is asking for death.

Here is some reading from a guy who knows what he is talking about: http://zrusin.blogspot.com/2010/02/3d-apis.html

[elanthis]

I'm confused with the comment in the previous article about direct3d being a better API than opengl. Back when I did some opengl programming (pre DX10 days) just about everybody seemed to prefer opengl.

DX10/11 is an entirely different beast than DX9 and earlier.

A lot of programmers also really hate the extension system of OpenGL. Sure, it's more flexible, but many devs don't give a shit. They just want to say "we're using DX9" and know exactly what features are going to be there, without needing to write every other bit of the graphics engine as "if GLEW says extension Foo exists then UseFoo else UseShittyWorkaround". Most of my OpenGL work just checks for some specific version of OpenGL, bails if that version isn't available, and only uses the core functionality of that version -- makes the code smaller, cleaner, saner, easier, and (IMO) better.

There's also the matter of DX being a C++ OOP API, which more and more programmers are preferring over the procedural state machine API of GL.

Plus, the DX API is inherently faster than OpenGL in some ways on account of not being a state tracker, because there are less built-in state transition points. For instance, an object in DX is configured once, while an object in GL can be reconfigured at almost any time. This in turn means the GL driver must be complicated and contain more tests (and hence more branches, and more overall code to try to fit in the CPU's code cache, both of which hurt performance quite badly on modern CPUs).

Then there's the multi-threaded programming D3D allows that OpenGL currently does not. This is really important on modern hardware. With OpenGL, you can only do the client application processing of graphics data in multiple threads. You will then need to serialize the computed data through the main thread for submission to the driver. The driver, before it submits the data to the GPU, first does a series of validation checks as well as potential data conversion steps. D3D lets this validation and conversion happen in the individual threads, and only the actual dispatch of the command buffers has to happen in the main thread. D3D is hence inherently able to squeeze out better performance in multi-threaded rendering engines, which exist and are used in commercial titles today. Even the sophomore students' game engines at my school (all game titles are required to be written from scratch, ground up) are being written with multi-threaded physics and graphics components more and more often.

You can also look at Carmack's old GL vs DX post from years ago, and see how yesterday's "better" is today's "worse." It's actually very amusing to note how he thought that the now deprecated (and literally removed in OpenGL ES and OpenGL 3.1+ Core Mode) glBegin/glVertex/glEnd sequence is better than vertex buffers at all. Quite simply, for modern hardware and modern drivers, the old GL method is just incredibly slow and stupid. It can and does result in _massive_ performance degradation from the overhead of making multiple indirect function calls for every vertex attribute. His argument that the old GL 1.x API was easier isn't even that accurate; his code sample of using a vertex buffer looked ugly because he made it look ugly, not because using them is actually difficult or even remotely that bad looking. Modern engines are keeping buffers of vertex data around anyway for CPU-side culling and effects, and it's actually even easier to use DX/GL vertex buffers than it is to use the old GL 1.x API.

I still think it would be neat for someone to define a new, Open API that gives us what Longs Peak was supposed to be: modern OO stateless 3D API targeted at modern hardware. Essentially, in a way, implement D3D 11 with different names/identifiers, and use GLSL 4.10 as the shading language (including support for pre-compiled shaders). Try to get D3D 11's multi-threaded rendering support in, too, that's pretty important these days. (It's possible to implement a much slower version of that in GL, but it's impossible to do it as efficiently in GL due to the nature of the API.) Add an extension framework if you really want, but for the love of God keep the library versioned and based on hardware generations, so if a developer wants to keep his sanity and just use library v.X, he can, and knows exactly what he's getting, and users can easily know if their hardware is or is not v.X compatible. That's incredibly more useful and important than being able to use extensions.

[elanthis]

Oh, and regarding patents: Microsoft already has patents that cover OpenGL 3.x. We're fucked either way. Either FOSS fights those and wins, or FOSS desktops are stuck with an ancient GL 2.x API missing various chunks of modern technology.

Look no further than S3TC to see how this already affects the FOSS graphics stack. The patents need to be fought, somehow. Avoiding them leaves everyone stuck in the dark ages. (This is pretty much true of any software patent, of course, hence why everybody here should contacting the USPTO by Monday to help start fixing this problem.)

[pingufunkybeat]

Thank you for a rare detailed and informative post on the topic.