Do you know where babies come from? It's kinda disturbing, isn't it? I blame it on the global warming. Stay with me here and I'll lead you through this. 1) Storks deliver babies (fact), 2) I, not being very careful about how I word things cause global warming (also a fact), 3) global warming kills storks (my theory) 4) evolution takes over and replaces storks with the undignified system that we have right now (conclusion).
Speaking about not being very careful about how I word things, how about me announcing those DirectX state trackers coming to GNU/Linux in my last blog, eh? By the way, now that's a good transition. The announcement was very exciting, albeit a little confusing, in particular to myself. Likely because it's really not what I meant. Mea culpa!
What I was talking about is adding features to the Gallium interfaces that will allow us to support those API's, not about actually releasing any of those API's as state trackers for Gallium. Gallium abstracts communication with the hardware and the support for OpenGL 3.2 + few extensions and Direct3D 10.x requires essentially the same new interfaces in Gallium. So support for Direct3D 10.x means that we can support OpenGL 3.2 + those extra extensions. I don't think that it's a big secret that while we do have and are shipping Direct3D 9 state tracker and are working on a Direct3D 10 state tracker, to my knowledge, we simply don't have any plans to release that code. It's Windows specific anyway, so it wouldn't help the Free Software community in any shape or form.
I know there's that misguided belief that a Direct3D state tracker would all of a sudden mean that all Windows games work on GNU/Linux. That's just not true, there's a lot more to an API than "draw those vertices and shade it like that", windowing system integration, file io, networking, input devices, etc. If software is DirectX specific then it's pretty clear that the authors didn't use X11 and Posix apis to implement all that other functionality. Those windows.h/windowsx.h includes are pretty prominent in all of those titles. So one would have to wrap entire Windows API to be able to play DirectX games. That's what Wine is about and they're better off using OpenGL like they are now.
The issue with gaming on GNU/Linux isn't the lack of any particular API, it's the small gaming market. If an IHV would release a device that 500 million people would buy and the only programming language supported would be COBOL and the only 3D API would be PHIGS then we would see lots of games in COBOL using PHIGS. Sure, the developers wouldn't like it, but the brand new Ferraris that the company could buy, after release of their first title, for everyone, including all the janitors, would make up for that.
The bottom line is that the majority of games could easily be ported to GNU/Linux since the engines usually are cross-platform anyway, at the very least to support different consoles. DirectX, libgcm, OpenGL ES... either they're all already supported or could be easily made to support them. It's simply that it's not cost-effective to do so. A good example is Palm Pre which is running GNU/Linux and even before the official release of their 3D SDK (PDK) which uses SDL they already got EA Mobile to port Need for Speed, The Sims and others to their device.
On the other hand if a title supports only DirectX or only libgcm it's usually because it's exclusive to the given platform and presence of the same API on other platforms will not make the vendor suddenly release the title for the new system.
So yea, Direct3D on GNU/Linux simply means nothing. We won't get more games, won't make it easier to port the already cross platform engines, won't allow porting of the exclusive titles and will not fill any holes in our gaming SDKs. Besides ethically speaking we should support OpenGL, not a closed API from a closed platform.
22 comments:
So, what's the point? Why is this being written?
It's written for VMWare translating Direct3D calls of Windows guests to something they can use on the host system.
And it could be uses for creating OSS video drivers for Windows/ReactOS...
I think you're exaggerating to cover the wrong statement you made in your previous blog post.
Non of the consoles (PS, Wii, Xbox) use OpenGL, and penGL ES is for embedded systems. Also, most of the mainstream titles doesn't have MAC OS ports so stating that game engines are cross-platform (including linux) is just plain wrong.
Furthermore, we have indie games. It's a pretty productive industry and they would *LOVE* the idea of a true cross-platform Direct3D API. Linux community would certainly not object to that.
I understand that you're not the one responsible of this decision and I also understand that you are pro-opensource but please stay with the facts.
BTW, buying an open-source friendly company like Tungsten Graphics and make them create proprietary code is a superb idea. Way to go VMWare, take anything and give nothing back to the community.
@Anonymous: First of all, do me a favor and quote me that "wrong statement" that I made in my previous blog post. If you're going to accuse me of something, then it'd be good if you didn't just make it up.
Second of all PS3 does use OpenGL ES, it's just that many developers prefer libgcm since they can get more performance out of it that way. I never mentioned Mac, so I'm not sure where you pulled that from. In case you were confused about consoles they don't all run Windows. And in case you were /really/ confused libgcm is not DirectX so just having a game/engine that works on XBox360 and PS3 already makes it cross-platform.
Third of all speaking on behalf of an entire community of developers as "Anonymous" is ridicules.
Fourth of all "take anything and give nothing back to the community" is just silly and betrays how little you know about anything you're talking about. Who's by far the largest Mesa3D contributor right now? The company name starts with a V, then there's a M, and ware.
But flat out lying is easy when you're anonymous, isn't it?
I suspect this will still (albeit indirectly) benefit free software in the long run by removing the need to dual-boot for a lot of gamers. VMware 8.0? Zack - can you not confirm or deny? ... ... Thanks, much obliged.
@Anonymous: I can't talk about the schedule or make promises as to the version numbers, we have a whole department for that :) But yes that's certainly one of the goals. Gallium should allow us to accelerate any graphics api on any platform, but because of the sheer market size Windows apis tend to be very important.
To be honest though, the biggest benefit of this work is not indirect - all those features directly translate to support for new versions of OpenGL and soon OpenCL. As we work during our work hours to support Direct3D features, we're adding to Gallium exactly the same features we'll need for new versions of GL and CL.
The features I mentioned in the last blog are great examples of it as they both will have far reaching implications for Free Software graphics.
Hi Zack.
I really like your take on this. D3D doesn't belong in Linux.
Can you give an update where progress is happening in Gallium? It have almost been 3 month since last update on
http://www.x.org/wiki/GalliumStatus
Anything you can share with us?
Louise
we simply don't have any plans to release that code. It's Windows specific anyway, so it wouldn't help the Free Software community in any shape or form.
There are many open source projects that could benefit.
Thinking reactos already takes advantage of your existing open source offering on windows. This one will directly benefit.
Next is open source virtual machines. Yes I know you your competition. KVM/QEMU, Virtual Box, XEN just to name a few. All run windows inside. Remember KVM is part of the Linux kernel. So the claim there is no gain to Linux is wrong.
Now galluim3d has the idea of unifying the graphic stacks. Why not also unify the virtual machine graphical stack interface. This will make virtual instances more transferable.
Now even that wine would not be able to use your driver directly. Having it as a reference would be useful to wine developers if they decide to do a migration to a galuim3d. Remember wine does support more than 1 graphics emulation layer. So could keep it existing wined3d and winex11 and have another along side doing galuim3d. Really this would be beneficial to both galuim3d functions used in direct X would get tested more.
FOSS claim of no benefit is nicely not true.
Now what is it. You want a benefit over your competition? or Microsoft has placed some conditions on you that you cannot? or The person who made the selection to close source the driver did not think this everything through so made wrong option?
Any or all of the 3 most of US have no problem in the FOSS world. Truth is more important to us.
The no use excuse is common as an attempt to justify other motives and sound good to the rest of the open source world. No use I have never seen to be 100 percent true.
Everyone would love codeweavers interface open source. But codeweavers does not say it no use. Instead they truthfully say it for commercial grounds.
@Anonymous: Another person without a name being rude on the internet? Surely not! I won't believe it!
Yes, it's disgusting how we won't release implementation of a closed api for a closed platform to support closed apps to help Free Software. I'm ashamed for the entire team how we dare to not release that closed state tracker, for the closed api, for the closed system for the closed programs to rock Free Software.
We do it, especially the part of how we're the most active contributors to Mesa3D/Gallium to finally kill all the puppies (we just don't like them), increase global warming, enslave the turtles (they're weird looking) and, being completely inexperienced in what Free Software is, to get great unethical lessons about ethics of Free Software from anonymous people on our blogs.
I think we're gonna end this discussion now, I feel like I'm cutting into your "government hiding alien invasion" conspiracy finding time, plus Elvis/Bigfoot will not just find themselves. Go where you're needed.
I'd actually like the DX API on Linux because it _does_ help portability. Just because you're using Direct3D doesn't mean you're using Windows APIs for everything else. We've got Direct3D+SDL+FMOD with a custom cross-platform network library on one of our projects. The only thing we'd have to make (major) changes to to port to Linux or OS X is the Direct3D portion.
Porting from D3D to OpenGL is also a lot harder than the reverse. With D3D, you have a fixed set of features for a particular version, and you can just write your code and be done. For OpenGL, many common implementations are still using half-assed incomplete 2.1 (or lower) profiles and you have to hunt and peck for dozens of extensions to get similar functionality. OpenGL is more flexible, but we don't _need_ flexibility -- we just need it to work. I stick with OpenGL in my personal stuff because portability matters, but in the professional world, not one single major gaming platform uses OpenGL. The PS3 may have OpenGL ES but nobody uses it because it sucks on that platform, the Xbox and Windows are D3D-only, the Wii uses a custom library, and the handheld are mostly using fixed-function OpenGL ES 1.0 (but it doesn't matter, because you can't port something like Assassin's Creed to the iPhone with just a simple change in graphics library; the whole damn thing has to be rewritten and reduced in scale and gameplay to make up for numerous other handheld limitations compared to a PC). So sure, a cross-platform game might already have three renderers, but then why force people to add a fourth when they've already got those three? The fact that the Wii and PS3 use something besides D3D just makes it less likely that a developer will support them, which is why Windows and the Xbox dominate the gaming market right now (for non-casual games at least, which are totally different beasts from the casual games that Apple and Nintendo dominate).
To put it bluntly, D3D is just better than OpenGL from a developer's standpoint. Plus, although it's not directly related to the API, D3D has so many better tools for developers than OpenGL has ever had (or ever will, given the complete lack of effort put into them). Once you've used pix or NVperfHud (both D3D exclusive) there's just no going back to the crap tools the OpenGL camp is saddled with. My school actively discourages students from using OpenGL specifically because the students are pretty much up shit's creek with bugs while the kids using DirectX have tools that can almost literally say, "hey, your mistake is right here at this line, and here's how you should fix it."
I don't really have a problem with Microsoft controlling D3D, because they can't do anything with it to hurt Linux, other than just continually making it better than OpenGL and making D3D so attractive an option for game developers. There are potential patent issues, but OpenGL already suffers from those and that already is an issue for FOSS implementations (look at some of the recent issues over OpenGL 3 and patents). I'm less interested in retarding technology out of fear of patents and more interested in spending that effort lobbying to outlaw software patents (which naturally the vast majority of FOSS users refuse to do despite it only taking minutes of your time a week for minimal support).
Your employer has probably made up its mind and that's final, but it's just silly to claim that Direct3D on Linux is useless. Sure, apps will still need porting, but they'll need less of it and the Linux ports could benefit from the otherwise Windows-only/DirectX-only tools that simply have no remotely-close OpenGL equivalent.
As a quite further addendum... I'd freaking love to see those kinds of tools released as FOSS with OpenGL support. One thing I hope Gallium3D will allow (and that some very very nice company will fund) is top-notch OpenGL debugging tools that can do the things pix and nvPerfHud do. Won't eliminate the need to port or OpenGL's loose standards and support, but better tools will at least remove some of D3D's edge.
I'm ashamed for the entire team how we dare to not release that closed state tracker, for the closed api, for the closed system for the closed programs to rock Free Software.
Zack companies supporting open source still have to make a profit.
You are making out that the team is guilty some how. You are not right. Anyone who truly believes in Open Source Software has to except a person right to release code under the license of author/companies choosing.
The big problem here is the so called closed system is being cloned. So the so called closed api is no longer completely so. Reactos a clone. LUK is also another. So you justification so again is wrong. This suggests both have been overlooked when it was decided to go closed. This could be a simple case of Opps we were not aware or forgot this other stuff existed.
Or worse you are being a PR guy Zack and don't want to say that it is for commercial reasons because that might seam bad. Lots of companies in the open source world do things for commercial reasons. Lieing is not helping anyone.
Commercial reasons answer allows everyone to go ok that is the way it will be in future and move on. While is answered that it could be a oversight it has to be questioned. Sorry.
Some of the issues with docs release by AMD about ATI cards have been tied up by restrictions from parties including MS. So asking if that is the case with the vmware driver thinking both companies are producing Direct X drivers is a fair question.
Could be a simple case you don't have the time to confirm the legal status as well.
Basically if there is something truly locking you from releasing the code no blame can be placed on you. Again this is being truthful. If there are locks blocking you doing something for FOSS if FOSS supporters know they can try to get them removed.
But if we don't know we cannot attempt todo something to address.
If you want to keep it for commercial grounds closed. Nothing wrong with that either. Redhat does not release everything open. All open source companies have a percentage of stuff they normally keep under wraps.
Simple point here so far your justification has holes. Zack Rusin. Get your justification right
Now that I posted Anonymous does not make my statements false.
I do want to be mean. If you don't want Anonymous posts that posting option can be disabled Zack. No point complaining about people posting Anonymous when you are in control of if they can or cannot. Its very much like having a open door party then blaming the people who come for stuffing your house.
This avoiding of responsibility for own actions is what has caused me to post in the first place Zack. Nice to see that it is also in your own personal responses so most likely not vmwares problem.
So I will wait for either you to grow up in accepting responsibility for actions and answer correctly without trying to smoke screen the real status.
True that. The way you're fighting for that closed api makes you a true champion of Free Software.
I don't know what I was thinking we need more closed APIs on GNU/Linux. The only way we can succeed is by supporting all closed source APIs! They all are super valuable and have so much benefit, that instead of working on open standards we need to focus on releasing all closed source apis! I don't know what I was thinking.
I take solace in the fact that you anonymous guy are a true master of Free Software graphics, while I am a lowly PR guy. Your incredible opinions are just so much valuable than the silly things I do, like writing software.
Really you should be spending more times implementing Windows apis in the open rather than bother with me.
Zack, Thanks for the info. I can't believe some of the comments you've gotten on here to the tune of, "You have to open sources."
The one thing that bothers me about the Internet is that there can be large crowd of people that are happy about what someone is doing, but somehow only the few unhappy people stick out and really ruin that person's mood and make them wonder why they even bother.
I just want to say your work is appreciated and really all open source work is appreciated by someone. Just think, your work makes people smile :)
I think VMware should consider releasing the DirectX state tracker at least with a restrictive license, such as "no commercial usage".
Being able to look at it would allow Mesa/Gallium developers not employed by VMware do a better job by having a better understanding of how Gallium is used (and what requirements the DirectX API places on it).
And of course, Wine could use it to spend less CPU time doing API translation and you may get code contributions from the Wine community.
What is the business reason for not releasing it?
Desire to prevent competing virtualization vendors from using it?
Hope of being able to license it to GPU hardware makers?
I understand and agree with your point that D3D has no place on any Linux operating system, but I'm not quite sure what's wrong with open-source drivers on Windows. (And for brevity's sake I will not even mention ReactOS.)
I think that, even if this state tracker stays on Windows (*especially* if it stays on Windows,) this could be a massive benefit to all operating systems. Suddenly, Gallium3D becomes a viable option for big graphics card vendors like ATI and nVidia. If they don't have to reimplement D3D themselves, this already makes it easier for them to write a new driver. Plus it also makes their driver much more cross-platform, which indirectly improves hardware support on other operating systems. While releasing the source code to this state tracker isn't a requirement for this benefit to happen, IMO it would be a good move anyway and it wouldn't cost VMware anything (unless I'm missing something.)
If releasing an Open Source driver stack for a closed-source operating system is of no benefit to the Free Software community, then I suppose we'd better stop putting out OpenOffice, VLC, and Firefox versions for Windows? Clearly, those Free Software projects are very important, but would they be as important if they didn't run on Windows? A graphics driver which doesn't support D3D cannot really claim to support Windows. Right now, Gallium3D is of no consequence on Windows, thus it is of relatively little consequence overall (sad but true.) By having an Open-Source driver stack that supports Windows (including D3D,) G3D could imitate the great success story of, say, WebKit. Sure, drivers are more of a specialty item than browsers, but I'm confident that the basic ideas are the same.
-Max.
I can understand it. VMWare wants to get benefits for their work. Gallium3D is still a good framework and I hope to get rid of closed source drivers with it (I would like to use KMS, RandR with Nvidia). But thats all, Gallium3D is not a holy cow.
All I have to criticize is that this wasn´t said or made clear earlier. They should have known that the OS-community think it would be free and for Linux too.
I can not talk about personal experience as my field is somewhat unrelated but hearing what classmates involved in the game industry tell me, your post is _absolutely_ correct.
And the anonymous troll that is wandering around, lots to tell you but I have some opensource code to write, no time for you.
I wonder, where does such a state tracker live? Kernelspace or userspace?
There's a lot of good synergy between virtualization, Gallium3D and WINE.
Yes, WINE has a different focus. But WINE seems to have the worst compatibility with gaming. WINE can benefit tremendously, I think, from Gallium, albeit at a further performance cost.
I want to play my older games on Linux, especially since they are not supported in Windows, anymore.
But in the future, I want people to realize that they can develop for Linux for a relatively small cost - especially considering how many PC gamers are computer geeks and FOSS enthusiasts.
We only need (or want) DirectX for now. All of us, I think, are waiting for better things to come along. Gallium helps us get there.
Zack,
Im unsure if you got my last message so I wanted to send it again. You posted a reply onhttp://labs.trolltech.com/blogs/2008/11/15/flick-list-or-kinetic-scrolling/
about having seen kinetic scrolling with bounce -
Jacek wrote the code for this two years ago. It’s in dev/research/minibrowser, or at least was (also, his version supported bouncing on edges)
Can you please point me to where I can find this code?
Post a Comment