Tell us what you need, and we'll leak it.
Works for me![]()
Phoronix: The Linux GPU Documentation That's Needed
A week ago we shared that the first of the slides and videos from VMware's recent Gallium3D workshop were now posted on the Internet. This morning some more of this content is being published, which covers the VMware SVGA driver status, a Gallium3D state tracker overview, and the status of the OpenGL ES state tracker...
http://www.phoronix.com/vr.php?view=NzgwNg
Tell us what you need, and we'll leak it.
Works for me![]()
Video summery: OpenCL, soon. D3D, not soon.
I imagine having Direct 3D on Linux would make WINE developers very happy
I wonder, if they are in favour of that, and maybe supporting it...
I signed up just to respond to this because it's probably the biggest obstacle I've run up against when trying to get involved with X testing and development.
One thing that would be helpful is perhaps some good pointers on books that could teach me how graphics cards and X work. C has the "K&R C" book. The Linux kernel has "Linux Device Drivers" and probably more. Is there something analogous to these fundamental books in the open source graphics drivers world?
Another thing which might have less to do with documentation and more about packaging. It would be nice if there was an easy way to build an entire X stack, without all of the dependency hell. Perhaps distributions could add a metapackage that pulls in all of the development packages needed. If something like this already exists, then it sure would be nice to know.
Another thing is the freedesktop.org and x.org websites. I'm never sure which I need to go to when looking for information about the various layers of the graphics stack. I'm not trying to be nit-picky. I'd really like to help with the graphics stack, but some of these barriers make it pretty tough to get started.
No, it won't. That's a common myth, but it's false. It would make them happy if it allowed them to ditch their D3D->openGL wrapper, but it doesn't.
First of all, Wine is supposed to run on linux, macos, *bsd and solaris. If only one of these platforms starts supporting D3D natively, they haven't gained anything at all. I can imagine *bsd getting support (eventually), but D3D on macOS just isn't going to happen.
Second, the wrapper is being used outside of wine, for example for Virtualbox's accelerated rendering - only openGL can be accelerated on the client, as such D3D has to be translated first.
Hence the wrapper will continue to be needed for quite some time, both inside and out of wine, and a native D3D interface doesn't help at all.
There is one group that may be interested in a native D3D interface, and that's companies attempting to port games to linux. But as D3D is closely connected to other windows-specific APIs, I'm not sure how much work it really saves compared to just rewriting the rendering pipeline in OGL.
Besides, why would we want to be strapped in to a reverse-engineered implementation of a Micro$oft-controlled system? Using OpenGL (for all 3D applications on all platforms) would be the easiest thing for everyone.
Okay, that was some quite good arguments, that I hadn't really thought of.
Sadly we can 100% sure that Oracle will stop development of VirtualBox, once they acquire Sun. Oracle already have 4 or 5 virtual machines. Most of them are Xen based, like their own Oracle VM.
It wasn't too long ago, they bought a small, but very promising Xen virtual machine company, and killed it afterwards.
Getting VirtualBox is just perfect for Oracle. One less competitor to worry about.
It is a trade off with Oracle. They are VERY pro Linux and open source, in the areas, where it benefits them, and for rest rest, they rip, slice, shred, and kill the rest, in a way that makes even Balmer say, "That's enough."![]()
I thought they were talking about D3D for Windows guest OS, not for Linux. Did I miss a juicy comment somewhere ?