Right... Apart from the fact that this is a tad* unrealistic, don't you think it'd be easier to improve existing drivers rather than writing d3d drivers from scratch?
* hint: sarcastic understatement.
I'm sorry but that attitude is pretty stupid. After all if everyone had that attitude then many of the things we have today wouldn't have been made. After all it would have been easier to not make anything new and just improve what we had.
I love how you told that to a guy taking (took?) theoretical physics
(07-17-2013, 06:03 AM)ExtremeDude2 Wrote: [ -> ]I love how you told that to a guy taking (took?) theoretical physics
That post had nothing that helps this thread.
This thread has nothing that helps anyone. If you want to prove your point to people who know a lot about graphics API and graphics drivers, please do so by providing data, not assumptions.
If your next post does not provide data/facts proving that a D3D implementation on Linux would help speed, I'll just close this thread. Too much noise, not enough signal.
(07-17-2013, 06:23 AM)delroth Wrote: [ -> ]This thread has nothing that helps anyone. If you want to prove your point to people who know a lot about graphics API and graphics drivers, please do so by providing data, not assumptions.
If your next post does not provide data/facts proving that a D3D implementation on Linux would help speed, I'll just close this thread. Too much noise, not enough signal.
Whatever, this thread wasn't about a speed up. Mostly about a concept. The side effect was that it
might give one. Close this thread if you really want to.
(07-17-2013, 06:28 AM)DatKid20 Wrote: [ -> ]Whatever, this thread wasn't about a speed up. Mostly about a concept. The side effect was that it might give one. Close this thread if you really want to.
Most people asking for D3D on linux only ask because they think it'll magically speed up emulation, which is why we usually assume that it's the motivation of suggesting such things.
Speaking of the concept itself, people have proven uninterested in making D3D on linux a real thing. There's a Gallium3D state tracker (which, I think, is even used in VMWare or VirtualBox, can't remember which one) implementing D3D but IIRC it's closed source. The open source community failed to show any interest in maintaining the open source D3D state tracker that appeared some years ago.
Phrases like "hey, this is linux - someone eventually will go ahead and do it!" usually come from the kind of people who aren't doing the actual work. OSS developers need some kind of motivation for their work and, frankly said, a D3D runtime for linux has close to zero motivation.
I don't get why. A lot of the people in the community complain that game developers don't code for linux. If they helped then wine could have a better directx implementation and games would become closer to native speed.
Apparently d3d1x has been implemented to the drivers for the 500 series.
And VMware uses gallum3d
One last thing, Does anyone know of a good website to learn about the code used to develop Dolphin?
It's not as easy as that. OpenGL is the least problematic part of the picture. Most game devs already wrap their GPU API usage around abstraction layers, so if it was only about OpenGL support it'd be easy to just add another graphics backend. Blizzard has added OpenGL support for many of their games, yet we still haven't seen a linux client for any of their games. Heck, they even had a full linux client for World of Warcraft, but they never released it. Also, if it was only about OpenGL, why don't all those games with an OSX port run on Linux?
A different thing is optimizing Wine's D3D implementation. Short story: Even if there was any D3D runtime on linux and support for it via open-source drivers, Wine devs still wouldn't make use of it. Wine has one of the most dictatorial development models I know of (which isn't necessarily a bad thing, but here it is), so it won't change a piece about it's current approach of implementing D3D on top of OpenGL. It has happened in the past that people went ahead and did huge pieces of works that never were merged into the Wine tree because of this.
EDIT: Responding to your edits:
http://www.phoronix.com/scan.php?page=news_item&px=MTMyNDU <-- the d3d state tracker you're speaking of has been killed meanwhile.
http://www.phoronix.com/scan.php?page=news_item&px=Nzk3NA <-- not sure if this has changed meanwhile, but this suggests that VMWare is working on their own D3D implementation internally (and that it'd be useless for the open source community anyway)
(07-17-2013, 06:45 AM)neobrain Wrote: [ -> ]It's not as easy as that. OpenGL is the least problematic part of the picture. Most game devs already wrap their GPU API usage around abstraction layers, so if it was only about OpenGL support it'd be easy to just add another graphics backend. Blizzard has added OpenGL support for many of their games, yet we still haven't seen a linux client for any of their games. Heck, they even had a full linux client for World of Warcraft, but they never released it. Also, if it was only about OpenGL, why don't all those games with an OSX port run on Linux?
A different thing is optimizing Wine's D3D implementation. Short story: Even if there was any D3D runtime on linux and support for it via open-source drivers, Wine devs still wouldn't make use of it. Wine has one of the most dictatorial development models I know of (which isn't necessarily a bad thing, but here it is), so it won't change a piece about it's current approach of implementing D3D on top of OpenGL. It has happened in the past that people went ahead and did huge pieces of works that never were merged into the Wine tree because of this.
Can't people make their own branches of wine? Like cedega?