E-450 graphics performance issues

[89c51]

Between the existing code, comments in the code, and agd5f's blog posts (eg http://www.botchco.com/agd5f/?p=45) what do you think is missing ?

Sorry but regarding proper (whatever that means) PM you admitted that there are things missing because you cannot release them.

[bridgman]

Sure... that would fall into the "not documenting things we can't release yet" bucket.

I don't think that justifies a "Shame on you, AMD" comment, do you ?

[89c51]

Sure... that would fall into the "not documenting things we can't release yet" bucket.

I don't think that justifies a "Shame on you, AMD" comment, do you ?

The only "Shame on you, AMD" comments that i justify are the ones made for when the blob fucks up.

Yes i would like the documents (UVD, PM, whatever) to come quicker but i believe you work on it. If you don't then "Shame on you AMD"

[brent]

Just to be clear, are you saying "shame on us" for :

- not documenting what we don't know yet or can't release yet ? (remember we have to figure out the hardware by getting code working first before we can *write* documentation)
- not doing enough documentation about the parts we do know and the code we have released ?
- working on higher priority things like fixing corruption/hangs or implementing initial support for new hardware instead of improving power management ?
- something else ?

It's a shame because Evergreen hardware is now almost three years old, and there is still no proper documentation. It's a shame because a lot of things are only "documented" in code (which is a very bad substitute for proper docs). It's a shame because there is no central place to get to the various bits of information.

I know the shame line is a bit of a hyperbole, but it definitely provoked an actual reaction - as opposed to the earlier posts.

Between the existing code, comments in the code, and agd5f's blog posts (eg http://www.botchco.com/agd5f/?p=45) what do you think is missing ?

Well, for instance a detailed AtomBIOS documentation. E.g. what does EnableASIC_StaticPwrMgt do? (This so-called "static power management" is used by the old UMS driver, but not by the KMS driver.) What is the exact format of the PowerPlay tables? And so on. Moreover, how does clock gating work on R600+? What about advanced features like framebuffer compression or reducing screen refresh rate? Or in short, how to get power consumption to the same level as fglrx?

Brazos is pretty awesome hardware, and it can be very power efficient. My notebook idles at just a bit over 5W in the best case. That's better than my old Atom netbook that used a much smaller screen! Unfortunately with the open source drivers it uses over 7W when idling. I would really like to change this.

The biggest changes between generations are in the shader core, and we release ISA guides for each new shader core. Please take a read through the Evergreen ISA guide at your convenience (especially section 8) and let me know what you think is missing :

http://developer.amd.com/sdks/AMDAPPSDK/assets/AMD_Evergreen-Family_Instruction_Set_Architecture.pdf

Yes, but that is literally the only official document specific to Evergreen hardware, as far as I can see. And it's not what I'm interested in. I'm sure there have been *many* changes in power management between R600 and R800/Brazos hardware, so i doubt R600 documentation will be useful.

[bridgman]

I know the shame line is a bit of a hyperbole, but it definitely provoked an actual reaction - as opposed to the earlier posts.

I was out cutting grass and pulling weeds. Sorry we're not working 24/7 on the weekends

Well, for instance a detailed AtomBIOS documentation. E.g. what does EnableASIC_StaticPwrMgt do? (This so-called "static power management" is used by the old UMS driver, but not by the KMS driver.)

http://lists.opensuse.org/radeonhd/2009-06/msg00161.html

What is the exact format of the PowerPlay tables?

We push an updated version of atombios.h and associated tables with each new hardware generation.

Moreover, how does clock gating work on R600+?

I don't think we know yet (which makes it hard to document). Again, is your complaint that we're not documenting enough about the things we know, or that we're not documenting the things we haven't figured out yet or don't have permission to release yet ? One more time -- first we need to figure out how the hardware works and get it running properly so we can write the documentation, and then see if we can get approval to release it (the last two run in parallel a bit). That is being worked on now... we've said this a couple of times recently.

We were expecting to see community improvements in the current code, but realized recently that developers were holding off, reasoning that future PM documentation and code might simplify the work and obsolete some of the code they wrote. I wasn't expecting that but in hindsight I guess it makes sense.

Yes, but that is literally the only official document specific to Evergreen hardware, as far as I can see. And it's not what I'm interested in..

Perhaps, but it is where most of the changes have occurred. Are you really talking about Evergreen or about Brazos ?

I'm sure there have been *many* changes in power management between R600 and R800/Brazos hardware, so i doubt R600 documentation will be useful.

Actually no, the core functionality is the same. There are some additional generation-specific bits we don't have approval to release yet, basically some blending between CPU and GPU power management. The initial PM code agd5f pushed uses hardware which is the same across all generations.

[smitty3268]

Again, is your complaint that we're not documenting enough about the things we know, or that we're not documenting the things we haven't figured out yet or don't have permission to release yet ?

Not to speak for Brent, but I suspect the complaint is about the end result of not having enough public documentation. The reasons for why that's happening is something for AMD to figure out internally, it doesn't change the end-result.

[bridgman]

Yeah, but if that's the case I wish people would actually say that. I might even agree

[glisse]

It's a shame because Evergreen hardware is now almost three years old, and there is still no proper documentation. It's a shame because a lot of things are only "documented" in code (which is a very bad substitute for proper docs). It's a shame because there is no central place to get to the various bits of information.

I think people are just dreaming, as far as i know there is no magic documentation that take you by the through all the things you need to understand. GPU are not changing that fast and anyone that know how works a gpu from few years ago already have all the needed knowledge. I am not saying it wouldn't be nice to have better documentation. I am saying it will cost valuable time to people that know to produce this documentation and i don't think it will bring a lot of new contributor.

Well, for instance a detailed AtomBIOS documentation. E.g. what does EnableASIC_StaticPwrMgt do? (This so-called "static power management" is used by the old UMS driver, but not by the KMS driver.) What is the exact format of the PowerPlay tables? And so on. Moreover, how does clock gating work on R600+? What about advanced features like framebuffer compression or reducing screen refresh rate? Or in short, how to get power consumption to the same level as fglrx?

[...]

Yes, but that is literally the only official document specific to Evergreen hardware, as far as I can see. And it's not what I'm interested in. I'm sure there have been *many* changes in power management between R600 and R800/Brazos hardware, so i doubt R600 documentation will be useful.

If you want to know what does a specific atombios function just use atombiosdisasm tools to look at the atombios code. It's not secret. All the knowledge you need is there, i agree it's scattered but where would be the fun if it wasn't.

If you really want to match fglrx just reverse engineer fglrx, in the end the closed driver is the documentation and only way to access that information is through reverse engineering. Nothing stop you from doing so.

I just don't get this please document things when pretty much all the informations is out there (catchy line from the X-Files )

[bridgman]

Are you really talking about Evergreen or about Brazos ?

Sorry, that should have read "<6xx/7xx to Evergreen> (where most of the changes are in the ISA doc) or <Evergreen to Brazos>" (where that is not so much the case) ?".

[brent]

Sorry, that should have read "<6xx/7xx to Evergreen> (where most of the changes are in the ISA doc) or <Evergreen to Brazos>" (where that is not so much the case) ?".

The code names are confusing. I meant R600 to Evergreen.

If you want to know what does a specific atombios function just use atombiosdisasm tools to look at the atombios code.

Well, in the end most AtomBIOS functions just do some register magic, so that is not very helpful.

I just don't get this please document things when pretty much all the informations is out there

That's not very convincing. Of course you can always reverse-engineer the hell out of anything, but that's not a very satisfying, easy or quick approach. And it's definitely not what AMD promised.

About clock gating:

I don't think we know yet (which makes it hard to document). Again, is your complaint that we're not documenting enough about the things we know, or that we're not documenting the things we haven't figured out yet or don't have permission to release yet ? One more time -- first we need to figure out how the hardware works and get it running properly so we can write the documentation, and then see if we can get approval to release it (the last two run in parallel a bit). That is being worked on now... we've said this a couple of times recently.

Well, I don't really see what's so very hard about that. There must be some internal documentation, or at least code in fglrx. Power management is a pretty isolated feature set, and probably doesn't amount to a lot of code, either. Just have someone sit down and at least give some basic pointers about how it is supposed to work, please? I browsed through the RV630 register documentation and family 14h BKDG, but there's no real pointer on where to start with GPU clock gating. I am tapping in the dark. IMHO it's strange how everything related to CPU and NB is documented quite thoroughly, while the GPU is hardly documented at all.