Open ATI Driver More Popular Than Catalyst

[bridgman]

For a long time most of the effort went into getting the stack running over a decent memory manager. I don't think that work is quite finished yet. Once it is, though, I think you'll see faster progress in other areas.

Note that LLVM isn't likely to be a happening thing for low level shader compilation (below IL/TGSI) for quite a while -- it doesn't really handle VLIW at all in its current form. My sense was that shader utilization (compiler efficiency) was not the bottleneck anyways - reducing draw command overhead and increasing parallelism / pipelining between GPU and driver execution were the big things AFAIK.

[frantaylor]

Kano, every driver has its problems and bugs that go unresolved for long periods of time... Hell, I still have a NVIDIA driver bug that's been open now for about four years or so concerning CoolBits and Xinerama.

Did it ever work right? Regressions are MUCH more important to fix than things that have never worked in the first place.

[smitty3268]

Note that LLVM isn't likely to be a happening thing for low level shader compilation (below IL/TGSI) for quite a while -- it doesn't really handle VLIW at all in its current form. My sense was that shader utilization (compiler efficiency) was not the bottleneck anyways - reducing draw command overhead and increasing parallelism / pipelining between GPU and driver execution were the big things AFAIK.

Is VLIW support something Itanium needs? Just wondering if there's any chance of someone else helping out with it or if it will need to come from the radeon developers to make it happen.

It probably doesn't make a whole lot of sense to drop the current compiler while you are still able to share it with the non-gallium driver, but I do hope this gets worked on eventually when gallium gets more mature. I really don't think the custom code in the drivers is going to be able to compete with the optimizations created by a dedicated compiler team.

[smitty3268]

Did it ever work right? Regressions are MUCH more important to fix than things that have never worked in the first place.

All things being equal, yes. But on the other hand, a regression that only affects 10 people using an unmaintained rarely used app is a lot less important than a bug that's never worked but affects millions on a daily basis. Which is exactly the point that AMD was making about that bug which deanjo seems to disagree with so strongly.

Lets be honest, we all know that fglrx is buggier than the current nvidia drivers. But they aren't unusable, or the devil's spawn either. Hopefully the day will soon come when the OSS drivers have decent OGL3 support and we can all forget about fglrx for good

[frantaylor]

There is no way to determine the impact of a regression

a regression that only affects 10 people using an unmaintained rarely used app

This is NOT my experience with regressions. I test software for a living and I find odd weird regressions all the time. Invariably they end up having much more impact than you might think.

Here is a common scenario: A regression is found in a "rarely used app" and a bug report is filed. The developers say "this is a rarely used app" and they mark the bug as "we are not going to fix it". Others come across the same bug, find the bug report, see that the developers are indifferent, and they either code around it or they just drop the buggy piece of code and switch to something else. The developers have no idea that this has happened. Since it is free software, there are no sales to affect and no salesmen to beat up the developers to fix it.

Really the only sane approach is to take a serious effort to fix any regression, no matter how minor it seems.

[smitty3268]

This is NOT my experience with regressions. I test software for a living and I find odd weird regressions all the time. Invariably they end up having much more impact than you might think.

Here is a common scenario: A regression is found in a "rarely used app" and a bug report is filed. The developers say "this is a rarely used app" and they mark the bug as "we are not going to fix it". Others come across the same bug, find the bug report, see that the developers are indifferent, and they either code around it or they just drop the buggy piece of code and switch to something else. The developers have no idea that this has happened. Since it is free software, there are no sales to affect and no salesmen to beat up the developers to fix it.

Really the only sane approach is to take a serious effort to fix any regression, no matter how minor it seems.

I'm certainly not saying regressions are unimportant, quite the opposite. But any sane development team is going to prioritize the bug reports they get, and if you think that regressions should always automatically go on top no matter what the situation, then I would have to disagree.

[MostAwesomeDude]

It probably doesn't make a whole lot of sense to drop the current compiler while you are still able to share it with the non-gallium driver, but I do hope this gets worked on eventually when gallium gets more mature. I really don't think the custom code in the drivers is going to be able to compete with the optimizations created by a dedicated compiler team.

Other way around. r300g borrows the compiler from classic r300.

r300/r500 is *not* a good venue for LLVM. r600 is a bit more amenable. And for the record, I really don't think the custom code in LLVM is going to be able to compete with the optimizations created by fglrx's team.

[smitty3268]

r300/r500 is *not* a good venue for LLVM. r600 is a bit more amenable.

Can you elaborate why? Do they have too much fixed-function hardware and not enough shader power, or what?

And for the record, I really don't think the custom code in LLVM is going to be able to compete with the optimizations created by fglrx's team.

Sorry, I meant the OSS drivers. I don't think LLVM will be able to compete with fglrx either, I just think it will be closer.

[mirv]

idtech5 is an bullshit backward engine only for bullshit Xbox360/playstation3 hardware with only 256mb-ram/512mb-Ram.

IDtech5 is the worst i ever read abaut....


ArmA2 vor an exampel is an Killer Engine for Big workstations 12Cores 32gb ram 2GB-Vram Grafic-cards

and you need 2 pices of 5870 to play it!


for idtech5 you need a backward graficcard with no power and you need no ram and no and no.. nothing????

idtech 5 is bullshit!

idtech4 has more features than idtech5!

day and night! idtech5 can only handle DAY-Time!

I'm not sure why you think so lowly of id tech 5 - I think it's quite impressive. Certainly it won't run on the open source drivers, but from everything I've read and seen about it, it's quite an advanced engine so there shouldn't be any surprise there.

[dgrafenhofer]

...bullshit...bullshit...

IDtech5 is the worst i ever read abaut....

... and no and no.. nothing????

... is bullshit!

(rant)
I am sorry to say this, but you are getting more and more on everybody's nerves with your inflammatory and trollish comments. I know that you are not a native speaker - me neither, but somebody has to tell you that your usage of swear words is completely out of place.
(/rant)