That's the way it's looking today. Dave Airlie has been cleaning up the parser to go into the kernel, and Ben H has been working on fixing the big-endian issues. There was a rumour that one of our driver devs had already fixed the big-endian support but it turned out the fixes were for the pre-Atom BIOS instead.
Originally Posted by c0un7d0wn
<deleted the comments about the new AtomBIOS parser we discovered internally 'cause it just confuses things >
Last edited by bridgman; 07-04-2008 at 10:11 PM.
Awesome. So there are two drivers for ati hardware and now it turns out there are also two atombios parsers. If we combine them we can have 4 drivers that does the same thing.
Actually forgot about kms, so that makes, what, 6?
Ah, Operation "Extreme Redundancy" is carrying on!
Hey, there used to be four drivers, now there are only two-ish :
Seriously, the X community is going through some very cool times right now. There are a lot of good ideas competing for attention and developer time, and in most cases you get some forking while the pros and cons of each approach are understood, then everyone comes together on a single approach after a while.
That said, there are a lot of different worlds co-existing in X right now and both drivers have attributes which are useful to some users. The challenge is to get everyone to agree on what the good and bad bits are.
Kernel modesetting will make things seem complicated for a while, but the benefits are going to be significant, particularly the potential for fixing suspend/resume once and for all, or at least making sure the problem is not with the graphics drivers.
Finally, you need to look at both the atombios and "quick & dirty 2d" radeonhd branches together if you want to get the whole picture. If anyone feels like testing the "quick & dirty 2d" branch on a 5xx or 690 it should have full EXA acceleration, textured video Xv, and 2d/3d coexistence from radeon, plus the driver abstraction and modestting code from radeonhd, plus a bunch of other recent changes to make all the bits fit together nicely.
Last edited by bridgman; 07-04-2008 at 10:46 PM.
Maybe slightly off topic, but I'm a 3D designer with a strong interest in both Linux and FireGL products, so I was wondering...
With these opensource drivers, will there still be a difference between the FireGL and their Radeon counterparts and will that difference be forced upon the open source drivers through AtomBIOS? (Like the way the Windows driver decides what features are to be enabled on a specific adapter, as can be observed from the many succesfull hacks).
Hello everyone. I have a very brief question for brigman: will kernel modesetting also be available on r300?
Originally Posted by bridgman
9800pro owner here :-)
It varies from one generation to the next, but AtomBIOS doesn't force anything -- it just identifies the card as a FireGL product and lets the driver decide what to do. There are other mechanisms we use to force different behaviour -- and when we don't use them, the cards do occasionally get hacked.
Originally Posted by StefanHamminga
AtomBIOS commands only cover initialization and modesetting. All the rest -- including 2d, 3d and video acceleration -- are done via the on-chip command processor (cp) or by poking the same registers used by the command processor. I guess at a very abstract level you could say that AtomBIOS does for display & modesetting what cp does for acceleration -- it provides well-tested programming sequences which "just work" for most situations and can be bypassed where necessary.
On the 5xx parts I don't believe there will be any behavioural difference between Radeon and FireGL products with the open source driver. Not sure yet about 6xx and up yet.
Last edited by bridgman; 07-05-2008 at 01:16 PM.