AMD A8-3850 With Radeon HD 6550D

[edgar_wibeau]

So I did a downgrade to oneiric's current xorg-packages: they work, I don't recognize a difference in quality. But they are slower; benchmark results for warsow, 1920x1280 are:

xorg oneiric: 18 fps
xorg edgers: 23 fps

Most worrysome to me currently is that googleearth (6.0.3.2197 and 5.1.3533) is too slow to work with. Version 6 offers to switch to DirectX mode (guess it's a winelib application) which results in a crash. The OpenGL mode is very slow, way below 10 fps for both versions of GE. I do remember that 5.1 worked with my old installation, Kubuntu 10.04 stock with radeon driver, Phenom 4x2GHz, Radeon HD 3300 IGP. It also was too slow (I think it was even a little faster than my current setup), but that was a 40 SP IGP vs the 400 SP one offered by Llano, plus doubled ram bandwidth.

[edgar_wibeau]

Gotta make a correction: I haven't removed the edgers stuff (seems that was another test installation), so I have the git stuff installed. What I tested were edgers/natty packages, I updated them to edgers/oneiric an hour ago, still everything's ok. I disabled edgers now, so I'll hopefully pull stable packages before release. Or maybe I'll re-enable xorg-edgers? Dunno, tough decisions to make all day

But I did a test with Ubuntu Oneiric standard packages some days ago with my old TFT (1280x1024) with similar results.

chithanh: Filing a bug is what I was thinking about as well. I already did some searches, but didn't seem to find something related to Llano and the radeon driver. D'oh!

[chithanh]

Nice to hear that it works now!
If you have the time, please report a bug on https://bugs.freedesktop.org/ so it can be fixed properly.

[edgar_wibeau]

chithanh - works fine, thanks!

$ ls /sys/class/drm/card0/
card0-DVI-D-1  card0-VGA-1  dev  device  power  subsystem  uevent

Kernel parameters: "video=DVI-D-1:e video=VGA-1:d"

dmesg | grep drm:

[...]
[    1.650398] [drm] Connector 0:
[    1.650399] [drm]   VGA
[    1.650400] [drm]   HPD2
[    1.650402] [drm]   DDC: 0x6440 0x6440 0x6444 0x6444 0x6448 0x6448 0x644c 0x644c
[    1.650403] [drm]   Encoders:
[    1.650404] [drm]     CRT1: INTERNAL_UNIPHY2
[    1.650405] [drm]     CRT1: NUTMEG
[    1.650406] [drm] Connector 1:
[    1.650407] [drm]   DVI-D
[    1.650408] [drm]   HPD1
[    1.650409] [drm]   DDC: 0x6430 0x6430 0x6434 0x6434 0x6438 0x6438 0x643c 0x643c
[    1.650410] [drm]   Encoders:
[    1.650411] [drm]     DFP1: INTERNAL_UNIPHY2
[    2.532824] [drm] Internal thermal controller without fan control
[    2.532850] [drm] radeon: power management initialized
[    2.548875] [drm] forcing VGA-1 connector OFF
[    2.548877] [drm] forcing DVI-D-1 connector ON
[...]

Now the monitor switches off for some seconds after loading the kernel, but comes back with the boot splash animation at full monitor res and - more importantly - shows the KDM greeter! So I removed the xrandr stuff from ~/.kde/share/config/krandrrc.

Very happy

[chithanh]

I think I tried "video=DVD-0:e video=VGA-0:d". Maybe it's the syntax with two times "video=", didn't try.

I think you got the output names wrong. You need to use the names from /sys/class/drm/card0, not the names shown by xrandr.

[edgar_wibeau]

A8-3850 / Radeon HD 6550D works with free radeon driver!

Hi,

I also tried 11.04 (natty) with xorg-edgers which serves the latest git xorg stuff, an I had the same results as Michael shows on page 2 in his review. I run an HP LP2465 via DVI, my board is an Asus F1A75-M Pro. FGLRX 11.7 didn't work well for me as it repeatedly crashes when I watch VDR (DVB-S) via kaffeine/xinelib and switch channels or choose another video source inside VDR (like AVIs from hard disk). After re-login kded4 utilizes one CPU core at 100%, systray gets slooooooooooow. I had the same phenomenon (X crashes when switching channels with VDR/kaffeine) with FGLRX years ago when radeon wasn't stable with my older HD 3300 IGP. Still unsolved it seems.

So I threw out FGLRX and edgers, went back to the original xorg and radeon packages and upgraded to 11.10 (oneiric) alpha 2, current state.

And - surprise surprise - Radeon works!

One major drawback though: the driver and KMS "see" a VGA monitor (on "VGA-0") which isn't there and it's configured to 1024x768. That one is the primary monitor, thus the real monitor on DVI ("DVI-0") is set to mirror the VGA and also runs at XGA res. There is at least one work-around though: in KDE System Settings -> Display and Monitor, which calls xrandr at login time. A little tricky though as X hangs when fooling around too much with the settings. The way it worked: I first set 1920x1200 using krandrtray (a systray tool), started systems settings/display and disabled the ghost VGA monitor, set the whole thing as standard. Kwin now calls xrandr at login time to apply these settings. The result in ~/.kde/share/config/krandrrc is:

[Display]
ApplyOnStartup=true
StartupCommands=xrandr --output VGA-0 --pos 0x0 --mode 1024x768 --refresh 60.0038\nxrandr --output DVI-0 --pos 0x0 --mode 1920x1200 --refresh 59.9502\nxrandr --noprimary

Problem: while booting, when KMS kicks in, my screen switches off. And comes back after KDE-login so I have to use auto-login. Which I do on my home machine anyways. It can be set to lock the screen after login for the scared amongst us

I'm sure this can be done in xorg.conf too, but I want to stay with the standard graphical tools until radeon/kms are fixed. Also kernel parameters might do the trick, I saw older documentation and the switches didn't work for me. I think I tried "video=DVD-0:e video=VGA-0:d". Maybe it's the syntax with two times "video=", didn't try.

So, everything works for me now, idle power was 5 watts higher when I last measured so I guess the GPU power management lacks behind FGLRX's, but 3D works, 3D desktop works (after first reboot with new settings), but is slower than FGLRX of course. But rock stable. Btw, V-drift is faster than FGLRX only because many effects (like reflections) are inactive when running it with radeon.

So, that setup works fine for me now. And if Oneiric breaks temporarily (only, hopefully) on it's way to release, I have a backup and also a running Natty copy with FGLRX, my data sits on a RAID and my mails on IMAP

Oh and DarkFoss: Llano has two memory channels of 64 bits, populating four DIMM slots only hurts power draw (at least), latency, max freq.

[DarkFoss]

Don't forget if you populate all 4 dimm slots you can enable simultaneous reads and writes but only up to 1600MHz, 1866 or higher and you'll lose that function.

[edgar_wibeau]

Guess I missed the virtual "ironic" tags in Qaridarium's post, well how funny. I agree with Kivada, it's just some extra bucks vs. DDR3-1333 (+?20 for 8GB, my 1866s are at 1.5V btw.) and you get extra value for it. It's NOT overclocking by any means.

[Luke_Wolf]

Lets also not forget that AMD has stated there will be mobos for these chips using Coreboot instead of BIOS or UEFI as default. Makes it an easy pick for the would be RMS around here that want something that is as OSS as possible.

I personally will be so glad to have that. And such boards I will definitely favor, Here's hoping for Gigabyte to be The One or one of many anyway...

[Kivada]

there are tests out there proofed the 2500mhz ddr3 speed up.

sure you need to overclock it to 5ghz to get the effect.

So you know nothing of overclocking or hardware in general I see... These chips are designed to use DDR# 1866Mhz as stock memory, you can easily find DDR3 rated t run at 2.4Ghz as it's stock speed at the DDR3 voltage spec of 1.65v, the only thing you need is a mobo with the options in BIOS to change the clock rate and timings past the memory controller's default.

Considering you can do this completely independently of the CPU, GPU, FSB and HT Link speeds and the fact that the ram is within $10-20 USD of DDR3 1600Mhz if you shop around theres no real reason not to max the ram to get as much punch ot of the GPU as possible.

These chips can also be crossfired with the HD6670 or paired with any PCIe GPU you like and used as a dedicated OpenCL coprocessor whenever that becomes a major part of OSS software.

Lets also not forget that AMD has stated there will be mobos for these chips using Coreboot instead of BIOS or UEFI as default. Makes it an easy pick for the would be RMS around here that want something that is as OSS as possible.