AMD Releases R600/700 Programming Guide

[phoronix]

Phoronix: AMD Releases R600/700 Programming Guide

AMD ended out last year by releasing basic R600/700 3D code that allowed the rendering of open-source triangles, but not much in the way of usable OpenGL acceleration for end-users. Just last month AMD had then pushed out new R600/700 code that plugged into the Mesa stack and is being used as the groundwork for the providing open-source OpenGL acceleration on the Linux desktop with newer ATI graphics processors. In between December and April, AMD had also released extensive documentation covering the 3D engines on the R600 and R700 graphics processors along with the R700 instruction set architecture. While the open-source 3D support is still emerging for the Radeon HD 2000, 3000, and 4000 series, AMD has released some more documentation. This time around they have a programming guide for those developers interested in understanding the latest ATI GPUs.

http://www.phoronix.com/vr.php?view=13802

[rotarychainsaw]

Sweet! Waiting with baited breath.

[Mr_Alien_Overlord]

Oooohhhhhh baby. Come to Papa! :D

[Qaridarium]

This spec shit is so nice only for this i buy a 3850 2 years ago 4350 1 year ago and last mond i buy a 4670 :-)

for the next peace of openspec shit i will buy a 4770 realy :)

[korpenkraxar]

Wohoo!

One more time (I am still a bit confused here): which of the three radeon, radeon-rewrite and radeonhd drivers is at the frontline and most likely to add semi or proper 3D first?

[rohcQaH]

radeon and radeonhd are xorg drivers, used for modesetting and 2d. Xorg uses mesa for 3d, so it doesn't matter which one you pick.

there are several branches of mesa, radeon-rewrite being one of them. bridgman has explained them several times (use the search function), but the baseline for end users is: pick whatever is announced on phoronix :p

[korpenkraxar]

radeon and radeonhd are xorg drivers, used for modesetting and 2d. Xorg uses mesa for 3d, so it doesn't matter which one you pick.

there are several branches of mesa, radeon-rewrite being one of them. bridgman has explained them several times (use the search function), but the baseline for end users is: pick whatever is announced on phoronix :p

Great! Thanx! I should have known that really. In my defense I am just emerging from a horrible cold and my much brain is still suspended ;)

I am using radeon on my Thinkpad and have not tried radeonhd yet. I seem to hear less fuzz about the latter one but it is still actively developed no? Are there significant feature differences between the two in other areas such as 2D rendering, suspend/resume, xrandr and powerplay?

[Adarion]

That makes me hope that my new onboard chips will be working nicely soon. And I hope that these powersaving features will also be implemented finally.

[Heiko]

Nice going AMD!

Lets hope this helps in finally letting die that bad reputation Ati has for their drivers. The opensource drivers provide choice for the end user to pick the best driver available. It also means that these graphics cards will be supported for a long long time (because the community has the ways to do this). And it means that Ati is the way to go for the opensource guru that hates the binary blobs, which are the only things that other manufacturer provides ;).

Perhaps some day AMD/Ati will be the choice for Linux because good opensource drivers are available (my personal hopes are that the catalyst drivers will get a bit better as well, so they can really get on par with nvidias drivers).

Anyway: my next graphics card (after an HD4870, an HD3450 and an integrated HD3200) will certainly be an AMD/Ati one again.

[Yfrwlf]

Perhaps some day AMD/Ati will be the choice for Linux because good opensource drivers are available (my personal hopes are that the catalyst drivers will get a bit better as well, so they can really get on par with nvidias drivers).

Excited as well, but I still hope fglrx dies as soon as the open drivers catch up and it's not needed anymore. That circumvents them needing to open source it if there are issues with that, and then they can focus their efforts on a much more open future for the GNU/Linux platform.

Seeing the CCC open sourced would be neat too, but again, if they don't open source it I hope they help make an open source GUI to tweak their (and other) gfx cards or simply help contribute and enhance the graphics configuration GUIs and command line programs which already exist which would probably be more ideal. Perhaps enhance xrandr or something else to do more complicated tweaks to graphics performance (like mipmaps, various frequencies, etc etc).

[Dummy00001]

*standing ovation*

[Pfanne]

BIG THANKS!
im really excited about all this and cant wait for the drivers to available!

[MaestroMaus]

+1 kuddo for the AMD guys.

[nanonyme]

Great work from the AMD guys. Wasn't this kinda the last doc even semi-required after which the ball completely moved to the opensource community? As in, if the drivers still will take a long time, we only have ourselves to blame. ;)

[mirv]

Thankyou AMD!

[bugmenot]

Thank you Alex and John!

[Craig73]

And thank-you as well... exciting times.

[Duskao]

Ok, so then my question since I'm new to linux and all is... should I stick it out with Ati or should I jump boat to Nvidia? I'm trying to play a few games here in linux and one of my all time favorites is HL2 and varients, but none of these work very well. I have a Radeon 4850 and I'm lucky if I get 30 fps with the lowest settings possible (through wine of course) Not I'm totally confused...

[89c51]

@bridgman or anybody else that can answer


how many people, outside the ones that are getting paid by companies, have contributed code to the drivers since the specs released??


there is no need for specific numbers (few, alot, none is ok)

thanks

[bridgman]

Including radeon, radeonhd, drm and mesa, something like :

- 4 or 5 quite active
- another half dozen contributing a few changes each
- maybe another dozen contributing single fixes (guessing here)

Most of the sustained work has come from company-funded developers, but there have been some pretty significant contributions from independent developers as well.

[ssmaxss]

Are there positive economical effect from opensourcing drivers? Approximat cost of the work of non-amd-payed contributors overweight cost of opening specifications (IP cleaning, lawyers....)?

[bridgman]

It's probably about break-even in terms of direct costs; there are some extremely capable developers working on the open source drivers who are not on AMD's payroll, but the planning and execution of the IP review process eats up time from our most senior technical people, the ones who would otherwise be working on the GPUs and drivers we'll be selling 2-4 years from now.

The same goes for intangibles (risk, market benefits, "halo" effect, indirect benefit for other markets like embedded etc..) only the numbers are even harder to quantify.

What I think it boils down to is that if we were still a pure GPU company it would be hard to justify doing this, but as a GPU/CPU/platform company it does make sense. The hard part is that you still end up comparing apples and oranges when trying to determine the overall cost/benefit.

[Louise]

So far only AMD CPU's have nested page tables, which improves the speed of para-virtualization a lot.

So I am thinking, which these specs, would it be possible to implement virtual page tables for AMD GPU's, so you can swap out an entire page table?

[ap90033]

Oh my gosh so I could finally get my 4870X2 working 3d in Fedora 11???

[nanonyme]

Oh my gosh so I could finally get my 4870X2 working 3d in Fedora 11???I doubt it. I'd already consider it lucky if 3D got from experimental to basic (as in, could maybe even handle *gasp* glxgears or Compiz) by Fedora 12. Chill out, you'll likely have upgraded your distro version at least once or even more times if you expect to get it without installing it yourself from git. ;) (just to clarify: I did not just say that current git would be usable for any real use case, still locks up on eg glxgears)

[Kjella]

The hard part is that you still end up comparing apples and oranges when trying to determine the overall cost/benefit.

Not to mention, do you have the benefits yet? I'm currently running nVidia with the proprietary drivers, and I see absolutely no reason to buy an AMD card in order to run Catalyst. Not unless you're really trashing nVidia in Windows game performance, but there you're usually competitively priced anyway (margins are another matter). I want to choose open source, but I'm fairly pragmatist.

That means, what can I get out of the box on mainstream distros using open source? I don't expect them to be default but compiling git trees is pretty much out. I don't expect it to win FPS shootouts but I want a 50% unoptimized acceleration not a 1% software rendering solution. You're not at the point where I want to buy it yet, but you're getting closer.

I'll probably be ready for another purchase once the Radeon R800 generation arrives. The question is if your open source drivers will be ready to reap the benefits, or at least give me credible faith they will soon. Yes, I know you can't talk about unreleased products and certainly not product lines but as a general advice, try to be on top of new releases. They're often the ones that cause purchase decisions, which is when you have to be there.

[nanonyme]

I'll probably be ready for another purchase once the Radeon R800 generation arrives.I think there's general suspicions (R800 isn't out yet so no one really knows at this point and people who might otherwise know couldn't really even tell they know since they'd have signed NDA's anyway) R800 would be relatively similar R6xx/R7xx when it comes to the 3D engine so the work on them could then be ported over when developers get to know the differences. (assuming the expectations are true, the faster R6xx/R7xx 3D gets in a working shape, the more likely it is that R800 will start getting useful support ported to it soon after release) Sadly no one can really promise anything, neither in how soon the support will be written nor in that the new chipset family would have similar 3D engine. We'll see.

[bridgman]

Yeah, a lot of the code to support new GPU generations piggybacks on code for earlier products, so it's important to get the previous generations solid first. We put docco for the 3xx-5xx generation out first so the devs could be working with that while we were writing docs and sample code for 6xx/7xx; the critical docs and sample code came out about 6 months ago.

Similarly, we need 6xx/7xx 3D support to be solid in order to provide a foundation for 8xx work. I can't comment on the degree of change between 7xx and 8xx, of course, but we have already started collecting info for the docs and sample code.

That means, what can I get out of the box on mainstream distros using open source? I don't expect them to be default but compiling git trees is pretty much out. I don't expect it to win FPS shootouts but I want a 50% unoptimized acceleration not a 1% software rendering solution. You're not at the point where I want to buy it yet, but you're getting closer.

I'll probably be ready for another purchase once the Radeon R800 generation arrives. The question is if your open source drivers will be ready to reap the benefits, or at least give me credible faith they will soon. Yes, I know you can't talk about unreleased products and certainly not product lines but as a general advice, try to be on top of new releases. They're often the ones that cause purchase decisions, which is when you have to be there.

What you get out of box right now with open source drivers on the latest chips is solid EXA and Xv acceleration plus software 3D, which actually meets the needs of a surprising number of users. The 3D driver is written and had started integration testing in April, but we had to take a little side-trip to adapt to the radeon-rewrite code base which changed the lower level bits of the stack quite a bit (albeit in a good way).

Porting 6xx/7xx 3D to the -rewrite code base is finished and we have resumed integration testing. We are down to a single buffer management issue that causes soft hangs after a few frames; once that is fixed I think things should seem to progress pretty quickly (as they normally do when all the hard work was done months ago :D).

Top priority for the next round of distro releases is getting the kernel driver code in the box, since updating userspace drivers via package manager is usually a no-brainer.

There is a disconnect between the release cycles of typical distros and the market inflection points that drive new hardware releases, in the sense that distro releases tend to come out just *before* new hardware (which sucks for users who prefer open source drivers), but I think that will evolve into something that works a bit better for everyone over time. Ubuntu release timing is pretty good in the sense that you can usually *just* squeeze new hardware support in, but even there the timing is extremely tight and you end up working outside the distro packager's comfort zone.

[nanonyme]

Ubuntu release timing is pretty good in the sense that you can usually *just* squeeze new hardware support in, but even there the timing is extremely tight and you end up working outside the distro packager's comfort zone.That and I think they also seemed quite aware of how the drivers were progressing for the 9.04 (not very surprising considering all the noise about radeon EXA/Xv in Linux land) and they decided to put it into their 2.6.28 kernels. A cynical viewer could see a pattern here where distros find kernel releases to come so seldom they end up having to backport the interesting changes themselves thus putting themselves in kernel maintainers' boots. In Ubuntu the stuff got in two kernel versions early and in Fedora one early; in upstream Linux the functionality only got to 2.6.30. I'm not aware how it ended up being in other distros. I'd assume Ubuntu and Fedora would backport (as in, new stuff for older kernels) the 3D stuff into their systems too if it gets in a reasonably working state before freezes and the kernel release dates are inconvenient.

[ap90033]

So what you are saying is sell my 4870x2 since its crap in linux?

[MartjeB]

No, just wait. You can't play games (not like: pop cd in, install, play) on Linux anyway. Keep Windows for another six months or so.

[ap90033]

I hear you but I want to get some linux gaming going. The only way Steam, and other gaming companies will get on the Linux band wagon is if we are using it and ATI sucks in linux. I have just ordered two GTX260 core 216's and am going to try to sell my 4870x2 for $250...

[nanonyme]

I hear you but I want to get some linux gaming going. The only way Steam, and other gaming companies will get on the Linux band wagon is if we are using it and ATI sucks in linux. I have just ordered two GTX260 core 216's and am going to try to sell my 4870x2 for $250...You or I or anyone else buying graphics cards on Linux is not going to help with that. In theory lobbying might but I seriously doubt game companies care enough. You could always write them an address that all the signed people would be interested in buying the game if it got ported. (probably have to gather tons of names and it still wouldn't probably work)

There's already a reasonably large userbase on Linux, no one just has any idea of how big the paying userbase would be. Thus we'll probably be stuck in a chicken-and-the-egg situation where game companies can't know market size without making a game and they don't want to make a game without knowing the market size. (Who knows, maybe it really is not worth it to make games for Linux; someone should take the chance and you can't expect it to be big game companies. As soon as we have indie companies making big bucks on Linux games, they might change their attitude)

Summa summarum, pick a better set of tactics than pondering which graphics card you want to buy.

[nanonyme]

In case previous message wasn't clear, here's how you get the big game houses to get interested of Linux:
1) Learn to code
2) Make a Linux game
3) Try to sell it
It'll be a flop, retry from 2. Eventually you get to 4 assuming there's a market and you're innovative enough.
4) Profit
5) Start making a Linux game
6) Sell the idea to a big game house and show proof of the previous success to them; most of the profit goes to them
8) Keep repeating 5 to 6 for an arbitrary long time
9) Linux slowly develops a commercial game culture
If you're wrong and Linux users don't actually want to pay for games, you'll stay forever looping 2 and 3. Do you want to risk it? You have to show the big game companies you can make a commercial success, otherwise they aren't going to care.

[Kano]

Why would anyone develop a Linux ONLY game? That would be the most stupid design decision you can make...

[nanonyme]

Why would anyone develop a Linux ONLY game? That would be the most stupid design decision you can make...Well, doesn't have to be Linux-only, as long as you are able to provide statistics on how many Linux users bought the game.

[Kano]

Create an online game then you see it in the server stats ;)

[nanonyme]

Create an online game then you see it in the server stats ;)That's details. My point was that you need a proof of concept, things will probably start rolling on their own weight after that. This is why learning to code and to draw is a lot more important than buying hardware.

[nhaehnle]

I recall an article by the head of an indie game studio, where he was basically saying that they make significant money (for their small size) from Mac OSX and Linux markets. In particular, while the market on those alternative OSs is significantly smaller than on Windows, it is also much easier to get very good exposure in those markets, precisely because there are so few people catering to them. Unfortunately, this is now just me talking, because I can't find the link anymore...

But yeah, the irony is that big studios won't port their games to Linux because, even though they could easily afford to do it, the added income from Linux just doesn't register for them.

On the other hand, look for independent studios producing Linux games - while the relative cost of supporting Linux is higher for them, they stand to gain much more. And there are certainly some gems out there; just vote with your money.

[Kjella]

But yeah, the irony is that big studios won't port their games to Linux because, even though they could easily afford to do it, the added income from Linux just doesn't register for them.

On the other hand, look for independent studios producing Linux games - while the relative cost of supporting Linux is higher for them, they stand to gain much more. And there are certainly some gems out there; just vote with your money.

I don't think you should forget that those big name titles are pretty much 100% made without thinking about cross-platform compatibility. Often they are designed for a DirectX engine, that's often licensed not owned by them. If the cost estimates include doing that from scratch with all the ugly details of making something work exactly like this other engine works then the cost/benefit obviously won't work out.

The independents on the other hand often prefer to use open engines or other cross-platform languages. A good example is "World of Goo", that's a pretty big hit that's available for Linux. Other than that, I must admit most of my gaming happens in WINE...

[madman2k]

personally I dont think it is a good idea to release closed source games for linux at all.
I mean in linux everything assumes everything else is open source so they break ABI/ API quite often and it is a pain in the ass to keep an ancient version of libstdc++ or sdl just to play a commercial game.

I would rather prefer if developers would ensure that everything works under wine so it would be our "compability layer".

The alternative would be to release the engine as OSS and keep the content proproetary...

[Ex-Cyber]

personally I dont think it is a good idea to release closed source games for linux at all.
I mean in linux everything assumes everything else is open source so they break ABI/ API quite often and it is a pain in the ass to keep an ancient version of libstdc++ or sdl just to play a commercial game.Actually, the way it works on Windows is precisely that the needed versions of libraries are kept around, usually installed inside the application's directory. For example, I have a Sun JDK installation with 3 copies of msvcr71.dll (the libc DLL from Visual C++ .NET 2003).

[ap90033]

Dude who cares about having to keep an extra library? I have (2) 750 Gig drives so space is not a concern as it isnt for most. Drives a cheap.

I am trying to do what i can. Its like the political arena in America, both parties suck and want you to feel that you have no chance in changing the crappy politicians minds. BUT if Everyone would quit fighting about Democrat versus Republican and we all agreed on the core principals this country was founded we would be united (they dont want that) and could make a difference. I mean isnt it funny that both parties claim they wont raise taxes then when elected thats the first thing they do.

[monraaf]

Dude who cares about having to keep an extra library? I have (2) 750 Gig drives so space is not a concern as it isnt for most. Drives a cheap.

Well, extra libraries will also be eating up extra memory.

[ap90033]

Got 6 gig and can get 12 for it... Not a big deal again. I am not saying become bloated like windows but sheesh we have hardware now that should be taken advantage of... lol

[duby229]

Got 6 gig and can get 12 for it... Not a big deal again. I am not saying become bloated like windows but sheesh we have hardware now that should be taken advantage of... lol

taken advantage of and wasted are 2 very different things. I run some pretty heavy terminal servers that get alot of traffic. I use nx to share desktops to many different thin clients. In this configuration all of the processing and memory is on the server. Imagine running every version of every lib loaded into main memory for every single session..... We absolutely must keep it thin. Ok, so maybe you wont have every single version loaded into memory, but you may well have 2 or three versions loaded for some libs. If everything used the same versions then we would only need 1 version of each lib.

Running a Windows terminal server on 2008 server I can at most about 40 active sessions on my best server and that is pushing it a bit.. Using Linux with nx I can have around 150 active sessions and still run each well.

Thats a testament right there

[ap90033]

Well considering the current lack of games in linux couldnt you live with a little bit of waste for us gamers? Besides you dont have to have the extra libraries. So how about you dont have them, I will and I will waste an extra gig of memory, I dont care but I do care to be able to play my games LOL.... That way we all win...

[nanonyme]

Well considering the current lack of games in linux couldnt you live with a little bit of waste for us gamers? Besides you dont have to have the extra libraries. So how about you dont have them, I will and I will waste an extra gig of memory, I dont care but I do care to be able to play my games LOL.... That way we all win...And if someone bothers reading up on libstdc++ ABI changes, they realize that this in fact happened already once, pretty dramatically. It was afaik around GCC 3.3 and GCC 3.4. Backwards compat libraries are still getting shipped for applicable programs in some distros.
Edit: I'd note though that it's a normal package that's marked as dependency for programs that need it. Most users don't have it or need it.

[elanthis]

personally I dont think it is a good idea to release closed source games for linux at all.
I mean in linux everything assumes everything else is open source so they break ABI/ API quite often and it is a pain in the ass to keep an ancient version of libstdc++ or sdl just to play a commercial game.

Windows breaks backwards compatibility too. There are a ton of older games that I cannot for the life of me get to run under Vista or Windows 7 but which work perfectly fine in XP. That in turn is partly why Wine has such a difficult time of things: it's not just the API that programs use, but the bugs in APIs and system behavior. Simply changing the way memory address space gets assigned can cause a program to start crashing if it happened to have a bug that nobody noticed before.

The advantage of Open Source is that those bugs can get fixed, yes.

The disadvantage of Open Source is that most commercial games won't ever use it because it annihilates almost any chance of recuperating costs, much less making a profit. Games are one of the largest and most complex types of software to develop these days, and there are two big reasons why many games can even exist: companies can recuperate costs by selling engine licenses to other game development houses, and game development houses can buy high quality engines and game development toolsets that simply do not exist anywhere in the Open Source landscape at all (and once those tools are used, open sourcing the resulting game in a remotely usable state is near impossible due to licensing restrictions).

I think the best you can hope for in the games industry -- ever -- is that most companies will eventually release their older IP under an Open license after it has ceased to be commercially viable. Kind of like what id does with its older tech engines.

It's kind of pointless to even talk about commercial or Open Source games on Linux though, because Linux is a horrifically bad gaming platform all around.

Our video drivers still suck way too hard to make gaming with modern technology feasible. It's currently impossible to do on Linux without closed source drivers, and the ATI folks have even stated that they don't expect the OSS drivers to reach feature/performance parity with the closed drivers.

Installing software is also an absolute nightmare on Linux. Even if a game developer were willing to package the same fucking binary 50 times for multiple versions of multiple distributions of the same OS, NONE of the current packaging tools are capable of handling games with 8+ GB of game resources in a sane manner due to a combination of a lack of authentication against repositories (even if an engine is open source, the game data will not be free) and a lack of standard support for delta-updates across all major distros. And honestly, in the end, developers want to write one installer -- uno, ichi, eins, ishte -- and have it work everywhere (and that means works for everyone, so no needing to open a terminal, copy the installer to the hard disk, set executable bits, install dependencies for the installer binary, and manually running the damn things -- it means double clicking the icon on the CD auto-run or on the website Download Link and just having it work always). Even if all the distros standardized on RPM that still isn't possible because every RPM-based distro introduces a billion other artificial incompatibilities on top of otherwise identical binaries thanks to using different package names, putting files and binaries in different roots, changing the names of binaries to resolve conflicts with practically irrelevant software that happened to be in the distro first, and so on.

A real market for commercial games -- be they Open Source engines or not -- simply cannot materialize on Linux in the near future. The platform necessary for that market simply does not exist in any way on Linux, and the driving forces behind the desktop experience on Linux have zero interest in fixing the deficiencies, largely because a great deal of people either don't think games are important ("all people need on their computer is a browser, man, that's the future!") or think that the central-repository-one-umbrella approach is the only true way to deliver software ("it has to be in our repo for testing and QA, man") even though the central repositories and their mirrors would never be willing to host dozens of 4GB+ games.

[Ant P.]

A real market for commercial games -- be they Open Source engines or not -- simply cannot materialize on Linux in the near future. The platform necessary for that market simply does not exist in any way on Linux
Typing `emerge ut2004` works just fine on my machine, and it doesn't download 4GB of data files from a distro mirror either. Was your post written for 1999?

[MartjeB]

@Ant P.: Oh come on! Please! Have you ever compared UT2004 to Crysis? Or even Far Cry 1?

I agree with elanthis for a large part. Except the following:
Installing software is also an absolute nightmare on Linux. Even if a game developer were willing to package the same fucking binary 50 times for multiple versions of multiple distributions of the same OS, NONE of the current packaging tools are capable of handling games with 8+ GB of game resources in a sane manner due to a combination of a lack of authentication against repositories
What about the following:

You click on your DEB/RPM/Whatever on the DVD of your game
The deb-scripts (post-install, etc.) copies all the files needed to /usr/share/<game>
Launch the game!

Even if your platform is not supported (you don't use DEB or RPM) you can launch a small script which asks for your password and lauches a terminal, which copies the files.

All the dependencies of the game will be included in the game-data on the dvd.

[madman2k]

The disadvantage of Open Source is that most commercial games won't ever use it because it annihilates almost any chance of recuperating costs, much less making a profit. Games are one of the largest and most complex types of software to develop these days, and there are two big reasons why many games can even exist: companies can recuperate costs by selling engine licenses to other game development houses, and game development houses can buy high quality engines and game development toolsets that simply do not exist anywhere in the Open Source landscape at all.
Well we have OGRE and the Blender Game Engine is in coming. Probably these can cause some unemployment among game developers :D

[Pfanne]

Well we have OGRE and the Blender Game Engine is in coming. Probably these can cause some unemployment among game developers :D

the interesting thing is that the blender game engine is now being developed with the help of a game company called twilight22 or something.
they work on improving the speed as well as the workflow.
the bge is one hell of a powerful tool, though it lacks certain features to make it useful in the commercial way.

[elanthis]

Even if your platform is not supported (you don't use DEB or RPM) you can launch a small script which asks for your password and lauches a terminal, which copies the files.

Because that is impossible on current distros. NWN did that, as well as a number of other commercial Linux games. None of those installers work anymore without manually patching them.

If nothing else, there is no way to run a script that can ask for a password in a cross-distro compatible manner. Somem distros use sudo, some don't. Some have GTK frontends for su, some for sudo. Some use KDE frontends. Some don't have a graphical frontend at all. Whether or not the distro even allows the script to run is indeterminate, because osme distros mark the CD as noexec while others don't, some distros allow you to double-click an executable to run it and others don't.

Without a standardized installer, it WILL NOT WORK. That means a single installer format that some preinstalled-on-every-distro program can recognize, open, and process to copy files from one (or more) discs (or the Internet, even) onto the computer, either in a single user's home dir or on the system. Integration with RPM and DEB and such would be a (welcome) bonus, otherwise it requires a standardized update and uninstall tool as well.

There are several such tools available. Few of the distros want to even offer these in their repos, and none want them in the default install, making the projects all entirely wasted efforts.

[elanthis]

Well we have OGRE and the Blender Game Engine is in coming. Probably these can cause some unemployment among game developers :D

Not really. Most game developers are the exact same as the OSS developers: they reimplement crap from scratch due to NIH syndrome. :) How many OSS 3D engines are there? Irrlicht, CrystalSpace, Blender, and OGRE are just the four "big" ones, on top of the Quake3 tech mods. And so on.

And honestly, those tools are NOT game engines. They're 3D engines. A full game engine is far, far, far more than those things. As with all programming, games are dependent on the quality of the tools used to make them. The mapper tools used by level designers. The scripting tools used by AI designers (who are often not trained programmers). The reporting tools used by the game designers. The in-game event systems and analysis tools used by the logic programmers.

A 3D engine is just a tiny, tiny part of what a game engine needs, and honestly, it's the easiest to replace. 3D engines are commodities these days. There are tons of companies selling 3D engines, not to mention those Open Source engines you brought up. If that's all a game engine needed, Open Source would have actually come up with a game worth more than $5 already.

[energyman]

Not to mention, do you have the benefits yet? I'm currently running nVidia with the proprietary drivers, and I see absolutely no reason to buy an AMD card in order to run Catalyst. Not unless you're really trashing nVidia in Windows game performance, but there you're usually competitively priced anyway (margins are another matter). I want to choose open source, but I'm fairly pragmatist.


well, without the open source initiative, I wouldn't have bought the 3870 I own now. Or a friend of me would not have bought his 4850 ...

some time ago, people were saying 'I buy intel mobos. Because they have open source drivers for their onboard graphic'. Before that it was 'I buy ATI because the Radeons have open source drivers'. Ok, thanks to ubuntu the 'free drivers are a great thing to support' mindset suffered. But hell... I support that.

A company acts nicely? I buy their stuff. And all of my linux using friends think similar.