Wine Devs Have Mixed Feelings Over Direct3D In Gallium3D

[dalingrin]

Just because people are now devolving into "did not", "did too" school yard level arguments....why do you believe d3d is nicer than OpenGL? And when answering this, please remember that some people still use C quite heavily.

http://phoronix.com/forums/showpost.php?p=149754&postcount=8

[mirv]

An interesting read, although I disagree with some points, notably about the so called "performance" differences - these come from implementations, and OpenGL has traditionally had higher performance. These days there's not really much difference.
Multithreaded rendering would be nice on an API level, but I would point out that it's most definitely not indicative of the hardware. Even in D3D11 it's still entirely in software. I will reiterate though that from an API perspective it's nice.
In a previous post I mentioned C for good reason. OO doesn't fit as well with C, and C is still quite heavily used, so it would seem that OpenGL would be better in that case.
As an API, it needs to be used with some language - has anyone given much thought to bindings with different languages, and how easy/difficult that is with each API? Something else to consider anyway.
What all this sums up to is: each API has pros and cons. One is likely better in some circumstances, another is better in other circumstances. Just like Java is nice in some areas, but it can't beat assembly in other areas.

[mdias]

An interesting read, although I disagree with some points, notably about the so called "performance" differences - these come from implementations, and OpenGL has traditionally had higher performance. These days there's not really much difference.
Multithreaded rendering would be nice on an API level, but I would point out that it's most definitely not indicative of the hardware. Even in D3D11 it's still entirely in software. I will reiterate though that from an API perspective it's nice.
In a previous post I mentioned C for good reason. OO doesn't fit as well with C, and C is still quite heavily used, so it would seem that OpenGL would be better in that case.
As an API, it needs to be used with some language - has anyone given much thought to bindings with different languages, and how easy/difficult that is with each API? Something else to consider anyway.
What all this sums up to is: each API has pros and cons. One is likely better in some circumstances, another is better in other circumstances. Just like Java is nice in some areas, but it can't beat assembly in other areas.

There's always the matter of tastes, and some prefer OGL over D3D, sure, but facts are facts; and elanthis took care of explaining why D3D was faster.

Now C vs C++ is a different matter that I could discuss simply by saying "C developers are stubborn and could use C++ instead since anything they do in C can be done in C++ but not the other way around without tons of useless code", but I'll just say that D3D has (or at least used to, didn't check recently, sorry) support for C.

[mirv]

You can't always use C++. Sometimes you have to use C. Sometimes you don't want to or can't use either one. A good developer uses the best tools available, and they aren't always the same. And if you don't believe that, then feel free to implement a full kernel in C++.
I've also read various points explaining why OpenGL is faster than D3D. Again however, that mostly comes down to implementation, and with current hardware it's a fact that you really don't see any difference anyway. There not really anything in either API that makes one inherently faster than the other.

[Remco]

There's always the matter of tastes, and some prefer OGL over D3D, sure, but facts are facts; and elanthis took care of explaining why D3D was faster.

So when OpenGL gains multithreading and direct state access, we can all move back to OpenGL again?

[mdias]

Sure, most of the speed gain/loss goes unnoticed and is heavily dependent on implementations.
Uhm, let's not change the scope of the subject, D3D is obvisually not gonna get used to create an OS kernel. What I meant is everything you can think of that uses OGL/D3D can be done in C++. You can build wrappers for other languages too after that.

[mdias]

So when OpenGL gains multithreading and direct state access, we can all move back to OpenGL again?

When OpenGL:

• supports multi-threading
• becomes stateless; all calls need a "context" object as input (or better yet, object oriented)
• becomes versioned
• gets a new extension system
• closely matches the underlying hardware rendering pipeline (connected with the OO part for prettyness/cleanness/readability)

yes, we can go back to OpenGL, though I doubt it will still be called OpenGL.

[mirv]

Sure, most of the speed gain/loss goes unnoticed and is heavily dependent on implementations.
Uhm, let's not change the scope of the subject, D3D is obvisually not gonna get used to create an OS kernel. What I meant is everything you can think of that uses OGL/D3D can be done in C++. You can build wrappers for other languages too after that.

On a PC, I heartily agree there (from a theoretical point of view), but I'm not sure what the status of embedded systems is, and whether anything using a 3D api there is still done in C or not.

[mdias]

On a PC, I heartily agree there (from a theoretical point of view), but I'm not sure what the status of embedded systems is, and whether anything using a 3D api there is still done in C or not.

You raise a valid point I cannot corroborate from experience, but from a logical point of view, if a platform is complex enough to have an OpenGL implementation, it will surely be given a C++ compiler... I hope...

[Remco]

OpenGL is going to have direct state access in some near-future version (yes, OpenGL has versions!). Actually, it already has an extension that does such a thing.

Why the need for a new extension system? Why OO? The procedural API works perfectly fine.