Discussion: the ati/radeon open source drivers & radeon repository

ijanos · 2010-05-03 14:21:52

megawebmaster wrote:

...I've got Mobility HD 4570...

How cold you can make your card with power management enabled?
The i can make mine drop to 62°C from 74°C, but it is still far from ideal.

Perry3D · 2010-05-03 17:08:13

megawebmaster wrote:

I could say, that I'm using Xorg 1.8, kernel26-drm-radeon-testing and testing/xf86-video-ati - with Compiz my screen could freeze in any moment, but with Metacity and it's compositing - there is no problem. I've got Mobility HD 4570, so this must be problem between Compiz and Xorg 1.8.

insanemal wrote:

Xorg 1.8 currently makes my r700 freeze at random.
There is a bug report for it.
Just an FYI

Maybe you should switch back to xorg 1.7. And you can try disabling dynpm in /sys/class/drm/card0. (echo 0 > /sys/class/drm/card0/dynpm)

megawebmaster · 2010-05-03 21:02:38

Huh, if it will be so easy - I've installed so many packages depending on Xorg 1.8 that after downgrading mouse and keyboard stopped running in X Now I'm using Metacity + Cairo-dock (Open-GL version) all day and nothing happend - no freezes.

@ijanos - my temperatures has gone down around 5-7 degrees only... From 60-62 to 55*C. And fan is killin' me the same way... I have to say that after first start (i.e. after night ) when everything is cold my system turns off fans (which was really surprise for me) then when I will start using notebook temperature is going up and stops (idle) on 55*C. I'm using 2.0 governor for card.

ijanos · 2010-05-03 21:42:34

megawebmaster wrote:

@ijanos - my temperatures has gone down around 5-7 degrees only... From 60-62 to 55*C. And fan is killin' me the same way... I have to say that after first start (i.e. after night ) when everything is cold my system turns off fans (which was really surprise for me) then when I will start using notebook temperature is going up and stops (idle) on 55*C. I'm using 2.0 governor for card.

I see, thanks. Hopefully it will be better when voltage control will be implemented.

1311219 · 2010-05-04 09:22:34

Ok, I got a (potentially dumb) question: does these drivers lack proper VBO support? It works, but seems to be a software implementation (gives no speed increase).

I've tried the NeHe lesson 45 (http://nehe.gamedev.net/data/lessons/li … n45.tar.gz) example, and using the proprietary ati drivers (both on arch and windows) switching to vbo gives approximately 2500fps (compiling with vbo disabled gives 300fps). But when using the open drivers I only get aroun 60fps with or without VBO.

Don't get me wrong, I like the open drivers - they work good, and 60fps when rendering ~33000 triangles in that demo is still good. But I'm currently working on a program that will use vbo optimization (because it needs to render an awful lot of stuff quickly), and would really need this functionality...

This might even be related to my hardware: ATI Technologies Inc RV730 Pro AGP [Radeon HD 4600 Series] - which is on AGP bus (not pci express).

If anyone got the time, please try the NeHe demo (only requires SDL to compile), and see if you have better luck.

thanks!

btw: I do get a note about "IRQ's not enabled, falling back to busy waits: 2 0" when initializing opengl.... I thought the latest drivers supported IRQ? or am I still on the old (stable) drivers despite installing the packages from Perry's repo?

Perry3D · 2010-05-04 09:30:15

1311219 wrote:

Ok, I got a (potentially dumb) question: does these drivers lack proper VBO support? It works, but seems to be a software implementation (gives no speed increase).
I've tried the NeHe lesson 45 (http://nehe.gamedev.net/data/lessons/li … n45.tar.gz) example, and using the proprietary ati drivers (both on arch and windows) switching to vbo gives approximately 2500fps (compiling with vbo disabled gives 300fps). But when using the open drivers I only get aroun 60fps with or without VBO.

I don't know anything about VBO support. But this sounds like you get 60fps because of vsync. Currently there is no way to disable it with the open driver (except you modify a source-file).
But 3d-acceleration with the open driver is still slower.

1311219 wrote:

Don't get me wrong, I like the open drivers - they work good, and 60fps when rendering ~33000 triangles in that demo is still good. But I'm currently working on a program that will use vbo optimization (because it needs to render an awful lot of stuff quickly), and would really need this functionality...
This might even be related to my hardware: ATI Technologies Inc RV730 Pro AGP [Radeon HD 4600 Series] - which is on AGP bus (not pci express).

If anyone got the time, please try the NeHe demo (only requires SDL to compile), and see if you have better luck.
thanks!

btw: I do get a note about "IRQ's not enabled, falling back to busy waits: 2 0" when initializing opengl.... I thought the latest drivers supported IRQ? or am I still on the old (stable) drivers despite installing the packages from Perry's repo?

There were problems with AGP Cards. Maybe you can post the output of dmesg | grep -i drm .

insanemal · 2010-05-04 12:44:55

Perry3D wrote:

Maybe you should switch back to xorg 1.7. And you can try disabling dynpm in /sys/class/drm/card0. (echo 0 > /sys/class/drm/card0/dynpm)

Already switched back. I'm not using dynpm yet. I been rolling my own everything but not the Kernel so no PM.. im happy to wait.. I get 2 hrs with no PM.

megawebmaster · 2010-05-04 21:27:34

Huh, I love new things and dynamic PM is just what I needed from beggining - now waiting for voltage control and good fan slowing (I've got really big hope for it) - and my Arch will be in every way better than Windows It'll be beatiful day

1311219 · 2010-05-05 10:12:32

Perry3D, thanks for the reply.
Indeed, at first vsync seems to be what's causing it, but glxgears gives just over 800fps, so it seems more like a coincident.
Have you also tried that demo and gotten 60fps? Because then perhaps the demo itself is accidentally enabling vsync?

I've tried modifying the "terrain.bmp" heightmap in the demo to make it more processing intensive, and the fps now get around 48fps, exactly the same with VBO or not. So I'm fairly certain the "vbo" functionality of the drivers just wraps the old "vertex array" solution. The idea of VBO ("vector buffer object") is to instead send the 3d model directly to the memory of the graphics card, often resulting in a much higher fps (that demo on windows: 200fps -> 2500fps). Since I'm currently trying to use vbo in a program of my own (which requires realtime rendering of many, many, thousands of triangles), I'm quite focused on this specific feature in the drivers.

It might be so that vbo was initially implemented as a software solution (just a wrapper around "vertex array"), and then no one remembered/bothered to change it?

Anyway:

#dmesg|grep -i drm
[drm] Initialized drm 1.1.0 20060810
[drm] Initialized radeon 1.33.0 20080528 for 0000:01:00.0 on minor 0
[drm] Setting GART location based on new memory map
[drm] Loading RV730 CP Microcode
[drm] Resetting GPU
[drm] writeback test succeeded in 1 usecs

So at least it seems to work(?), and I'm quite happy as long as I get 3d acceleration at all...

regnak90 · 2010-05-05 10:29:13

1311219, i tried the demo and i get 180 FPS with or without VBO enabled.
My GPU is a Mobility Radeon HD 3650 and I'm using the testing repo so i have Xorg 1.8 and Mesa 7.8.1.
Seems like VBO will be software for a while.

EDIT : Oups I was wrong, with VBO lesson45 eats 3% of CPU and without it, 40%.
So it is working somehow.

Last edited by regnak90 (2010-05-05 10:45:42)

1311219 · 2010-05-05 10:53:40

That is interesting, my cpu usage is maxed on both.

Perhaps vbo is implemented then?... So either my specific hardware is the problem. I'll try the unstable versions...

Perry3D · 2010-05-05 11:04:13

If you want some informations at first hand (developers), visit the irc-channel: #radeon on irc.freenode.net .

1311219 · 2010-05-05 11:24:22

Thanks, sounds like a good idea.

(I just tried the xorg+ati packages from testing, no change)

some other stuff I've noticed (that might indicate my hardware being the cause of problem): I've never gotten kms automatically enabled (testing or not), graphics output freezes when switching from vt to x (testing or not), probably more stuff I can't remember...

update: someone suggested vbo functionality was implemented in dri2, so decided to get kms working (since radeon seems to require that to get dri2):
Success! - somewhat...
I don't get more fps (more like fewer ), but cpu usage goes down from 100% to around 2-5%. But I don't think this is the whole truth, since the whole system gets sluggish (probably much more usage, just not "detected").
I do however think it's vsynced! so I'm a bit impressed anyway.

Last edited by 1311219 (2010-05-05 20:51:37)

megawebmaster · 2010-05-07 19:42:41

Is xf86-video-ati-git from radeon repository already compiled for Xorg 1.8? Last time I wanted to use it Xorg won't even start, because of ABI incorrectness - compiled for Xorg 1.7.

Perry3D · 2010-05-08 10:58:25

@megawebmaster: No, i compile it against 1.7 because i don't want to use the testing repo. But today there was an article at phoronix: DRI2 Sync & Swap For ATI Finally Comes About. This feature requires xorg 1.8. It would be interesting to know when it will move to extra.

venky80 · 2010-05-08 11:32:55

yes please dont include 1.8 till it makes to extra

Last edited by venky80 (2010-05-08 11:33:06)

megawebmaster · 2010-05-08 12:00:27

OK, so I've got another question - are in this driver any improvements? I mean compared to xf86-video-ati from testing.

Perry3D · 2010-05-08 12:00:48

Updated the kernel26-drm-radeon-testing package: http://git.kernel.org/?p=linux/kernel/g … d1112055ba

drm/radeon/kms/pm: rework power management
- Separate dynpm and profile based power management methods. You can select the pm method
by echoing the selected method ("dynpm" or "profile") to power_method in sysfs.
- Expose basic 4 profile in profile method
"default" - default clocks
"auto" - select between low and high based on ac/dc state
"low" - DC, low power mode
"high" - AC, performance mode
The current base profile is "default", but it should switched to "auto" once we've tested
on more systems. Switching the state is a matter of echoing the requested profile to
power_profile in sysfs. The lowest power states are selected automatically when dpms turns
the monitors off in all states but default.
- Remove dynamic fence-based reclocking for the moment. We can revisit this later once we
have basic pm in.
- Move pm init/fini to modesetting path. pm is tightly coupled with display state. Make sure
display side is initialized before pm.
- Add pm suspend/resume functions to make sure pm state is properly reinitialized on resume.
- Remove dynpm module option. It's now selectable via sysfs.

The dynpm option has been removed. Don't forget to remove it from your kernel parameters. Otherwise there will be KMS errors.

/edit: ATI Gets Dynamic Power Management & Profiles Too

Last edited by Perry3D (2010-05-08 12:40:56)

handy · 2010-05-08 14:29:30

Before upgrading I removed dynpm=1 from kernel start parameters. On reboot I had no kms, & my glxgears was little more than half of what it was beforehand.

Any version of the xf86-video-ati-git package after 24 April, has slowed things down like this.

Anyway I'll downgrade kernel & radeon at this stage.

venky80 · 2010-05-08 18:23:51

Perry3D wrote:

Updated the kernel26-drm-radeon-testing package: http://git.kernel.org/?p=linux/kernel/g … d1112055ba
drm/radeon/kms/pm: rework power management
- Separate dynpm and profile based power management methods. You can select the pm method
by echoing the selected method ("dynpm" or "profile") to power_method in sysfs.
- Expose basic 4 profile in profile method
"default" - default clocks
"auto" - select between low and high based on ac/dc state
"low" - DC, low power mode
"high" - AC, performance mode
The current base profile is "default", but it should switched to "auto" once we've tested
on more systems. Switching the state is a matter of echoing the requested profile to
power_profile in sysfs. The lowest power states are selected automatically when dpms turns
the monitors off in all states but default.
- Remove dynamic fence-based reclocking for the moment. We can revisit this later once we
have basic pm in.
- Move pm init/fini to modesetting path. pm is tightly coupled with display state. Make sure
display side is initialized before pm.
- Add pm suspend/resume functions to make sure pm state is properly reinitialized on resume.
- Remove dynpm module option. It's now selectable via sysfs.
The dynpm option has been removed. Don't forget to remove it from your kernel parameters. Otherwise there will be KMS errors.
/edit: ATI Gets Dynamic Power Management & Profiles Too

can you expand as to how to "echo the requested profile to
power_profile in sysfs"?
thanks perry

handy · 2010-05-08 23:34:08

I've gone back to the [core] packages, as I have been having some latency re. refresh in Firefox since I've been using the kernel26-drm-radion-testing, & as mentioned more than once here the xf86-video-ati driver package is no good to me since 20100424.

I tested the [core] packages with glxgears & early start KMS & I have the same performance as the best I've got out of the dev' packages with KMS which is good.

So it does look like the prime work on kernel .34 has been PM. Which is great for all those using Notebooks I'm sure. The iMac doesn't have a fan that is controlled by the GPU, it has multiple fans that cool the entire system including CPU, GPU & PSU via air distribution ducting (best way to say it I could think of). I'm hoping that as PM develops further it will allow my machine to use less power than it does in normal operation, but time will tell, & I'm not particularly hopeful due to the machine that it is.

I tested its power usage over a 51hr time period, where it was torrenting whilst I slept & the price @ 19c/kw ran out to $124.64 / year.

Hopefully kernel .35 will bring the bag of new PM tricks for us.

Last edited by handy (2010-05-09 11:08:48)

bwat47 · 2010-05-09 03:14:03

so Im a bit confused, with the new kernel updates it looks like some of this info is outdated, With the newest kernel26-drm-radeon-testing package kernel how do you properly enable power management?

And are the repos in the op compatible with xorg 1.8?

Last edited by bwat47 (2010-05-09 03:14:27)

handy · 2010-05-09 03:23:39

I ran xorg-server 1.8, up until quite recently, & there was no problems with the [radeon] repo.

Perry3D · 2010-05-09 09:58:07

@bwat47: It's not compatible with xorg 1.8. And PM should be enabled by default. With the latest kernel update there were some changes: http://www.phoronix.com/scan.php?page=n … &px=ODIyOA

@handy: Did you try to switch PM to performance? echo high > /sys/class/drm/card0/device/power_profile

handy · 2010-05-09 11:13:07

Perry3D wrote:

@handy: Did you try to switch PM to performance? echo high > /sys/class/drm/card0/device/power_profile

My system is unresponsive to the PM developments thus far.

I'll hold off from these dev' packages until the packages for kernel .35 start being released & then I'll see how they are going.

I'll continue to watch this thread closely though.

Arch Linux

#1251 2010-05-03 14:21:52

Re: Discussion: the ati/radeon open source drivers & radeon repository

#1252 2010-05-03 17:08:13

Re: Discussion: the ati/radeon open source drivers & radeon repository

#1253 2010-05-03 21:02:38

Re: Discussion: the ati/radeon open source drivers & radeon repository

#1254 2010-05-03 21:42:34

Re: Discussion: the ati/radeon open source drivers & radeon repository

#1255 2010-05-04 09:22:34

Re: Discussion: the ati/radeon open source drivers & radeon repository

#1256 2010-05-04 09:30:15

Re: Discussion: the ati/radeon open source drivers & radeon repository

#1257 2010-05-04 12:44:55

Re: Discussion: the ati/radeon open source drivers & radeon repository

#1258 2010-05-04 21:27:34

Re: Discussion: the ati/radeon open source drivers & radeon repository

#1259 2010-05-05 10:12:32

Re: Discussion: the ati/radeon open source drivers & radeon repository

#1260 2010-05-05 10:29:13

Re: Discussion: the ati/radeon open source drivers & radeon repository

#1261 2010-05-05 10:53:40

Re: Discussion: the ati/radeon open source drivers & radeon repository

#1262 2010-05-05 11:04:13

Re: Discussion: the ati/radeon open source drivers & radeon repository

#1263 2010-05-05 11:24:22

Re: Discussion: the ati/radeon open source drivers & radeon repository

#1264 2010-05-07 19:42:41

Re: Discussion: the ati/radeon open source drivers & radeon repository

#1265 2010-05-08 10:58:25

Re: Discussion: the ati/radeon open source drivers & radeon repository

#1266 2010-05-08 11:32:55

Re: Discussion: the ati/radeon open source drivers & radeon repository

#1267 2010-05-08 12:00:27

Re: Discussion: the ati/radeon open source drivers & radeon repository

#1268 2010-05-08 12:00:48

Re: Discussion: the ati/radeon open source drivers & radeon repository

#1269 2010-05-08 14:29:30

Re: Discussion: the ati/radeon open source drivers & radeon repository

#1270 2010-05-08 18:23:51

Re: Discussion: the ati/radeon open source drivers & radeon repository

#1271 2010-05-08 23:34:08

Re: Discussion: the ati/radeon open source drivers & radeon repository

#1272 2010-05-09 03:14:03

Re: Discussion: the ati/radeon open source drivers & radeon repository

#1273 2010-05-09 03:23:39

Re: Discussion: the ati/radeon open source drivers & radeon repository

#1274 2010-05-09 09:58:07

Re: Discussion: the ati/radeon open source drivers & radeon repository

#1275 2010-05-09 11:13:07

Re: Discussion: the ati/radeon open source drivers & radeon repository

Board footer