Radeon HD6770 constantly runs hot (loaded even at idle?)

[Tyler_K]

@auxym

Posting this from OpenSUSE with working KDE and a quiet video card … and it’s all good now

nice to read.

In my spree to remove everything to do with radeon to get fglrx working, I think I had removed libdrm-radeon … (and I’ve learned a bit in the process)
well, just to further your knowledge for the future, there is/are no package(s) that is/are required to be removed from the system in order to use the catlyst/fglrx drivers … if its any consolation, I’ve observed such end user ripping spree behaviour many times in forum and mailing list posts, so you’re not alone when it comes to doing some monkey work rotfl!

I think I had removed libdrm-radeon … oops >:(. Removing that …also removed …xorg-x11-server
well, that solves that mystery: No X server, no X.

I think I had removed libdrm-radeon … (not even sure what it is)
the userspace X driver (radeon_drv.so) talks to the kernel driver (the DRM; radeon.ko) via libdrm (libdrm.so) … i.e. libdrm is the userspace interface to the kernel driver … it (libdrm) contains the DRM API functions/routines that allow it to provide the ability for X clients to interface directly with the graphics adapter, by way of the DRM … libdrm_radeon.so contains the DRM functions/routines specific to Radeon hardware

[Tyler_K]

@wolfi323

libdrm_radeon … I don’t think fglrx uses this

correct, just the OSS stack … fglrx has its own interface (which, off the top of my head, I believe is fglrxdrm.so, IIRC)

but Mesa depends on it on the rpm package level
yep, and on a functional level, I believe the gallium pipe driver (r600_dri.so) can access libdrm too (alluded to via: “ldd /usr/lib*/dri/r?00_dri.so | grep radeon”), but doesn’t, as it has its own interface to the kernel driver via the radeon winsys.

(and the radeon driver needs it for direct rendering on a radeon card).
yeppers, as described above (and alluded to via “ldd /usr/lib*/xorg/modules/drivers/radeon_drv.so | grep radeon”)

[Tyler_K]

@Tyler_K

on a functional level, I believe the gallium pipe driver (r600_dri.so) can access libdrm too (alluded to via: “ldd /usr/lib*/dri/r?00_dri.so | grep radeon”)

Oops, my mistake.

The ? contained in the suggested command above picks up r200 too, and it is that which produces the grep hit … If you do a simple “ldd /usr/lib*/dri/r*_dri.so” instead, with that pattern, you’d end up checking the dependencies for both the classic and some of the gallium driver files (available to the respective radeon class hardware), and looking over its output would indicate that it is just the classic mesa drivers (radeon and r200) which have the link to libdrm_radeom … whereas the gallium pipe drivers (r300, r000) are unencumbered.

[Tyler_K]

@Tyler_K

The good news, is that there has been some improvements in recent kernels (3.8, 3.10) in relation to PM … in particular, some nice improvements related to CPU dynamic scaling (both Intell and AMD related code drops). On the graphics front, in particular to that which affects you, it is well known that the AMD developers who work on the OSS stack have already written considerable PM improvements, but are unable to yet release the code until it passes technical/legal review. Unfortunately, there is no specific timeline as to when such a code drop may happen, as well as there also being the possibility of it being upheld/veto’ed, though hopefully the later won’t come to pass. As that process has been going on for a while now, it is hopeful that it is a case of sooner, rather then later. Though, I can imagine that that news is small consolation to many who want it now!

Big code drop today. New PM features will be going into the 3.11 kernel … likely not enabled by default. … suspect that openSUSE 13.1 won’t get that then (it’ll likely get a 3.10.x kernel) …