Direct3D 9 Comes To Linux, Implemented Over Mesa/Gallium3D
An anonymous reader writes "Picking up the code from a failed Direct3D 10/11 implementation for Linux, a working Direct3D 9 state tracker has been implemented for Linux. The Direct3D 9 support works with open-source Linux GPU hardware drivers via Mesa's Gallium3D and can run games for the open-source Radeon and Nouveau drivers without simply converting the Direct3D commands into OpenGL. Unlike the experimental D3D10/11 code from the past, this D3D9 state tracker is already running games like Skyrim, Civilization 5, Anno 1404, and StarCraft 2. With Linux games not natively targeting D3D, Wine was modified for using this native Direct3D implementation."
can run games for the open-source Radeon and Nouveau drivers without simply converting the Direct3D commands into OpenGL.
Presumably "simply" isn't the right adjective, because it implies that converting from Direct3D to OpenGL is the better way of doing things - what's the problem with converting Direct3D commands to OpenGL? Slow?
systemd is Roko's Basilisk.
1998 called.. They want their joke back.
http://slashdot.org/comments.pl?sid=3963145&cid=44259321
We're on D3D11 now people.
... and did you tell them about the tsunami while they were on the phone? If not, then all those deaths are now your fault!
I love stacking my barbecues in the shed at the end of summer - you can't beat a bit of grill on grill action.
The closing line:
"It will be interesting to see if this Direct3D 9 state tracker takes off for Linux and whether Wine developers will optionally support it for better performance."
What is this, a high school paper? Need to fill space much?
I want to delete my account but Slashdot doesn't allow it.
Sounds like I'm going to have to find a new book to place under my monitor now.
It's pretty hard to warn people about a future disaster if they're leaving a voice mail.
Which is why my outgoing voicemail message includes a list of all of the major disasters from the last decade. Just in case somebody from the past decides to call me.
Well, if you're programming for windows, and XP is a target for potential users, then you'd be programming in OpenGL right now (because it's the only way to get tesselation and compute shaders on XP). If you're targetting Windows 7 or above, you'll be using D3D11. If you had even so much considered the remote possibility of ever going cross platform, at any point in the future, then you'd already be using OpenGL (or GLES).
So what we have here is a library that provides access to GPU functionality from 12 years ago. This might be great if you have the source to a 12 year old game laying about, but for everyone else, this is a completely pointless development in the world of linux.....
since 2001, you might be right.
Except it wasn't, and it HAS (DX 8.1 was I believe the XP release version. I've had to install since, and have some games that broke when DX 9.0a or b came out.).
Additionally what this is talking about is the hardware interfacing necessary for *ALL* directx 9 support on a bunch of current-gen AAA games now playing almost 2x faster thanks to shaving a whole layer of API indirection out of the average rendercycle, so in fact it *IS* a huge deal, especially for gamers on linux.
Combined with a variety of OTHER gallium related fixes going on (Notably the LLVMPIPE and R600 sb shader backend), we may be rapidly seeing a much larger shift to linux than the past would lead us to suspect.
Ok, so Direct3D9 is *only* 10.5 years old. My point still stands though. If you really want the latest shiny graphics in your games, you still need to use D3D11 or OpenGL 4. Being able to run a current gen game using D3D9 is not quite as exciting as being able to run a current gen game using D3D11.
Ohhh, it is phoronix, not moronix... they could have chosen better font for logo...
Anyway, I'm confused with the benefits here. From TFA
[...]
The Direct3D 10/11 state tracker excitement was ultimately shortlived as the upstream Wine development community wasn't interested in adding support for it since it's a Linux-only solution and at that it's *limited to those using Gallium3D*, which is basically the open-source *Radeon and Nouveau (NVIDIA) users*
[...]
Direct3D 9 state tracker can work so that the graphics API is natively implemented for the hardware *Gallium3D drivers*
[...]
So old one died because it was working only on Gallium3D and nobody wanted to use it because of that, but new one is also targeting Gallium3D, but it will be successful, because it has not died yet due to Gallium3D dependency?
You are only taking information that goes the cynical sens you want to give to your comment. Perhaps you should take the date of february 2007. The date of the release of the Direct3D 10 sdk. And then, taking into account some transition months to use this sdk, you see that games using this version is *only* 6 years old (And I'm pretty sure that games using this version was out 1 or 2 years after!). So, for those that are not fanatics and don't absolutely need the LAST games, that should be a first good step!
it seems to be one of those articles written for people who already follow the subject, rather than casual readers.
Yup, indeed, it's just a small quick news on phoronix.
For the others:
- Mesa is the opensource 3d graphics driver used on Linux for opensource drivers.
(- the closed sourc drivers uses their own sauce instead)
- the old classic mesa is just a plain big monolith exposing OpenGL (that's what Intel provide for their official opensource drivers.
- the modern Gallium3D Mesa is a modular architecture for 3D API (that's what is used by modern opensrouce drivers, like the reverse engineered Nouveau for Nvidia, or the AMD-sponsored Radeon driver).
The idea of the Gallium3D modular design:
- on one side you have low-level drivers handling the hardware (or the CPU in the case of the LLVMpipe software driver) and exposing the basic GPU functionnality.
- on the other side you have "state tracker" high-level interfaces speaking the various API (OpenGL, OpenCL, etc.)
This make the whole development much faster and help code reuse.
- If a new hardware comes, you only develop a new low-level drivers exposing the functionnality of this new GPU. And bam! you get automagically support for any API for which you provide the necessary functionnality. No need to write a complete new OpenGL driver from scratch.
(That's how most of the newer opensource drivers, like all the new GPU for ARM SoC are implemented or are going to be implemented)
-If you want an additionnal API, you only develop a state-tracker, the high level part of Gallium which speaks the API. And bam! you get automagically support for any hardware whose low-level provide enough functionnality. No need to write a full Direct3D stack for each single available hardware, just write a generic stack for Gallium.
That's what is being done regarding DX3D9 in this news.
Up until now, the way 3D worked for Windows software running under Wine, is that wine has a layer that intercepts all DX3D calls and retranslate them into OpenGL then sends those to the running OS (to Linux or Mac OS X).
It works, but it's difficult, and it's slow: this translation layer comes at a cost. Even more so because OpenGL and DX3D do not function in the same way, so implementing some stuff requires quite a complicated translation.
Now this Gallium stack is much more direct, it receives Direct3D calls and directly execute them using the low-level functionnality exposed by a hardware layer. It doesn't need to go throug a complex intermediate translation step.
The advantages of this approach are:
- It's much faster that way, because we directly call hardware function, instead of having to map to concept from another API (openGL) which doesn't work the same way.
- It's quick to develop, specially because Gallium has already support for most of the needed functionnality to provide Direct3D 9 (unlike an older Direct3D 10/11 driver which were attempted earlier).
- For older Radeon hardware, the opensource driver is what AMD recommand, they are stable enough, fast enough, and still maintained. So you're probably getting near native spead when running windows software on linux through wine, instead of slow down due to the opengl translation layer of wine.
The problems of this approach are:
- It only works with Gallium.
- Intel official opensource driver don't use it (but there are attempts by 3rd parties to make gallium drivers)
- AMD official drivers for current modern hardware is the closed-source catalyst (their own different stack).
So either you get fast up-to-date Catalyst drivers, which only speak OpenGL and you have to put through with the wine translation layer. So you lose performance.
Or you use experimental not-yet stable opensource drivers, which are gallium and thus do speak Direct3D 9, but they aren't perfected yet and are slower than Catalyst. So you lose performance too (albeit at a different level)
(At least, on the radeon side, AMD is collaborating a
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
that woosh you might be hearing is not a tsunami...
All we have to do is put some desks in the server rooms to accomplish that. Linux is very popular where most of the computing is actually done.
finally i can play those new games that came out... three to 11 years ago.
oh a serious note, progress is always good. it's really too bad transgamming killed cedega but didnt release any DX code. i really liked cedega and yes, paid the subscription fee for it.
Anons need not reply. Questions end with a question mark.
I think you hear a whoosh so loud that a tsunami is a silent event in comparison.
combined that with D9 BEING probably the longest lasting of them, many games, including new, still support it natively due to the large number of cards still out there that arent D11 compatible. with cards 5 and 6 years old still running games, even new ones, more than acceptably, the constant pressure to upgrade to the newest shiny constanly is lagely absent. and that would leave a huge market untapped if they didnt support it. its much different than a few years before when cards had a much shorter lifecycle, and you could expect your market to be upgrading every year.
(frankly I cant see a whole helluva lot of difference between 9 and 11 when playing, if the devs did their job right, unless I pause the game and actually look for the differences. When running and gunning, its not really noticable unless the devs were lazy. even crysis3 can be made to work with 9, and it still looks beautiful)
The guy who said the election was rigged won the presidency with the second-most votes.
addendum: point being, with such a large installed base of cards that run 9, and games that run 9, getting 9 running more efficiently on linux is a big boon to linux gaming.
The guy who said the election was rigged won the presidency with the second-most votes.
It's silly anyway, why in the hell would you want to lock yourself into an API (DX) that only works on one platform and could be pulled from under you at any time. And some devs complain about the difficulty of porting their game to Linux/Mac, well hey, if you had used a Cross-Platform API and Engine to begin with you wouldn't be having that problem DUH.
Ignorance and stupidity will be the death of this world I swear....
Not to mention that DX11 can do many things 2x+ than DX9. Not all things as in you will get 2x the FPS, but a decent amount of features that will keep your FPS from dipping as often during complex scenes.
DX9 needs to stop being used and everyone needs to switch to DX11 or even better, OpenGL4.
but Direct3D goes to eleven...
next thing you know, we'll finally catch up to Windows 3.11 for workgroups.....oh wait
This is Microsoft's strategy to finally push XP off a cliff, and get longtime XP users to upgrade to something bett...well to something, at least.
WARNING: Smartphones have side effects--most of them undocumented.
Firstly, claiming that this is running natively is hardly accurate. Its running under WINE. Yeah I know Wine Is Not an Emulator blah blah, but running anything under WINE is a very hit-or-miss experience, certainly not what you would assume when someone says its running natively.
What we REALLY need is for developers to switch from using any Microsoft-proprietary APIs at all. Technology such as this enables other developers to continue to backslide on change and continue down a bad Microsoft road as a (bad) way to get things onto Linux. That isn't the solution that anybody wants (except Microsoft because they know trying to run through copied Microsoft APIs shoots Linux in the foot so performance comparisons etc. cant even be a fair fight to begin with).
The only right way (and the only thing that should e called "Native" ) is to switch to using native (i.e. non-microsoft) APIs such as OpenGL. That is the only good approach. everything else will always be a compromised mess.
Yeah, and somehow knowing that will magically alter all the compiled code of decade-old games written by other people.
Slashdot social media options: AIM, ICQ, Yahoo, Jabber and Mobile Text. Why no MySpace?
Wait for it.... A new (incompatible) version will be released any day now. It will have huge sweeping changes and more undocumented little gremlins to keep those open source folks at bay....
Remember boys and girls, MS doesn't sell an OS they sell a gaming platform. Anyone who intrudes upon that turf will be met with swift incompatibility!
Says you. My two main games are Guildwars and Total Annihilation and both of them are from Win95 era though GW has finally moved upstream enough that they've dropped support for Win9x from the client. For me, this sounds like a decent performance improvement that actually benefits me as both run well on Wine 1.4
Mod me up/Mod me down: I wont frown as I've no crown
How many people still like to play games that are 5..7...10 years old. A lot of people
Even relatively modern games like Civ 5 and WOW are quite happy with direct x 9.
Since this is an article about Linux and 3D graphics.
Who should I vote for with my dollar this year? I don't mind having to dualboot with windows to actually play (don't want to much stinky closed source programs on my linux), but I want to go with the best effort.
Nvidia were given the finger earlier, did they improve their dual-GPU system support, or is AMD still leading for open-source support? Do they both ship stub drivers with a blob, and is Intel's last generation any good to run, say, SupCom or Skyrim with a constant decent framerate, fullscreen on low settings? (Links are welcome)
You claim that video games in genres that don't benefit from a mouse "are the minority of games". By minority do you mean 49% or 1%? As for recently played titles that aren't FPS/RTS, let's see: Super Smash Bros. Brawl, Sonic 4 Episodes, Sonic Generations, Giana Sisters, PiX Bros., FHBG, Streemerz, or anything else whose controls involve moving in a direction, jumping, and attacking. Yes, I'm aware that some of these are first-party console games and therefore not a perfect match for a discussion about menu controls in PC games, but that doesn't rule out a PC game in the same genre. For example, instead of Brawl, choose Street Fighter IV. Why put away your MadCatz Sanwa joystick and pick up a mouse to select your character? And even on consoles whose controllers have a mouse equivalent, like the Wii Remote, some games ignore the pointing feature, such as Brawl, because the menus are built not to need it.
DX9 needs to stop being used and everyone needs to switch to DX11 or even better, OpenGL4.
If Microsoft had ported DX10 and DX11 to XP, rather than using them as a club to beat XP users into switching to Vista, everyone already would have.
If you really want the latest shiny graphics in your games
The average person doesn't have the hardware, never mind the software, for this, and they don't really tend to care.
thats aimed at game devs not users,
---Saying gnome 3 is better than windows 8 not so much a compliment as it is damning with light praise.
Please don't stereotype like that. Most Muslims would not condone the actions of Al Qaeda on 9/11.
It is not about one giant leap into the Linux desktop domination. It is more about the steps required to get there of which this is one. Microsoft has now, through its own actions, pushed many people that I know personnaly over to Linux. They are the number one catalyst to cause the year of the Linux Desktop.
Are you stupid? This is talking about DX 9. It's stuck at 9.0c version with some patches from..... 2008 at the earliest?
Not about DX 11.whatthefuckever.
Still waiting on Serviscope_minor to wake up to fucking reality and realize that Jessica Price isn't going to fuck him.
So am I right in my understanding that this only benefits users with ATI GPUs?
Ok, so Direct3D9 is *only* 10.5 years old.
Wow, you really think the other AC was being a pedant about 1.5 years?
Protip: DirectX9 was last updated in June of 2010.
why in the hell would you want to lock yourself into an API (DX) that only works on one platform and could be pulled from under you at any time.
Because if you want to port to Xbox 360 or Xbox One, it's the only API available to you. For some genres, a port to an Xbox platform is more lucrative than a port to GNU/Linux or OS X.
The hardware from AMD, Nvidia and now Intel is NOT DX9 or OpenGL whatever- it is a general programmable shader based processing system of proprietary design. The layer of PC software that most closely controls the GPU hardware is NOT anything to do with DX9 or OpenGL or OpenGL ES. The DX or OpenGL layer TRANSLATES concepts from these APIs to the memory and streaming low level functions of the real hardware drivers.
The real problem is this- performance. GPUs are used because they are very fast. Getting DX9 working on a Linux box, and not caring that it is hundreds of times slower than the same hardware running under Windows is cretinous. And it will be hundreds of times slower in all but the simplest paths. Don't be fooled by self-serving benchmarks.
The future is Linux games designed for Linux. This means supporting OpenGL ES2.0 and ES3.0 Companies like AMD, Nvidia and Intel can actually craft first class ES drivers under Linux, and ES3.0 can be considered a perfect replacement for DX9, and better.
Wanna play Dx9 games? here's a clue- make a dual boot to XP, and go game in that environment. Wanna encourage first quality Linux games? Here's a clue- support games written using ES2.0 and ES3.0.
Microsoft has announced the DirectX project is over. The phenomenal success of ARM devices means that OpenGL ES3.0 will eventually be the dominant GPU API. ES3.0 and beyond can run just as happily under Windows. DX, on the other hand, can ONLY ever run happily under Windows. One GPU API can be great everywhere. One GPU API is only great on a dying platform. Doesn't take a genius to figure out which is going to be the winner.
Who cares? Linux (counting Android and other systems) is doing quite well everywhere else, and between servers, laptops, phones, tablets, and dedicated gaming consoles, who even needs a desktop anymore? The slump in PC sales suggests the answer is "no one." (Thank you, Windows 8!)
If 2014 is the Year of Nothing on the Desktop, then Linux can count itself a winner.
If it's for-profit but free, you're not the customer -- you're the product (e.g., the Slashdot Beta's "audience").
The reason you can't see much, if any, difference between Direct3D9 and Direct3D10/Direct3D11 is because game developers are wasting their time implementing the exact same thing across multiple Direct3D versions. There are things one can do with modest Direct3D10 and Direct3D11 hardware which to replicate in Direct3D9, even on the same hardware, would be horrendously slow.
It's a case of new features not being utilized for anything near what they can really do because they are afraid of leaving users that refuse to upgrade past Windows XP out of their product. I don't understand it at all when the alternative to Direct3D is OpenGL which allows you to use the latest features your graphics card supports on even the oldest OS as long as a working driver is present.
I honestly laughed my ass off when you said "if the devs did their job right". If the devs really did their job right you would see a massive jump in quality going from Direct3D9 to Direct3D11. But no they didn't do their job right, they just did it good enough to port features of their implementation to the new API, lazy shit.
Poor DX support is really the only thing that's been holding me back on dumping windows for the last 5-8 years(every year is the year of the linux desktop right?) But, with this, and with any luck DX10/11 eventually, it may very well be enough to push 'nix in whatever flavor into the mainstream market and out of the realm of geeks. And yes, I know there's the oddball non-geek who's using it, or have had someone set it up for them. This on the otherhand if done right will take a major bite out of the Windows market.
Om, nomnomnom...
In English. In Arabic or Urdu, however....
This has the added benefit that if anyone does call you that they will never try to contact you a second time.
Basically the targeting is for the graphics card, not the OS. Plenty of Windows 8 computers are using cards that are only DX9 capable, even if the DLLs are listed as DX11.1.
DX10 I would agree with. DX11 doesn't add that much that is noticeable.
wuuhuu 4everLinux Games.
Wuuhuuu
How is my post offtopic? I was clearly stating my emotion (subject) and opinion (content) to Linux being able to be used with a graphics API other than OpenGL.
Just because I didn't write a long rant exposing an approximation to why I think I feel that way, it doesn't mean the content isn't related to the article.
Just because I didn't write a long rant exposing an approximation to why I think I feel that way, it doesn't mean the content isn't related to the article.
You posted nonsense that exposed yourself as a dumb jackass. Learn from it; contribute or go the fuck away, you insufferable child.
Anything you use the control pad's analogue stick for can be done better and faster with a mouse.
How would Super Mario 64, where the Control Stick on the Nintendo 64 controller's center handle makes Mario face a direction and move at a given speed, have been controlled with a mouse?
control schemes [for fighters and platformers] are so limited they are easily replicated on a touch screen (one of the worst game controllers in existence due to a complete lack of tactile feedback)
In fact, there's so little feedback that the player can't even feel which button his thumb is over, which means he can't tell where to press for weak, medium, or strong punch or kick without looking away. So I don't see how a fighter could be done on a touch screen. Even platformers, with buttons to jump, use main tool, and use secondary tool (traditionally C, B, and A respectively on the Genesis controller), run into the same problem.
consoles are made for spilt screen gaming and PC's aren't.
How not? Sure, a 21" desktop PC monitor is far smaller than a living room TV, but it's still bigger than the TVs that were common in bedrooms during the Nintendo 64 era. Furthermore, you can connect a PC to an HDTV with an HDMI cable. If your PC lacks HDMI out, you can use DVI-D to HDMI and audio cables or even VGA and audio cables, which should cover every PC since the Windows 3.1 era. In addition, nearly every PC since 1999 has USB ports for connecting USB gamepads, and every Windows operating system since Windows 98 supports four or more USB gamepads.
I prefer fighting games and platformers on consoles because I play these games with friends
I've talked to some people on Slashdot who tell me they choose to play with strangers in pickup groups because they don't want to fly out to play with their friends or just because they don't work the same shift as their friends.
in the same room
What keeps you from building a home theater PC and putting it next to your TV? I know hairyfeet is a big proponent of the HTPC.
switch to using native (i.e. non-microsoft) APIs
xf86-input-joystick [...] alsa
These APIs are not available on Windows. They are specific to Linux (or to UNIX in general). Or are you recommending making games exclusive to Linux instead of exclusive to Windows?
just use sockets
UNIX sockets work on UNIX, and Windows sockets work on Windows, but I thought key points of semantics differed between the two.
You're saying that like Direct3D alone would solve it.
Windows games use Win32 APIs for things other than graphics. OpenGL is available on both Windows and UNIX, but a lot of the other APIs are available only on Windows or only on UNIX without some sort of translation layer like Wine or Cygwin.
Input and audio were moved out of DirectX
Only keyboard, mouse, and Xbox 360 Controller input were moved out of DirectX. One still needs DirectInput to read HID gamepads. And besides, when audio and keyboard, mouse, and Xbox 360 Controller input were moved out of DirectX, they were still moved to a Microsoft API.
Let me try rephrasing this again: OpenGL is present on both Linux and Windows. But for a single game that has both Linux and Windows versions, what libraries present on both Linux and Windows should the developer use for things other than graphics? Or does each developer need to write its own wrapper library around the corresponding Linux and Windows APIs?