The State Of Open-Source Radeon Driver Features

[bridgman]

IAnyway. Don't mind me. I just had high hopes for that.

The bigger question is still "if so many people want better power management, and if people are already tweaking the code on their own personal systems, why aren't we seeing improvements in the common code ?".

[tstrunk]

There's a middle ground that we all have trouble with...

Don't give up... but don't assume it's coming for sure either... and do reasonable things in the meantime.

Of course this leads to a discussion about what is "reasonable", which was going on for thousands of years before we had Linux or open source drivers

The bigger question is still "if so many people want better power management, and if people are already successfuly tweaking the code on their own personal systems, why aren't we seeing improvements in the common code ?".

First of all: thanks for going the extra mile to provide also an open-source driver.
But here is my question:

I know fglrx in total will never be open source due to lots of license issues and IP, which AMD can never release, because it doesn't belong to them. What I don't understand is, why AMD doesn't release the parts of the driver as open source, which definitely belong to them. I heard the power management code is one of the biggest chunks inside of fglrx and I suppose that due to its proprietary nature, it cannot contain much licensed code. Again due to its proprietary nature it should be completely useless to your competitors.
I also know that a power management library ripped out of fglrx as such will be just a big hunk of useless code for the open source devs, because of missing interfaces. It won't even compile. But the logic, which says when to switch into which state; when to write what into which register, should be applicable also to the open driver.

Oh and while we are at it: Exactly the same question for the OpenCL client library. It would make so much sense to at least open source the ICD loader and put it under a BSD license. Like that it could be included by default in any linux distribution and it could be established as _THE_ standard implementation. Just recently I had to do a rollout of two different clients of our software for nvidia and amd graphics cards, because of subtle differences in the ICD loader. In my opinion the first one offering a free (GPL or BSD) solution for an OpenCL ICD loader library (one which can be linked statically under linux) will be the standard distributor of that lib for all eternity. Sorry for the off-topic.

[89c51]

The bigger question is still "if so many people want better power management, and if people are already tweaking the code on their own personal systems, why aren't we seeing improvements in the common code ?".

Knowledge, ability and will are all needed in order to write driver code. You can't get away with 2/3 or 1/3. Most people have the will but nothing else.

[bridgman]

Knowledge, ability and will are all needed in order to write driver code. You can't get away with 2/3 or 1/3. Most people have the will but nothing else.

Sure, but knowledge doesn't come down in a flash of lightning... you look at code, ask questions, try things, ask more questions, and after a while it starts to make sense. Nobody learned how to write graphics drivers at school, AFAIK. Nobody was born knowing how to write drivers either.

You basically trade will for knowledge and ability

[bridgman]

But here is my question:
... same questions everyone asks...

re: kernel driver, power management etc...

If we have trouble getting approval to release a specific block of programming info, do you think we would have an easier time releasing the same info mixed with 5 million lines of proprietary source code, particularly when that source code is written to work across multiple OSes and most of those OSes *require* robust DRM as part of the design ?

re: client driver...

The GPU business is *very* competitive, and small differences in performance & features drive many of the buying decisions. The cost of driver development is the primary entry barrier for new competitors. Why would an established vendor give away their competitive advantage ?

There is a standard client lib already (mesa) -- are you sure you want to see it replaced with something 10x the size and optimized for one specific HW vendor ?

[89c51]

Well of course you are not born with knowledge but there is a difference in a Computer scientist/engineer than the hobbyist who knows how to write hello word in C and Java and wants to contribute.

The GPU business is *very* competitive, and small differences in performance & features drive many of the buying decisions. The cost of driver development is the primary entry barrier for new competitors. Why would an established vendor give away their competitive advantage ?

On the non mobile "space" there are only two (2) companies competing in hi end GPUs.

[dfx.]

What other possible answer is there ?

well, something like "now, when we dropped a hell of the load of hardware support from our shitty, glitched like a hallucinating crack-addicted whore, binary driver, we can spare a few guys to make all those AMD-hw-stuffed laptops usable and stop wasting your electricity" would be a damn nice answer.

for serious PC-gaming even on Windows©, with such frivolous support-drops, lack of PhysX-support and similarly glitched drivers (see Rage fiasco), AMD GPU hardware doesn't look very promising (only performance/price ratio still saves it. existence of which also means that managers know that and set prices accordingly). even i (AMD-fanboy from early teen years) really tempted nowadays to buy low-power Intel-based desktop and a PS3 (i'm using PS3 gamepad for gaming anyway, might as well drop xbox-gamepad emulation bullshit and delete Windows© altogether, will be able to play some MGS: GZ like a boss as a bonus).

...and most of those OSes *require* robust DRM as part of the design...

"robust DRM" - such a powerfull oxymoron. pursuit of which is also so damn unethical, one of biggest scams in computational technology.

The GPU business is *very* competitive, and small differences in performance & features drive many of the buying decisions.

so "competitive", that there is like 3 desktop GPU vendors in the entire world, one of which almost isn't conserned with rendering speed, heh.

The cost of driver development is the primary entry barrier for new competitors. Why would an established vendor give away their competitive advantage ?

that's one is right in the bullseye: _hardware vendors competing primarely with software tricks_. it couldn't be any more ass-backwards.
and using that order of things to prevent newcomers to break the oligopoly.

daaamn, i so dream of the day, when anti-monolopy commitees of the world would rise from their asses and break some ties in this situation. but i might as well wait for unicorns to ascend from the sky to help us... or for "robust DRM" to start making sense, materialise and fuck all our cumputers up beyond saving.

PS: don't take all this as a some kind of personal insult. it's just that PM is a hot topic and it pisses me the fuck off. i know you only saying a sad, sad truth.

[airlied]

Correct. Still working on it though.

Again, there's a lot of PM info out there now. This is just a couple of additional blocks.

PM seems to be an exception to the rest of the driver stack -- everyone seems to want it but hardly anyone seems to be willing to work on it. For most of the other bits it seems that every N'th user is willing to roll up their sleeves and make the code better but it's not happening here.

John can you stop spreading this BS, it really isn't possible to improve the current PM code to anywhere near the degree you think. The problem is the atom tables (for setting engine and memory clocks) aren't used or tested in this way by the fglrx driver, so they have no QE beyond the BIOS using them at startup to set the clocks. The time taken to execute the tables is longer than vblank on a lot of cards, and this would require writing per-card/memory attached specific tables to try and allow the reclock to run in under a vblank time limit.

Really you guys know how the cards work, and fglrx works with them, anything else is pointless since its using functionality that hasn't been exercised or QAed.

please stop making excuses. you could maybe improve r500 to the level of fglrx but r600 and upwards its a waste of time and it would require years of testing before we could enable it by default, since no other drivers have ever tested these codepaths.

Dave

[jrch2k8]

John can you stop spreading this BS, it really isn't possible to improve the current PM code to anywhere near the degree you think. The problem is the atom tables (for setting engine and memory clocks) aren't used or tested in this way by the fglrx driver, so they have no QE beyond the BIOS using them at startup to set the clocks. The time taken to execute the tables is longer than vblank on a lot of cards, and this would require writing per-card/memory attached specific tables to try and allow the reclock to run in under a vblank time limit.

Really you guys know how the cards work, and fglrx works with them, anything else is pointless since its using functionality that hasn't been exercised or QAed.

please stop making excuses. you could maybe improve r500 to the level of fglrx but r600 and upwards its a waste of time and it would require years of testing before we could enable it by default, since no other drivers have ever tested these codepaths.

Dave

and that explain why 5million LOC in the fglrx PM code <-- was too easy for let it go bridgman (just a joke)

[bridgman]

John can you stop spreading this BS, it really isn't possible to improve the current PM code to anywhere near the degree you think.

You might be thinking that I'm thinking about a higher level of support than... um... than you think. (that didn't come out right)

The problem is the atom tables (for setting engine and memory clocks) aren't used or tested in this way by the fglrx driver, so they have no QE beyond the BIOS using them at startup to set the clocks. The time taken to execute the tables is longer than vblank on a lot of cards, and this would require writing per-card/memory attached specific tables to try and allow the reclock to run in under a vblank time limit.

Yes, although AFAICS the biggest pain point for users is not lack of slick dynamic PM but not even having enough entries in the tables to use the current profile mechanism fully. First priority would seem to be interpolating between the low and high settings in the current tables.

Really you guys know how the cards work, and fglrx works with them, anything else is pointless since its using functionality that hasn't been exercised or QAed.

Yep, and at least for 6xx/7xx the hardware is simple enough that the driver could do the same thing (again, for static not dynamic PM).

please stop making excuses. you could maybe improve r500 to the level of fglrx but r600 and upwards its a waste of time and it would require years of testing before we could enable it by default, since no other drivers have ever tested these codepaths.

I don't think I'm saying (or thinking) anything that would count as an excuse. Increasingly I think I'm seeing hardware without enough power states for the current profile mechanism to work, and I do think there are options for improving that.

Is it worth trying to match fglrx with the current code ? I don't think so (other than for r600 and below). Is it worth improving the current code enough to give a bunch of current users full use of the profile mechanism (and maybe a few options in between), particularly on middling-old hardwere ? I think so...

Now, if you're saying that my perception of a non-trivial number of users not having enough entries in the power tables to be able to make good use of low/mid/hi settings is completely wrong, then maybe we are at the limit of what can be done today and I'll shut up