ATI R600 Gallium3D Driver Continues Advancing

[Schmaker]

No.

[stupid 10 characters limit]

I noticed. I gave it a shot - HoN got some color corruptions (logged at console as well). Fallout 3 crashes X server. Counter Strike is working properly on framerate 10~20 FPS. Age of Empires 3 wont start. Lightsmark have same graphic corruptions as in classic driver. glxgears works
Everything has like 2/3 or 1/2 performance of classic open driver. Anyway - pretty nice beginning. Keep a good job opensource crowd

[allquixotic]

I noticed. I gave it a shot - HoN got some color corruptions (logged at console as well). Fallout 3 crashes X server. Counter Strike is working properly on framerate 10~20 FPS. Age of Empires 3 wont start. Lightsmark have same graphic corruptions as in classic driver. glxgears works
Everything has like 2/3 or 1/2 performance of classic open driver. Anyway - pretty nice beginning. Keep a good job opensource crowd

824/930 on piglit is like a grade of "F". The grading scale goes, 920 - 930 = A, 910 - 919 = B, 900 - 909 = C, 890 - 899 = D, less than 890 = F

Why so harsh? Well, if the space shuttle only supported 824 out of 930 remote commands, how many space shuttles do you think would make it into orbit without blowing up? A corollary of Murphy's Law would be that the vast majority of 3d engines are going to need one or more features in that unsupported 106/930 gap, so you can either rewrite all the 3d engines people are using on Linux today (not gonna happen), or you can fix the drivers.

[GDJacobs]

824/930 on piglit is like a grade of "F". The grading scale goes, 920 - 930 = A, 910 - 919 = B, 900 - 909 = C, 890 - 899 = D, less than 890 = F

Why so harsh? Well, if the space shuttle only supported 824 out of 930 remote commands, how many space shuttles do you think would make it into orbit without blowing up? A corollary of Murphy's Law would be that the vast majority of 3d engines are going to need one or more features in that unsupported 106/930 gap, so you can either rewrite all the 3d engines people are using on Linux today (not gonna happen), or you can fix the drivers.

Judging by the fact that a good junk of the fails were in shaders and texturing where there were 41 failures and 40 failures respectively, I think it would be more appropriate to compare the current situation to a shuttle with a wing and an engine missing. This is encouraging, because it means the parts that are implemented more or less completely are of good quality and hopefully will not be very troublesome down the road.

There's likely even more subtlety in the numbers depending on whether additional tests were activated to try generate more data on specific problem areas.

[bridgman]

It's probably worth mentioning that if the shuttle supported 824 out of 930 remote commands and a typical mission used 850 commands then missions would probably not run smoothly. If, on the other hand, a typical mission used 56 commands from 930 then you could go for years without running into a problem. I suspect that a typical application's usage of the full OpenGL feature set is probably closer to 56/930 than 850/930... and if any of the 56 were failing then they would have been fixed after the first mission

Also, the real-world implications of a piglet failure typically do not include loss of life, unless you stare at a mis-rendered opponent in a shooter game for too long and your player gets fragged as a result. Invisible opponents in Nexuiz were a bigger problem, of course... MAJOR loss of life there

[spirit]

824/930 on piglit is like a grade of "F". The grading scale goes, 920 - 930 = A, 910 - 919 = B, 900 - 909 = C, 890 - 899 = D, less than 890 = F

Why so harsh? Well, if the space shuttle only supported 824 out of 930 remote commands, how many space shuttles do you think would make it into orbit without blowing up? A corollary of Murphy's Law would be that the vast majority of 3d engines are going to need one or more features in that unsupported 106/930 gap, so you can either rewrite all the 3d engines people are using on Linux today (not gonna happen), or you can fix the drivers.

Yes, i know that .

But just 1 month ago, r600G was 600/800. So i think the driver is maturing really fast. Maybe in 2-3 month ,it will be mostly complete.And in 3-6 month, i will be as fast/faster than r600c.


juzt to compare, fglrx from april :621/693

http://people.freedesktop.org/~airlied/piglit/fglrx/

so, proprietary driver is not 100% perfect too.

[xiando]

I don't really believe they be grateful. Your average Ubuntu user expects his stuff to work and doesn't know much about what Gallium3D is.

Very well said!

I am pesonally very greatfull for both the classic driver work since it has allowed me to (ab)use free drivers for my r600 a long while now, and I am also looking forward r600g becoming usable (it's not, kwin sort of works but it is way to slow to be anything near usable). But those I know who use Ubuntu.. NO.

Ubuntu is my favorite GNU/Linux for people who know nothing about computers. My old Ubuntu-using mother knows how to open Firefox and load a website, but she has no idea what "Ubuntu" or "Linux" or "Windows" or "Gallium" means and why would she?

[droidhacker]

It's probably worth mentioning that if the shuttle supported 824 out of 930 remote commands and a typical mission used 850 commands then missions would probably not run smoothly. If, on the other hand, a typical mission used 56 commands from 930 then you could go for years without running into a problem. I suspect that a typical application's usage of the full OpenGL feature set is probably closer to 56/930 than 850/930... and if any of the 56 were failing then they would have been fixed after the first mission

Also, the real-world implications of a piglet failure typically do not include loss of life, unless you stare at a mis-rendered opponent in a shooter game for too long and your player gets fragged as a result. Invisible opponents in Nexuiz were a bigger problem, of course... MAJOR loss of life there

It depends on the distribution of the probabilities of requiring particular commands.

For example, if EVERY shuttle mission definitely required 55 specific commands that are ALWAYS required and ARE implemented, and then ONE RANDOMLY from the remaining pool of 875 commands, then the chances of failing are extremely low.

IF HOWEVER, each command within the total pool of commands has an EQUAL probability of being required, then EACH COMMAND SELECTED has *about* a (930-824)/930 = 11.4% chance of being unimplemented ("about" because I don't feel like getting into the complexities of sequential probabilities from a diminishing pool of possibilities). So you're picking 56 random commands, each of which has an 11.4% probability of being unimplemented, each command is 88.6% likely to BE IMPLEMENTED, then EVEN IF only 56 commands are required, you MOST LIKELY STILL won't be able to complete the mission... the overall probability of success will look something like 0.886^56 = ~0.11%

(now obviously I didn't account for the fact that each command taken from the pool will affect the remaining commands within the pool and thus the probabilities for subsequent selections.... for real it'll be 824/930 * 823/930 * 822/930 * ... * 769/930 since the probability of lucking out with an implemented command diminishes every time you pull an implemented command out of the pool of available commands -- in other words, the estimate of 0.11% was actually HIGHER than what it would actually be.)

Guess its a good thing that some commands are more likely to be required than others.

[bridgman]

Yep. With most APIs there's a pretty drastic falling-off of usage... depending on the size and age of the API, of course. Sometimes APIs get "reborn" with all the old cruft cut away (this is the crux of the DX10/11 vs OpenGL debate, of course) and a consequence is that relatively more of the API is used and there are relatively fewer portions which are rarely used.

So... yeah, agree.

[nanonyme]

for real it'll be 824/930 * 823/930 * 822/930 * ... * 769/930 since the probability of lucking out with an implemented command diminishes every time you pull an implemented command out of the pool of available commands -- in other words, the estimate of 0.11% was actually HIGHER than what it would actually be.)

It's a while since I've been doing statistic but isn't it 824/930 * 823/929 * 822/928 ... instead of what you wrote? The total available choices decreases also as working choices decreases.

[nanonyme]

(I don't vouch for the rest of that logic to be right either)