The State Of Open-Source Radeon Driver Features

[airlied]

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)



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.

Hmm most the feedback I see if for dynamic PM not better static PM, static PM is crap, no use in laptops at all, we also want to be able to use the Fusion GPUs up to their package limits, like we can't upclock the APU because it'll overheat, so even if the BIOS has the table we can't use it because we have no decent thermal protection. We should be able to use AMD APU like we use Intel CPUs and we can't. There are so many problems we just can't solve and the ones we can solve there is little demand from people I talk to.

static profiles might work for people on phoronix, but they don't save power for the 99% of people who install RHEL and never read the online docs (i.e. my customers).

Dave.

[bridgman]

I don't think there's any disagreement on where we need to get to... the only question is whether it's worth doing anything in the interim.

Static PM is just a first step, but the most unhappy users I see are the ones who can't even get that working with help. I agree static PM is a non-starter for server customers and that is one of the points we're using to drive discussions internally; not sure I completely agree about laptops though.

[airlied]

I don't think there's any disagreement on where we need to get to... the only question is whether it's worth doing anything in the interim.

Static PM is just a first step, but the most unhappy users I see are the ones who can't even get that working with help. I agree static PM is a non-starter for server customers and that is one of the points we're using to drive discussions internally; not sure I completely agree about laptops though.

If the users make it this far to ask then they are in the possibly 5% of users who care, I can't provide a proper OS on top of that, its crap.

In servers we care a bit, but on laptops they need to the right thing without specific configuration, the shit we did 5 years ago doesn't cut it any more, and its not like this stuff is getting simpler, so doing the dumb thing for evermore is just pointless. By the time we get to doing smart stuff for any of the current GPUs they'll find another reason for blocking doing smart stuff for newer chips. This requires someone in AMD with some power to overrule the idiocy that is blocking PM code. You guys own the hardware, you guys are diong the same things as nvidia and intel, if you have some innvoation in r600-trinity that nobody knows about at this stage I'd be shocked and amazed that anyone gives a shit. Just release the code already, and arrange for anyone who tries to block it to find a new position where being an idiot is acceptable.

Dave.

[bridgman]

Ahh, I think I see the disconnect. You're talking about this as an either-or, where working on current PM code is an alternative to (or, worse, could delay) the release of more information.

I'm just saying "that work is proceeding, but maybe not as fast as we would like, what do we do in the meantime ?".

[89c51]

I'm just saying "that work is proceeding, but maybe not as fast as we would like, what do we do in the meantime ?".

Pray for some pissed hacker to reverse engineer the thing and release the code.

[airlied]

Ahh, I think I see the disconnect. You're talking about this as an either-or, where working on current PM code is an alternative to (or, worse, could delay) the release of more information.

I'm just saying "that work is proceeding, but maybe not as fast as we would like, what do we do in the meantime ?".

Well if someone rips up the current code and makes it a lot better, the work you've done will require another rewrite and then let me guess another review, which someone else will find another reason to block. The best chance is for the current code to not move so we can avoid any future AMD review process :-)

But really AMD spent a lot of money on hw designers to make the chips do this stuff, actively working against the hw designers design seems both pointless and stupid, especially when the same company is paying people to waste their time.

Dave.

[Kano]

Well maybe amd has to update the legacy driver branch(es) to support newer xservers until the oss driver has pm, that would be a logical consequence - but most likely amd want to be responsible for lots of overheating laptops running Linux.

[jrch2k8]

Well if someone rips up the current code and makes it a lot better, the work you've done will require another rewrite and then let me guess another review, which someone else will find another reason to block. The best chance is for the current code to not move so we can avoid any future AMD review process :-)

But really AMD spent a lot of money on hw designers to make the chips do this stuff, actively working against the hw designers design seems both pointless and stupid, especially when the same company is paying people to waste their time.

Dave.

i kinda remember[ish] that nouveau had a set of tools to intercept every call made to the GPU and i think it somehow extracted pm data too[i remember sending dumps of my old but thrustworthy 8800gts], so maybe this tool could be modified to do the same thing with FGLRX and keep that code out of tree along with a place to keep the dumps??

[mjg59]

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...

Having written a bunch of the existing Radeon PM code, I've no doubt that it could be better. But the incentive to make it better when we know that we *can't* make it as anywhere near as useful as fglrx is limited. Any kind of worthwhile power management on Radeon is going to involve running code on the chip itself, and that's not something you've documented. So yeah, I could spend a few months on getting us reliably reclocking during vblank, but it'd still be something that almost everyone would turn off because it'd have an awful performance impact. There's just not a great deal of incentive, especially since AMD have already written code to do it and are choosing not to release it.

[bridgman]

Having written a bunch of the existing Radeon PM code, I've no doubt that it could be better. But the incentive to make it better when we know that we *can't* make it as anywhere near as useful as fglrx is limited. Any kind of worthwhile power management on Radeon is going to involve running code on the chip itself, and that's not something you've documented. So yeah, I could spend a few months on getting us reliably reclocking during vblank, but it'd still be something that almost everyone would turn off because it'd have an awful performance impact. There's just not a great deal of incentive, especially since AMD have already written code to do it and are choosing not to release it.

Hi Matthew;

I had the same discussion with Dave a page or two back. I'm not even suggesting going that far at this point.

I don't understand your comment about "already written code". I'm sure you understand that for new hardware writing code is just the first step of what can be a very long process with a lot of rewrites and may never result in a release. It's possible that the info you received under NDA was incomplete and suggested that the code was going to be released very soon, if so please let me know privately and I'll try to fix that.