Direct3D 9.0 Support On Track For Linux's Gallium3D Drivers 55
An anonymous reader writes Twelve years after Microsoft debuted DirectX 9.0, open-source developers are getting ready to possibly land Direct3D 9.0 support within the open-source Linux Mesa/Gallium3D code-base. The "Gallium3D Nine" state tracker allows accelerating D3D9 natively by Gallium3D drivers and there's patches for Wine so that Windows games can utilize this state tracker without having to go through Wine's costly D3D-to-OGL translator. The Gallium3D D3D9 code has been in development since last year and is now reaching a point where it's under review for mainline Mesa. The uses for this Direct3D 9 state tracker will likely be very limited outside of using it for Wine gaming.
Costly? (Score:3)
Maybe it's because I tend to play old games, but my perception of it hasn't so much been costly as explodey. Or sometimes it just draws stuff wrong, but I can mostly live with that.
Re: (Score:2)
RTFS.
allows accelerating D3D9 natively by Gallium3D drivers and there's patches for Wine so that Windows games can utilize this state tracker without having to go through Wine's costly D3D-to-OGL translator
(Emphasis mine.)
Re: (Score:1)
Yeah, you have to pay $2 every time you launch an app that uses the D3D-to-OGL translator in WINE [capitalized due to it being an acronym...or possibly a synonym...maybe an acronym...some kind of nym].
Re: (Score:3)
I think the idea behind the it's a compatibility-layer not an emulator thing is to emphasise that it doesn't emulate the underlying CPU architecture.
Want to use Wine to run Windows programs on Linux-on-ARM (MIPS/PowerPC etc)? That's beyond the scope of the Wine project. [winehq.org]
Re: (Score:2)
But yes the idea is to be a translation or compatibility layer to expose windows API's to windows PE's.
Re: (Score:2)
But unlike windows Linux doesn't have to drag along all the legacy binary support for some of the lower layers.
Is D3D 9 advantageous over 10? (Score:2)
Re: (Score:2)
That D3D10 state tracker never made it past an early prototype and, I think, Mesa/Gallium is still lacking for D3D10 support (it doesn't support OpenGL 4.x either yet).
Re: (Score:3, Informative)
Apparently up to this point in wine D3D 10 had more complete support than D3D 9 [wikipedia.org]. Is there a reason why it would be useful to make D3D 9 support more complete? I understand that this article goes beyond Wine.
If you have a working D3D 9 implementation, you've also covered practically everything needed to support D3D 5 - 8 as well. This will get you pretty good coverage of games and other 3D apps released from 1998 to at least 2011.
D3D 10 was a significant break from both the API perspective and in terms of how it works underneath. D3D 10 was included with Vista but never made available for Windows XP (because it relied on kernel changes and a new driver model that couldn't be backported) so game developers too
Re: (Score:2)
D3D 10 was a significant break from both the API perspective and in terms of how it works underneath. D3D 10 was included with Vista but never made available for Windows XP (because it relied on kernel changes and a new driver model that couldn't be backported) so game developers took their time in moving to it.
Not only that, the Xbox 360 also used something that was fairly close to DirectX 9 (in the same way the Xbox One uses an API close to DirectX 11), so it made sense to reuse the 360 version for PC with a few tweaks here and there. Certainly much easier than rebuilding for the vastly different DirectX 10 API.
With the arrival of the new console generation, we're seeing a sudden (and very welcome!) shift to DirectX 10+ and 64-bit executables.
Re:Is D3D 9 advantageous over 10? (Score:5, Informative)
Is there a reason why it would be useful to make D3D 9 support more complete?
Games only started using D3D 10/11 *very* recently -- the back catalog this could enable is huge, and D3D 9 games are still coming out today. It'd say it's very important to support.
Re: (Score:2)
Games only started using D3D 10/11 *very* recently -- the back catalog this could enable is huge, and D3D 9 games are still coming out today. It'd say it's very important to support.
Bullshit. Almost all games have had an D3D 9 rendering path since XP has been so massively popular, but a whole lot of games has taken advantage of D3D 10/11 where it's been available. It's very important to the number of games you can run on Linux, but it does not represent the state of the art. Speaking of which, WINE's support of D3D 9 through an OpenGL has been pretty good. Or rather my impression has been that if they can figure out what DirectX is doing, there's usually a fairly efficient way of doing
Small percentage (Score:5, Informative)
This support in mesa will allow these games to be ported more easily, rather than forcing a rewrite in a major portion of any game engine, the display layer.
This won't help much for porting. It only works for drivers that work on Gallium3D. Thus, it only works on Radeon and Nouveau (and the alternative Gallium3D powered ILO. The official Intel runs on classic Mesa).
So only a very few end users will be affected. It's not worth counting on Gallium Nine for the port, as you're missing the big part of users who instead run the proprietary and/or official drivers (specially since Nvidia's blob has way much better hardware support that the reverse engineered Nouveau - due to lack of documentation).
On the other hand, Gallium3D give a nice and faster route for Wine, so a few select users can get straigh Direct3D support instead of going through a transaltion layer. So it's a relative benefit for Wine itself.
The developer can even choose to go the wine route, and simply provide a wrapper for their product, such as Star Trek Online uses with thier Mac port.
That has technically been possible before the Gallium Nine driver, anyway. The presence or absence of this driver don't change the feasibility of such ports. It only makes them faster for a few select users by removing translation layers.
This may be hugely important for the Steam Box initiative.
Well, depends. I doubt that, when it comes out, it will rely on opensource drivers. At least not for Nvidia hardware: the difference of stability and hardware support isn't worth the effort.
On the other hand, if AMD get their shit together in time, and release the hybrid closed/source driver as promised (i.e.: you run the opensource kernel driver "amdgpu". Then, as an OpenGL implementation, you're free to use either the opensource Mesa Gallium3D driver or the Catalyst driver which will only be a GL+CL library running on top of the exact same opensource base), you might see the possibility of AMD Steamboxes that let the user switch between the two GL implementation on the go. That could mean using opensource GL/CL for the interface and for a few select game that need DirectX, and switching to Catalyst GL/CL for games that need GL 4.x, with Steam maintaining a database of which version runs better for which game and handling the switching without need of user intervention.
Over all, Direct3D is a much simpler and lower level API (at some point of time it was considered to be a back-end to be targeted by openGL drivers) so it would be supported faster than openGL and would give definitely a performance boost.
Also, specially if AMD releases Mantle for Linux (or if it becomes "OpenGL Next"), that might attract the interests of some multi-platform developers: such AMD powered Steamboxes would be closer to the hardware found in other consoles (AMD APU or GPU in all other consoles of this generation) and might help PC ports (at least on AMD it might get optimised a bit thank to re-using the work done on consoles).
Re: (Score:2)
Direct3D 10 is very different from Direct3D 9.
Direct3D 11 is a superset of Direct3D 10.
Re: (Score:2)
Direct3D 10 is very different from DirectX 9. The latter was designed with modern GPUs in mind and so is based around an entirely programmable pipeline. DirectX 9 is predominantly a fixed-function API with various places where you can insert shader programs into the pipeline. This means that DirectX 10 is easier to support because there's less provided by the API.
Supporting D3D 9 is akin to supporting OpenGL 2. You need to expose most of the programmable interfaces but also have a load of fixed-funct
Only usefull for wine? (Score:3)
I bet there are lots of other applications that utilize d3d and want to port to linux that can use this directly.
I've met people that actually prefer d3d over opengl (don't ask me why), so I think it's going to have much wider use than wine.
Re: (Score:3)
Re:Only usefull for wine? (Score:4, Interesting)
People prefer d3d over OpenGL for the same reason they use a Mac over Linux. Less to go wrong everything just works it's easier.
(I'm a Linux user who does a lot of open gl work)
Re:Only usefull for wine? (Score:5, Informative)
Just use this as an example: search on Google for glVertex. First link goes to the official documentation. Nowhere on the page is it mentioned that this entire rendering system has been deprecated. Nowhere on the page can you see that the documentation is for OpenGL 2. There's a 2 in the URL, but changing it to a 3 or a 4 gives a 404 error. At least now some blessed soul made docs.gl [docs.gl], but the fact it's not even Khronos taking some time to fix their fucking documentation is absurd. You'll note though that even there, the docs for glVertex don't mention deprecation; the function just doesn't have an OpenGL 4 page.
Then there's debugging. Once you've used PIX or VS2012's built-in debugger, you really can't look back. Being able to save any frame, step through the entire rendering process event by event, and even go as far as debugging an individual pixel (down to what tried to write on the pixel, why the draw call did or didn't pass, and a way to put breakpoints in shader code using that pixel's input and output!) is just... It's unrivalled. Nothing from OpenGL even comes close to this.
Re: (Score:2)
Re: (Score:2)
If you're just starting and know nothing about 3d programming, glVertex is FINE.
By the time you get to the point where you know how to deal with, can make use of, and/or need to move away from the fixed function pipeline, you'll know glVertex is the more limited way to do it.
Yes, people who don't know any better may choose DirectX. Maybe. But only if they use Windows exclusively, and incase you haven't noticed, that is now a minority.
Re: (Score:2)
What can go wrong? How about all the bugs in random gl drivers from various vendors? Oops this only works on nvidia, this only works on ATI (haha yeah right nothing works properly on ATI), intel is a joke, etc, etc.
Re: (Score:2)
This native D3D9 support only works for drivers based on Gallium3D, which includes Noveau and the newer cards supported by the Radeon driver. If you are using the proprietary NVidia or AMD drivers, then this won't work. I can't imagine that any company would want to support a Linux port that required you to have specific graphics card drivers installed. Especially a company that didn't care enough about cross-platform support to use OpenGL from the start, and especially when many of the people who care abou
Re: (Score:2)
You make no sense, since having only the proprietary driver available sounds to me like "require you to have a specific driver installed". The Gallium3D driver, which supports Radeon cards since the R300 series (Oct 2002), offers an alternative to the required proprietary driver. And since AMD regularly drops support for older hardware in the proprietary driver, the Gallium3D drivers supports a wider variety of hardware, and will continue to do so. Seems like writing for the proprietary driver is the mor
Re: (Score:2)
Think of it this way. If you are a company that has a D3D application that you need to port to linux, does it make more sense to spend a small amount of time making wine-lib based port that works with any video card driver. Or to spend a larger amount of time to create a native port that only works with specific drivers, causing all sorts of complications for your potential user base. It's a no brainer; you take the path that is less work for you, and more compatible for your customers.
Voodoo Glide (Score:1)
Glide = Fixed pipe (Score:2)
It would be nice if support for Glide 2.1 and 3.0 be added also, there is a good chunk of oldies that would benefit and nowadays wine has dosbox built in, so even DOS games would be supported.
Very unlikely in my opinion:
Voodoo cards (and their Glide API) are fixed pipeline.
Whereas, from the ground up gallium3D was organised around the modern features found in a programmable-shader card.
There's a lot of difference between how these work.
On the other hand, Glide was designed with the simplest subset of OpenGL implementable in hardware in mind. That's why it easy to write miniGL or OpenGL implementations on top of it (and the reverse also: it's not impossible to write Glide-to-OpenGL wrappers).
Mean
Re:Glide = Fixed pipe (Score:5, Insightful)
Given the hilariously low power of even the VooDoo5 compared to today's hardware, a simple wrapper (like what was used in many old emulators) would do the job and you'd never notice frame issues.
Re: (Score:1)
Re: (Score:2)
since from what I have heard, modern video drivers emulate OpenGL 1/2
Where did you hear this?
Again fixed pipe (Score:2)
Again, there's a reason why Glide wrapper tend to target OpenGL 1/2 instead of 3/4.
Glide is fixed pipe.
Glide and the other APIs back then (DirectX 7, OpenGL 1/2, etc.) where about just painting plain triangles. Paint triangle with tips at vertex v1,v2,v3 using texture T1, optionally a second texture T2 as lightmap (and for the few architecture that did have it: using a third texture T3 as a bump map).
That's it.
For any pixel on the screen, the only thing the hardware is capable of is geting 2 or 3 textures (
Re: (Score:1)
Re: (Score:2)
If you use the Daum build, also consider using the latest version of DBGL [quicknet.nl] which supports the extra experimental config settings.
Re: (Score:1)
Re: (Score:2)
I remember people using Glide -> DirectX/OpenGL translation layers on Windows several years back to run UltraHLE and things like that.
So I doubt it is that hard.
grammar nazi (Score:2)
"There's patches" ?
Re: (Score:2)
DX12 is highly unlikely to become popular any time soon because of the whole 7 uber alles situation. At best, it'll be where DX10 was.
DX11 while popular is not mandatory for most games that come out. A lot of games still have separate DX9 and DX11 rendering paths. As a result, while you'll have to give up some bells and whistles you will be able to run the game just fine as long as you have DX9 rendering path available.
There are some games that require DX11. Those are usually latest and greatest that requir