"DONE" means that it is implemented and relatively bug-free.
"MOSTLY" means that it is implemented but has some known bugs.
"WIP" means that someone has started on the initial implementation.
"BIOS" means only if supported by your BIOS. No software support. Yet.
"N/A" means that the feature is not supported by the hardware.
"N/N" means that the feature will not be implemented, because a better alternative is or will be available.
"TODO" means that someone needs to write the code. The required knowledge to write the code may or may not be known. Please ask on #radeon if you want to get your feet wet on this.
"UNKNOWN" means that the current status of this item isn't known. You are free to update it if you know.
I'm not sure if I got my point across, so I'll spell it out more cleanly.
My understanding is that when a feature is under development, the driver is reporting that feature as available when the user program queries it. I think there should be one of two solutions (or both of them):
a. The feature is never reported as available using the standard API. A new standard or non-standard API is used to query the list of in-progress features. This would allow special programs to be used to test new features without impacting real applications.
b. The feature is not reported as available using the standard API until a standard or non-standard API call is made to inform the driver that it is in testing and evaluation mode. In-progress features are then reported as working. This allows normal applications to be used to test the driver with the feature, with only a small change or wrapper to the application.
The table you linked to has a lot of options, and I'm not sure the complexity of having more states than working/WIP/not working in the drivers and APIs themselves is worth the benefit it would bring. That is definitely the kind of knowledge that I think should be available programmaticly, though.
But talk is cheap, and I'm no X developer, so I may have no idea what I'm talking about.
i find it hard to believe that linux's 3d is hard to work with. even before linux had any decent video drivers, people still made 3d games. maybe not good ones, but they worked. if the ff devs are focusing explicitly on open source drivers and not proprietary, then really, they're idiots. open source video drivers are just about the worst open source products there are. besides, if they can get 3d working with proprietary drivers from other OSes, as i see it, that should mean that they only have a few things to tweak to make it work. they don't have to claim the entire 3d portion of the browser non-functional, they should just simply discourage using open source drivers temporarily. its better to have something than nothing.
even opera puts more dedication to their linux side than firefox has. i'm glad i'm an opera (and chrome) user.
Well, how hard is it to hit a moving target ? 3d code is massively complicated and the IL "intermediate layer" and the assembly compiler are effected by the ever evolving kernel changes.
should it be easy to write code for linux for good 3d performance, on paper yes. Is it viable for companys to chase the roving targets ? likely not. All of these GPU accelerated apps rely on a fiarly consisten API to function properly and becuase the linux API is highly flexiable and in a state of flux, its very hard to target properly.
With gallium drivers and the gallium IL and IL API comming along quickly, we might see a gpu accelerated browser.
People forget alot of the code in the nvidia and ati 3d drivers is likely microsoft code to begin with which is why we all get screwed in the end. New GPU's are very very dedicated to current Direct X standards from the hardware layers up to the drive IL language.
actually, he made a valid point and testing in mesa mailing list confirms that: most (all?) open drivers pass almost all the tests but just crash ff randomly because of few other bugs.
Well the drivers support many cards from many families, not all are cards equally well supported. In fact Evergreen support in r600g has regressed so badly that it can't even run blender without locking up. I guess that's what you get when everybody hacking on it only test with the cards they have available (probably HD 4xxx series), sigh...
Anyway here's my experience with Firefox + WebGL + latest r600g: