Announcement

Collapse
No announcement yet.

E-450 graphics performance issues

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • #16
    The power states look rather strange to me altogether:

    Code:
    [    7.630610] [drm:radeon_pm_print_states], 6 Power State(s)
    [    7.630615] [drm:radeon_pm_print_states], State 0: Default
    [    7.630618] [drm:radeon_pm_print_states],    1 Clock Mode(s)
    [    7.630621] [drm:radeon_pm_print_states],            0 e: 275000
    [    7.630625] [drm:radeon_pm_print_states], State 1: Default
    [    7.630628] [drm:radeon_pm_print_states],    1 Clock Mode(s)
    [    7.630631] [drm:radeon_pm_print_states],            0 e: 507700
    [    7.630634] [drm:radeon_pm_print_states], State 2: Battery
    [    7.630637] [drm:radeon_pm_print_states],    1 Clock Mode(s)
    [    7.630639] [drm:radeon_pm_print_states],            0 e: 275000
    [    7.630642] [drm:radeon_pm_print_states], State 3: Performance
    [    7.630645] [drm:radeon_pm_print_states],    2 Clock Mode(s)
    [    7.630648] [drm:radeon_pm_print_states],            0 e: 275000     No display only
    [    7.630651] [drm:radeon_pm_print_states],            1 e: 507700
    [    7.630654] [drm:radeon_pm_print_states], State 4: Default
    [    7.630657] [drm:radeon_pm_print_states],    Default
    [    7.630660] [drm:radeon_pm_print_states], 
    [    7.630664] [drm:radeon_pm_print_states],            0 e: 200000     No display only
    [    7.630667] [drm:radeon_pm_print_states],            1 e: 200000
    [    7.630670] [drm:radeon_pm_print_states], State 5: Default
    [    7.630673] [drm:radeon_pm_print_states],    1 Clock Mode(s)
    [    7.630676] [drm:radeon_pm_print_states],            0 e: 173690
    Maybe this confuses the driver and tricks into selecting only the last two states.

    Comment


    • #17
      ...and that is indeed what is happening. I made some crude hacks to get profiles with 275 and 507 MHz clocks working, and they work fine. It's definitely a night-and-day difference, especially at the full clock.

      Now, what's up with those tables? Does the driver actually parse them correctly? The E-450 introduces a new turbo mode for the GPU, maybe that's handled with a new format in the powerplay tables. Or is it just Lenovo screwing up? fglrx seems to handle it correctly.

      Overall, from what I've seen the power management code seems to need a lot of work...
      Last edited by brent; 07-07-2012, 10:27 PM.

      Comment


      • #18
        Overall, from what I've seen the power management code seems to need a lot of work...
        True, and I believe the response has been "patches welcome, we'll work on it later if we have time"

        One tweak I guess would be fairly easy would be to make the "high" profile really pick the highest mode.

        Comment


        • #19
          I'm willing to work on it, but it appears that power management features are entirely missing in the available documentation. In fact, Evergreen hardware is not documented at all. Shame on you, AMD.
          Last edited by brent; 07-08-2012, 02:16 PM.

          Comment


          • #20
            Originally posted by brent View Post
            but it appears that power management features are entirely missing in the available documentation.... Shame on you, AMD.
            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 ?

            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 ?

            Originally posted by brent View Post
            In fact, Evergreen hardware is not documented at all.
            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/AMDAPP...chitecture.pdf

            Other than a few things like attribute interpolation (covered by the ISA guide, highlights at front + details in section 8) and compute support (ISA guide again, plus Tom and others in the community are writing and publishing code) the Evergreen and NI generations is programmed in the same way described in the 6xx/7xx documentation... it's really SI (GCN) hardware where we need another slug of documentation and that's one of the things being worked on now.

            There are gaps in areas where the devs are still trying to find correct info (eg DP-to-analog bridge chips) but unfortunately that falls into the "documenting things we don't know yet" bucket ;(

            In case you didn't know about the ISA guides, please check out the bottom of the RadeonFeature page : http://www.x.org/wiki/RadeonFeature
            Last edited by bridgman; 07-08-2012, 03:04 PM.

            Comment


            • #21
              Originally posted by bridgman View Post
              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.

              Comment


              • #22
                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 ?
                Last edited by bridgman; 07-08-2012, 03:18 PM.

                Comment


                • #23
                  Originally posted by bridgman View Post
                  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"

                  Comment


                  • #24
                    Originally posted by bridgman View Post
                    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/AMDAPP...chitecture.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.
                    Last edited by brent; 07-08-2012, 07:41 PM.

                    Comment


                    • #25
                      Originally posted by brent View Post
                      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

                      Originally posted by brent View Post
                      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/2.../msg00161.html

                      Originally posted by brent View Post
                      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.

                      Originally posted by brent View Post
                      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.

                      Originally posted by brent View Post
                      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 ?

                      Originally posted by brent View Post
                      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.
                      Last edited by bridgman; 07-08-2012, 08:55 PM.

                      Comment


                      • #26
                        Originally posted by bridgman View Post
                        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.
                        Last edited by smitty3268; 07-08-2012, 09:00 PM.

                        Comment


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

                          Comment


                          • #28
                            Originally posted by brent View Post
                            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.

                            Originally posted by brent View Post
                            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 )

                            Comment


                            • #29
                              Originally posted by bridgman View Post
                              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) ?".
                              Last edited by bridgman; 07-08-2012, 09:42 PM.

                              Comment


                              • #30
                                Originally posted by bridgman View Post
                                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.

                                Comment

                                Working...
                                X