AMD Releases R600/700 Programming Guide

[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]

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

[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.

[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.

[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...

[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]

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

[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.

[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 ).

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]

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.