Why do you need a xorg.conf file these days for oss drivers? Wouldnt it be more logical when those options are default?
Announcement
Collapse
No announcement yet.
E-450 graphics performance issues
Collapse
X
-
I already enabled 2D color tiling earlier, and it seems to help a little bit, but not much. Performance still is largely pathologically bad. For instance, a simple GLSL-based plasma effect I made a while ago runs with approximately similar performance to GMA950, again. It's a very simple fragment shader, yet a fullscreen window of it runs at just ~20 fps.
Is this really the current state of Mesa's APU support? What's holding back performance?
Comment
-
Originally posted by brent View PostIs this really the current state of Mesa's APU support? What's holding back performance?
Comment
-
fglrx offers great OpenGL support and performance, and power management is also much better (~1W less at idle!), but literally everything else is worse or completely broken. I don't care that much for the driver being closed-source, but features like suspend to ram simply must work reliably. OTOH, I don't need superb OpenGL support/performance, but it should be *acceptable* at least.
Performance is fluid on my APU systems.
agd5f, by the way, do you know if power management works correctly on Brazos APUs? As I said before, radeon_pm_info spits out some rather nonsensical values. Is the GPU actually clocked correctly up to its full frequency? I did some simple tests and observed no difference between low/mid/high profiles or dynpm. What power management features are missing to make power consumption as low as with fgrlx?Last edited by brent; 07 July 2012, 11:21 AM.
Comment
-
I enabled some DRM debugging, and this is what I see for *every* call to r600_get_dynpm_state:
[25233.444967] [drm:r600_pm_get_dynpm_state], Requested: e: 17369 m: 0 p: 1
Comment
-
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
Comment
-
...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 July 2012, 10:27 PM.
Comment
-
Overall, from what I've seen the power management code seems to need a lot of work...
One tweak I guess would be fairly easy would be to make the "high" profile really pick the highest mode.
Comment
-
-
Originally posted by brent View Postbut it appears that power management features are entirely missing in the available documentation.... Shame on you, AMD.
- 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 PostIn fact, Evergreen hardware is not documented at all.
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/RadeonFeatureLast edited by bridgman; 08 July 2012, 03:04 PM.Test signature
Comment
Comment