Wine Devs Have Mixed Feelings Over Direct3D In Gallium3D

[Yfrwlf]

Actually, if MS gives D3D over to a standards body with transparent decision-making, and revokes all their patents relating to the technology, I'd accept D3D immediately.

But this is not going to happen in this lifetime. MS wants to control the spec AND the implementation, and they want to use their patents to kill off their competition. This is pretty much the essence of their business. And exactly why nobody is following their "standards".

Do we have .Net on the Mac? Do we have Direct3D on the Mac? No, it's Java and OpenGL. Steve Jobs is not an idiot.

It's just like Office Open Document Format, there's going to be some places where it hooks into the bigger core Windows software stack, and you're going to need to reverse-engineer critical key components in order to stay on-par with D3D on Windows systems. Even if this isn't implemented now in D3D by Microsoft, no doubt it can be implemented in the future especially if they get everyone on their bandwagon. Of course this will all cause those wanting to implement D3D to tread on a dangerous patent minefield.

So even though I'm not a lawyer, it's pretty easy to see by anyone who knows a thing or two about how businesses work now days and how Microsoft operates, and I'd have to agree with pingufunkybeat. HOWEVER:

If you knew that this was a risk, you could attempt to isolate the potentially infringing parts so that patent suits couldn't attack your whole project or whatnot (would be silly, and again I'm no lawyer, but you get the jist) and then let whoever wants to use D3D to include Linux users do so knowing the threat or difficulties that D3D may have on the non-Windows platforms. If you're a developer and you know about those problems, you should ask yourself if you really want to even try that route at all. If the answer is no, because Microsoft is pulling a bunch of annoying crap on non-Microsoft platforms, then you use OpenGL, help advance OpenGL, or help advance an OpenGL alternative.

So, yes it most likely is "a trap", hehe, but you can never completely trap open source advancement and while it may be a waste of time to focus on things which are ultimately controlled by Microsoft (legally, at least) if there are those around who really want to support those things and waste their time, that's their choice. Everyone else: focus on advancing OGL or an alternative then.

[V!NCENT]

You can't isolate D3D and 'just' remove it later because like I already said; it's a building block. If accepted, it is going to be used to make applications _with_, so if you dump D3D then you dump these apps too.

So hell NO!

BTW if we get acceptable OpenGL support, which means OpenGL 4.0, all problems vanish and we can forget about this whole D3D thing.

Sure; it's somebodies hobby project. I'm not against that, but mainline inclusion is a whole different aspect.

And to all those people bitching about hwo much OpenGL sucks compared to Direct3D; it's a result of large companies whish, so it's the direction of the graphics industry. Nobodies perfect, but because everything, except consumer games, gears towards OpenGL, let's not go ahead and ignore everyone else.

[mdias]

It's just like Office Open Document Format, there's going to be some places where it hooks into the bigger core Windows software stack, and you're going to need to reverse-engineer critical key components in order to stay on-par with D3D on Windows systems. Even if this isn't implemented now in D3D by Microsoft, no doubt it can be implemented in the future especially if they get everyone on their bandwagon. Of course this will all cause those wanting to implement D3D to tread on a dangerous patent minefield.

So even though I'm not a lawyer, it's pretty easy to see by anyone who knows a thing or two about how businesses work now days and how Microsoft operates, and I'd have to agree with pingufunkybeat. HOWEVER:

If you knew that this was a risk, you could attempt to isolate the potentially infringing parts so that patent suits couldn't attack your whole project or whatnot (would be silly, and again I'm no lawyer, but you get the jist) and then let whoever wants to use D3D to include Linux users do so knowing the threat or difficulties that D3D may have on the non-Windows platforms. If you're a developer and you know about those problems, you should ask yourself if you really want to even try that route at all. If the answer is no, because Microsoft is pulling a bunch of annoying crap on non-Microsoft platforms, then you use OpenGL, help advance OpenGL, or help advance an OpenGL alternative.

So, yes it most likely is "a trap", hehe, but you can never completely trap open source advancement and while it may be a waste of time to focus on things which are ultimately controlled by Microsoft (legally, at least) if there are those around who really want to support those things and waste their time, that's their choice. Everyone else: focus on advancing OGL or an alternative then.

True, even if I can't think of anything they could do like that. That's why I say the best option is to have a whole new API.

And to all those people bitching about hwo much OpenGL sucks compared to Direct3D; it's a result of large companies whish, so it's the direction of the graphics industry. Nobodies perfect, but because everything, except consumer games, gears towards OpenGL, let's not go ahead and ignore everyone else.

It's the result of everyone just sticking with whatever exists. What good is OpenGL's openness if only the big industry players have a say on it?
It appears few developers are happier with OpenGL than they'd be with something comparable to D3D, so why not create a new API?

[BlackStar]

BTW if we get acceptable OpenGL support, which means OpenGL 4.0, all problems vanish and we can forget about this whole D3D thing.

I'm kinda worried about this one. SGI (now Microsoft) owns patent #6,650,327 patent for floating point textures/framebuffers (OpenGL extension spec), which is necessary for GL3.x+ (and arguably necessary even for modern 2.x apps: fp textures are a prerequisite for high quality shadows and high dynamic range).

I don't know if this can be somehow circumvented, e.g. by offloading all pertinent functionality to the hardware and disallowing CPU-side features (this approach was proposed for a limited - but compliant - form of S3TC support). Maybe it is, maybe it isn't, but it's more than likely that any modern GL implementation might infringe one patent or another. It doesn't matter whether OpenGL is or isn't "open" - the danger is always there.

[V!NCENT]

If OpenGL 4.0 is realy such a big problem then you could create a new API.

But, this is going to be a pain in the ass. The graphic stack is already behind on performance with the binary drivers. With all the Khronos API's flying around and having the performance benifit of shared functionality when all run at once on a GPU, this new not-GL API could impose serious performance hits allround.

So maybe no; maybe this new non-existant API is going to do more harm than good, with the only 'benifit' going to the coder, which is not needed given the already vastly available engines and Compositing WM's already in place.

[Yfrwlf]

What I meant is that being against Microsoft just because it's Microsoft isn't a valid argument.

I just thought I'd chime in here for a sec and say that actually it is a valid argument if you have morals. I know that corporations love to perpetuate the notion that they cannot be ever held responsible for any of their actions because they are corporations, and to that I say %@#% them. Microsoft deserves every tiny shred of dislike anyone can muster. The big shreds, too. They didn't stop what they were doing and seek penitence, they can and are continuing the same behavior.

[NoEffex]

Microsoft won't sue Linux companies (Since they can't sue regular owners..well, they could try, but it would never culminate into anything) because it would bring publicity to Linux which is exactly what they don't want to do.

It's like .NET. They endorse mono to look good. Everyone knows that if they could sue Novell and such over it without bringing publicity they would - but they can't.

[kayosiii]

In case that isn't obvious, OpenGL used to be the dominant graphics API back in the '90s (Glide, S3 Metal and D3D were just bleeps on the radars). Developers started moving to Direct3D around version 5 and all but abandoned OpenGL around D3D7. This wasn't due to Microsoft pressure but simply because developers found D3D easier and more efficient to work with. Outside Id software, OpenGL was only used for cross-platform ports.

This may or may not change but you cannot deny that modern desktop 3d hardware is designed with D3D in mind, rather than OpenGL.

That's not entirely true... Even when OpenGL was more popular most graphics card manufacturers (and there were a lot more in those days) either didn't do OpenGL drivers or sucked at them. You simply couldn't reach a lot of your audience by going OpenGL alone and doing just DirectX is a lot easier than doing both. Of course DirectX does suck a hell of a lot less than it used to and I have to admit that it currently sucks less than OpenGL.

The point about hardware not being designed for OpenGL is not entirely true either. nVidia is very OpenGL friendly, ATI less so (intel is pretty fecking hopeless at anything 3D). The ecosystem is somewhat different though so vendors release their hardware specific extensions (in which the features tend to be available before they are available in Direct3d). If the feature is picked up by other hardware manufacturers it will tend to make it to being an ARB extension (usually sometime after the feature is available in Direct3D) and eventually into the OpenGL core. This process takes a lot longer than Microsofts aproach and understandably many developers would rather not code seperately for each video card manufacturer but the new hardware features tend to end up there first.

[kayosiii]

No, there were certainly no tesselation or hull shader extensions on OpenGL before OpenGL 4.0 was released.

You are either misinformed or deliberately misleading.

I am not sure about OpenGL 4 but Tesselation was available as an ATI specific OpenGL extension before DirectX11 was released.

[NoEffex]

I am not sure about OpenGL 4 but Tesselation was available as an ATI specific OpenGL extension before DirectX11 was released.

ATI specific being the key.

You shouldn't have to write different code per graphics card manufacturer. Your code should be able to work on any card that supports the "standards" because they are standards and should work. However, OpenGL is very non-standardsy.