AMD/ATi Radeon HD5450 PCI

[MG]

Recently I tried one of these in an HP Integrity rx2620 (multi-core dual-processor, IPF) system, figuring it'd be a very interesting upgrade combined with the multi-core processors, prepared with the latest Gentoo IA-64 ‘minimal’ 2011 freshly installed on a spare U320 disk.

This is a somewhat rare and unusual card, it's the (3.3 V) PCI relative of the more common PCIe (as in PCI-Express, for clarity's sake) model. Though, somehow, it's regularly recognized as (or mistaken for) a ‘PCIe’ card in many environments (including by CPU-Z under Windows XP IA-64). I haven't tried it under HP-UX yet, but I can roughly predict that it won't work or give me much (aside from basic framebuffer support). Interestingly, it works out-of-the-box in the EFI environment and will successfully provide a ‘glass terminal’ for VMS.

Anyway, my questions would be: Has anyone else, by any chance, tried this card? Better yet, this specific PCI model in particular and willing to share experiences? I'm more than willing to help out, both in terms of developing and testing. (Or should I rather be approaching the X.org people directly?)

[eccerr0r]

There are plenty of idiosyncrasies with running x86 cards on a ia64 machine, enough so that the software dev may need the actual hardware to debug the issue. But quite possibly it just is because the devs didn't expect people to use a PCI version of the card and didn't configure the software that way.

Does the card work in an x86 box, first? Is the card dual voltage or 3.3V PCI only (since a lot of PC motherboards are 5V)?

rx2620s have PCIX slots, 64 bit and at least 66MHz. It may have the riser with an AGP slot, but the same ia64/x86 testing may be needed...

(I have never tried a graphics accelerator card in my SR870BH2 ia64 box, I just have never gotten my hands on a PCI graphics accelerator card...)

[MG]

There are plenty of idiosyncrasies with running x86 cards on a ia64 machine, enough so that the software dev may need the actual hardware to debug the issue. But quite possibly it just is because the devs didn't expect people to use a PCI version of the card and didn't configure the software that way.

I also tried this card under non-Linux platforms, like OpenVMS I64 V8.4 and Windows XP 64-Bit V2003 with SP2 (needless to say the ‘[for] Itanium systems’ version). With VMS, remarkably enough, I get a fully functional ‘glass terminal’ (as I said before; however, no DECwindows though, but that was to be expected) and with Windows I have a very snappy and fully functional framebuffer, which I didn't expect (as the Radeon 7500 and other cards [except for the FireGL X1] don't perform extremely well, even with drivers available).

A non-Gentoo Linux I also tried recently, namely Debian ‘Squeeze.’ It was my intent to try various Linux distributions, with Gentoo and Debian being my favourites (Debian also because it can sometimes be a bit quicker to install and because of extensive prior experience with it).

Here are some results I got whilst using the latest Debian IA-64 (‘Squeeze’ 6.0.2), in case it may perhaps (in part) prove useful for Gentoo as well:

Code: Select all

# cat /etc/debian_version
6.0.2

# uname -srmpv
Linux 2.6.32-5-mckinley #1 SMP Tue Jun 14 12:05:22 UTC 2011 ia64 unknown

# free -g
             total       used       free     shared    buffers     cached
Mem:            23          0         23          0          0          0
-/+ buffers/cache:          0         23
Swap:            7          0          7

# lscpu
Architecture:          ia64
CPU(s):                8
Thread(s) per core:    1
Core(s) per socket:    1
CPU socket(s):         8
NUMA node(s):          1
Vendor ID:             GenuineIntel
CPU family:            32
Model:                 0
CPU MHz:               1400.003
L1d cache:             16K
L1i cache:             16K
L2d cache:             256K
L2i cache:             1024K
L3 cache:              6144K

# lspci | grep -i Radeon
81:00.0 VGA compatible controller: ATI Technologies Inc Manhattan [Mobility Radeon HD 5430 Series]
81:00.1 Audio device: ATI Technologies Inc Manhattan HDMI Audio [Mobility Radeon HD 5000 Series]
e0:02.0 VGA compatible controller: ATI Technologies Inc Radeon RV100 QY [Radeon 7000/VE]

# dmesg | grep -i DRM
[    9.954248] [drm] Initialized drm 1.1.0 20060810
[   10.720171] [drm] radeon defaulting to userspace modesetting.
[   10.722446] [drm] Initialized radeon 1.32.0 20080528 for 0000:e0:02.0 on minor 0
[   10.724609] [drm] Initialized radeon 1.32.0 20080528 for 0000:81:00.0 on minor 1

I'm getting the following errors, when GDM is started and running:

Code: Select all

# dmesg | tail
[  581.224646] Xorg(11143): unaligned access to 0x2000000000d6d9a9, ip=0x2000000000019321
[  581.224680] Xorg(11143): unaligned access to 0x2000000000d6d9f1, ip=0x2000000000019321
[  581.224711] Xorg(11143): unaligned access to 0x2000000000d6d9b2, ip=0x2000000000019321
[  581.224742] Xorg(11143): unaligned access to 0x2000000000d6d9bb, ip=0x2000000000019321
[  581.224773] Xorg(11143): unaligned access to 0x2000000000d6d9c4, ip=0x2000000000019321

(At a first glance, it appears to be a driver issue. I'm using the "radeonhd" X.org driver here.)

Does the card work in an x86 box, first?

Good question, I haven't tried it yet. I tried it in an IBM x346, though that's hardly an average (i.e. ‘PC’) type of x86/-64 system (I ran into trouble there, because of the boot ROM and BIOS tripping over it, also due to conflicts with the integrated graphics adapter on IBM's RSA II).

Is the card dual voltage or 3.3V PCI only (since a lot of PC motherboards are 5V)?

Either dual voltage or 3.3 V, as it works fine (the PCI type, or form factor, is physically speaking also that of a 3.3 V.)

rx2620s have PCIX slots, 64 bit and at least 66MHz. It may have the riser with an AGP slot, but the same ia64/x86 testing may be needed...

I do have that PCI/-X & AGP combined riser/backplane board (originally intended for the zx6000) and, remarkably, it works with my rx2620! I got better results with the FireGL X1 than with this HD5450 so far.

(I have never tried a graphics accelerator card in my SR870BH2 ia64 box, I just have never gotten my hands on a PCI graphics accelerator card...)

Maybe this is a good opportunity? They're not very expensive, even new.

[eccerr0r]

First off the "unaligned access" is not an error unless you told the OS to flag it as such. Ia64 was not meant to do unaligned accesses for speed, but to be compatible with ia32 it needed to support them, so the OS handles unaligned accesses and when the OS does, it prints the warning out so people can remove them from the code. What does it do?

If Debian works, it should also work with Gentoo unless the code suffered bit rot... This needs to go to xorg.

Unfortunately for me, any graphics investment to my ia64 box is pretty dumb unless I get the hardware for free. There aren't any apps that I run on the ia64 that would benefit from the graphics accelerator... I have a pci matrox card that I could try but it's not an accelerator and probably the onboard ati is faster anyway...

I was also trying to get the mach64 driver to work on the internal rage pro. That didn't work very well either, with lots of errors that I don't see when running on my x86 pc's with a similar ati rage pro card...

[MG]

First off the "unaligned access" is not an error unless you told the OS to flag it as such.

I didn't tell the OS anything, nor instructed it to flag anything. All I did, so far, is simply install Debian ‘Squeeze’ IA-64 (6.0.2) along with the "xserver-xorg-video-radeonhd" (by the way, I naturally also tried "-ati" and "-radeon") package and see if I can get anything out of the card (i.e. GNOME), besides a text console. Same results under Gentoo IA-64. But, I'll soon give Gentoo another shot. I like Gentoo a lot better for customizations, including the whole kernel configuration and building procedure.

Ia64 was not meant to do unaligned accesses for speed, but to be compatible with ia32 it needed to support them, so the OS handles unaligned accesses and when the OS does, it prints the warning out so people can remove them from the code.

Sorry, but what is ‘it’ and why should ‘it’ be compatible with IA-32? (Or are you saying that it's more than just a performance improvement?)

What does it do?

From where I'm standing, not a terrible lot. Ironically, I get more out of this card under a neglected oddball of an operating system like Windows XP V2003 SP2 IA-64 (with no drivers available for the HD5450, or any other HD-series graphics adapter whatsoever) than under Linux (the supposed friend of cross-platform users).

If Debian works, it should also work with Gentoo unless the code suffered bit rot... This needs to go to xorg.

Well, that's the thing: It does not work. (About X.org, how would you suggest me to contact them about this? Is there an IA-64 specific mailing list? I haven't dealt with them yet.)

Unfortunately for me, any graphics investment to my ia64 box is pretty dumb unless I get the hardware for free.

Why would it be ‘pretty dumb’ to pay a modest sum for a modern graphics adapter?

There aren't any apps that I run on the ia64 that would benefit from the graphics accelerator...

Okay, then not, I guess. But, wouldn't it be useful for the cause of Linux and running it on something besides x86/-64, to provide proper and true multi-platform graphics drivers?

I have a pci matrox card that I could try but it's not an accelerator and probably the onboard ati is faster anyway...

(I'm a bit confused now. Didn't you just say that, for the software that you typically use, you don't really need graphics acceleration...?)

I was also trying to get the mach64 driver to work on the internal rage pro. That didn't work very well either, with lots of errors that I don't see when running on my x86 pc's with a similar ati rage pro card...

So, is it then safe to say that X.org doesn't particularly concern itself with anything except x86/-64...?

[eccerr0r]

I believe that sys-apps/prctl can be used to change the behavior of each application to hide warnings due to unaligned accesses or floating point denorm handling. Both of which were chosen by ia64 development as a worst case, won't happen often scenario if the software was written correctly case, and thus they optimized the CPU to not handle them (and instead have the OS handle these software issues.)

However it needs to at least detect them and handle them gracefully (instead of cause a bus fault/floating point, which it could do and kill the program... which is not a clean thing to do.) Keep in mind that ia64 initially started out as able to run ia32 apps as a feature, all ia64 machines previous to the dual core 9000 series can run them without software emulation - emulation done in hardware (slowly, without dynamic translation.) Your(and my) machine should be(is) able to cleanly chroot into an ia32 directory and run native ia32 linux apps as is!

One of the problems is that ia32 apps can and does do ugly stuff like unaligned accesses and SMC, so the processor needs to handle these.

I definitely have no use for 3D applications on my ia64, my x86 boxes can do them just fine. I just mentioned that the Matrox is the only PCI video card I own (and it has no 3d hardware, it's a pure 2D card), and could try to see if the ia64 will initialize and use the card correctly... Past that, no real need to try it!

Pretty much, it's true, they just don't have all the hardware combos to try. There shouldn't be a reason why the mach64 can't do rudimentary triangle handling.... then again I have yet to see it working on a x86 box yet either... it *should* work...

[MG]

However it needs to at least detect them and handle them gracefully (instead of cause a bus fault/floating point, which it could do and kill the program... which is not a clean thing to do.) Keep in mind that ia64 initially started out as able to run ia32 apps as a feature, all ia64 machines previous to the dual core 9000 series can run them without software emulation - emulation done in hardware (slowly, without dynamic translation.) Your(and my) machine should be(is) able to cleanly chroot into an ia32 directory and run native ia32 linux apps as is!

Don't too easily assume things: My rx2620s actually have Itanium 9000-series (“Montecito”; DC, MT) processors. So, my hunch was correct (that the lack of IA-32/x86 emulation would mean bad news down the road). I guess I could try my AGP cards (including the FireGL X1) in one of my rx2620s and the HD5450 [PCI] in one of my rx2600 (“Madison”) systems then, for the time being and in the short term.

[eccerr0r]

Ah... stupid debian pretexted "McKinley" and lscpu reported eight 1.4GHz cores without multithreading that matches up with a ... Madison :p (and rx2620's don't have 8 sockets...) You're right, the 9000-series CPUs do not have on-chip hardware ia32 execution code and may make it hard to boot video cards that require firmware to be executed. McKinleys do have ia32 emulation hardware.

I really don't think that 9000-series and graphics accelerator options have been tested, though there are 9000-series systems with pcie, no clue how those work... And of course the QPI IA64's have pcie...

[MG]

Ah... stupid debian pretexted "McKinley" and lscpu reported eight 1.4GHz cores without multithreading that matches up with a ... Madison :p (and rx2620's don't have 8 sockets...) You're right, the 9000-series CPUs do not have on-chip hardware ia32 execution code and may make it hard to boot video cards that require firmware to be executed.

Actually, Gentoo gave me the exact same "lscpu" results (it also thought it was an 8-socket system). Or, are you saying that a customized/tailored kernel could do miracles?

McKinleys do have ia32 emulation hardware.

Madisons as well. So, like I said, I'll give one of my rx2600s a try then. Not ideal, but better than nothing at the moment.

I really don't think that 9000-series and graphics accelerator options have been tested

Not for Linux, obviously. (The thing is: A Radeon 7500 under OpenVMS, FireGL X1 under Windows XP IA-64 and so on, with the drivers installed, will still work just fine. Yes, I actually tested this and before I started messing around with Linux...)

For everything there's a first time, I guess? I can provide remote access accounts for developers, if they'd perhaps like to help out (or help looking into things).

Though there are 9000-series systems with pcie, no clue how those work... And of course the QPI IA64's have pcie...

Yes, that should be interesting. But, only from a performance and availability perspective. The same problems as with my HD5450 (normally also a PCIe card) would arise, with regard to the IA-32/x86 ROMs...

[eccerr0r]

When I was working on a quad 9150 machine (SR870BN4, not mine... my ia64 machine is a Dell Poweredge 3250), IIRC the later 2.6 kernels did report the correct number of cores/threads, which is kind of weird. On 2.6.9, I believe RHEL4.something, it did report funny; but the latest kernels seem correct...

Nevertheless good luck. It's definitely not something that was intended ever since people stopped putting ia64 into the desktop... I'm sure someone would have donated an ia64 box to do dev work on; after all, Gentoo got an ia64 box from HP to dev on, even...

[mattst88]

I thought something felt familiar about your posts, but I didn't make the connection until a few minutes after I saw your username.

/me waves to eMGee

So, as you've gathered, most people with Itanium systems don't use nice Radeons in them. It's a cool project though, so I'm very interested to find out how it goes. The reason the card appears as a PCI-e to lspci is that it technically is -- it uses a PCI-e to PCI bridge chip. It's pretty transparent though and shouldn't complicate configuration.

I would suggest that you first try Kernel Modesetting. If that works, install X and Mesa.

Keep us posted.

[MG]

Nevertheless good luck. It's definitely not something that was intended ever since people stopped putting ia64 into the desktop... I'm sure someone would have donated an ia64 box to do dev work on; after all, Gentoo got an ia64 box from HP to dev on, even...

Today I had time to try it with the FireGL X1 (AGP) card in my rx2620, with Debian IA-64 still, this is what I see:

Code: Select all

# dmesg | grep -i AGP
[    0.895403] IOC: reserving 512Mb of IOVA space at 0x60000000 for agpgart
[    1.900236] Linux agpgart interface v0.103
[    1.973839] agpgart: HP ZX1 IOC: IOPDIR shared with sba_iommu
[    1.974124]  <NULL>: AGP aperture is 512M @ 0x60000000
[    1.974159] agpgart: Detected HP ZX1 HWP0003 AGP chipset (ioc=fed01000, lba=fed28000)

Code: Select all

# dmesg | grep -i DRM
[    9.615633] [drm] Initialized drm 1.1.0 20060810
[   10.423821] [drm] radeon defaulting to userspace modesetting.
[   10.425178] [drm] Initialized radeon 1.32.0 20080528 for 0000:80:00.0 on minor 0
[   10.426725] [drm] Initialized radeon 1.32.0 20080528 for 0000:e0:02.0 on minor 1

No "unaligned access" this time, except for the "Network Manager." However, nothing seems to come up on the screen (except a blinking cursor). I've tried to reset things like GDM, delete the temporary files (in "/tmp"). Still nothing though.

When I have time (hopefully in the near future), I'll try some more things with Gentoo again.

[eccerr0r]

That's odd. I guess I don't quite know how ia64 machines deal with memory mapped devices that were meant for ia32, but the aperature at 0x60000000 looks like it's at 1.5GB. If the machine has 4GB, that would lie in the same address space?! Wonder where the physical memory is mapped...
Interesting, will have to look at what my machine does. It has 4G which should completely cover the address space of 32-bit PCI, where would the machine put the video buffer, unless it has a separate address space for legacy cards? Weeiirrd....

[roarinelk]

That's odd. I guess I don't quite know how ia64 machines deal with memory mapped devices that were meant for ia32, but the aperature at 0x60000000 looks like it's at 1.5GB. If the machine has 4GB, that would lie in the same address space?! Wonder where the physical memory is mapped...
Interesting, will have to look at what my machine does. It has 4G which should completely cover the address space of 32-bit PCI, where would the machine put the video buffer, unless it has a separate address space for legacy cards? Weeiirrd....

depending on the chipset, the ram there is simply not accessible or can be remapped to higher addresses.
i don't know how the ZX1 works, but my guess is the designers foresaw a situation like this and added
a remapping function, especially since the address space on ia64 is huge and for a modern OS it doesn't
matter one bit where RAM is located.

[eccerr0r]

depending on the chipset, the ram there is simply not accessible or can be remapped to higher addresses.
i don't know how the ZX1 works, but my guess is the designers foresaw a situation like this and added
a remapping function, especially since the address space on ia64 is huge and for a modern OS it doesn't
matter one bit where RAM is located.

The RAM is all accessible of course, but the question is whether or not the I/O device, namely the video card, is. Because it has a 32 bit address, where in the 64-bit physical address space is it (well, not all cpus have h/w to support all 64 bits physical but you get the idea...)? And why is it only a 32-bit address, how will software know to map into that address space if it's only 32-bit?

If it displayed as 0x000060000000, note it 's the same number but has 16 more bits (48 bit phys address) then I'd be a little less worried it's not doing the right thing.

Again I'll have to look at the memory map and see how my ia64 (deals with)/(maps) PCI memory. The ATI Rage Pro onboard my machine should have 8MB RAM that it has to map somewhere... it most definitely does work as a frame buffer at least, so they handled it some way...

(The ATI Rage Pro seems slow on my ia64 box compared to my discrete AGP ATI Rage Pro... but that's just a guess based on how it *seems* to run.)

[roarinelk]

depending on the chipset, the ram there is simply not accessible or can be remapped to higher addresses.
i don't know how the ZX1 works, but my guess is the designers foresaw a situation like this and added
a remapping function, especially since the address space on ia64 is huge and for a modern OS it doesn't
matter one bit where RAM is located.

The RAM is all accessible of course, but the question is whether or not the I/O device, namely the video card, is. Because it has a 32 bit address, where in the 64-bit physical address space is it (well, not all cpus have h/w to support all 64 bits physical but you get the idea...)? And why is it only a 32-bit address, how will software know to map into that address space if it's only 32-bit?

If it displayed as 0x000060000000, note it 's the same number but has 16 more bits (48 bit phys address) then I'd be a little less worried it's not doing the right thing.

Again I'll have to look at the memory map and see how my ia64 (deals with)/(maps) PCI memory. The ATI Rage Pro onboard my machine should have 8MB RAM that it has to map somewhere... it most definitely does work as a frame buffer at least, so they handled it some way...

(The ATI Rage Pro seems slow on my ia64 box compared to my discrete AGP ATI Rage Pro... but that's just a guess based on how it *seems* to run.)

You seen an issue where there is none. There is no difference between ram and a device window; look at the 32bit
address space as a tiny subset of the larger 64bit space, and the arbiter inside the chipset knows based on the configuration
which chipselect line to pull when presented with a memory address (the ZX1 has an io virtualization unit which does IOMMU and
GART [AGP] duties]). Also since most PCI devices can't really cope with >32bit addresses (really, some broadcom network cards
can't even handle that little space) it's just easier to move the windows for pci (really, all external devices) somewhere in the
32 bit space and remap usable ram to just above the 4G barrier. Try it with 4g ram on a x64 box: bios will usually report 3G
of usable ram in the 32bit space and an extra 1g above 4g because of all the hardware windows (and kernel space) between 3g and 4g.

The reason it's printed as 32bit hex is because the format string for that particular printk is "%lx" ;)

As to the original issue: It works, doesn't it? Kernel recognizes both radeons. The alignment warnings are probably
the result of using either an older compiler and/or bad coding in the driver. I've seen similar issues when I initially
started out with Gentoo on MIPS (like all other archs mips is quite allergic to unaligned accesses for obvious reasons,
but doesn't warn about them and traps into the kernel to emulate them), but they gradually went away while rebuilding
all packages.

[eccerr0r]

You seen an issue where there is none. There is no difference between ram and a device window; look at the 32bit
address space as a tiny subset of the larger 64bit space, and the arbiter inside the chipset knows based on the configuration
which chipselect line to pull when presented with a memory address (the ZX1 has an io virtualization unit which does IOMMU and
GART [AGP] duties]). Also since most PCI devices can't really cope with >32bit addresses (really, some broadcom network cards
can't even handle that little space) it's just easier to move the windows for pci (really, all external devices) somewhere in the
32 bit space and remap usable ram to just above the 4G barrier. Try it with 4g ram on a x64 box: bios will usually report 3G
of usable ram in the 32bit space and an extra 1g above 4g because of all the hardware windows (and kernel space) between 3g and 4g.

The reason it's printed as 32bit hex is because the format string for that particular printk is "%lx" ;)

As to the original issue: It works, doesn't it? Kernel recognizes both radeons. The alignment warnings are probably
the result of using either an older compiler and/or bad coding in the driver. I've seen similar issues when I initially
started out with Gentoo on MIPS (like all other archs mips is quite allergic to unaligned accesses for obvious reasons,
but doesn't warn about them and traps into the kernel to emulate them), but they gradually went away while rebuilding
all packages.

The issue at hand is that there IS an issue. The cards do NOT work on ia64. They may recognize the cards, but they don't work. I'm just speculating potential issues of how they may have implemented the mapping, as these are issues that may affect architectures not tested for by the original drivers (including the fact that the drivers may not even handle the fact it could be running on machines with > 32bit address space). If the graphics drivers were truely arch independent, this thread wouldn't be here...

The issue of initialization by the board's BIOS still exists as a potential issue. This definitely is a potential problem; I even have a PCI SCSI card meant for an EFI ia64 box that doesn't work in a ia32 box at all, though the chipset is supported by Linux... At least there should be no mapping issue here.

[roarinelk]

Ah, I suspect that's a problem with the BIOS code on the card itself: The ROM
code is supposed to be executed within an x86 real mode environment which
ia64 can't provide (for basic initialization of the chip). Although the ATOMBIOS
stuff on newer ATI's is supposed to solve this to some extent, since the
kernel and the radeon X driver both have an atombios interpreter.

[RussianE39]

I have HP ZX6000 machine (cousin of rx2600 server) and after some little tricks I was able to run Radeon HD 4650 AGP card in it. Main problem would be lack of any Molex connector to feed modern card VRM's, if card needs only +12V for their supply, you could tap to CPU VRM's feed line. If you card also needs +5V, things would be more tricky, althogh my particular 4650 from gigabyte won't need any +5V from molex supply. I can report, that KMS and DRI partially works with this card:
80:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI RV730 Pro AGP [Radeon HD 4600 Series]
80:00.1 Audio device: Advanced Micro Devices [AMD] nee ATI RV710/730 HDMI Audio [Radeon HD 4000 series]

[drm] Initialized drm 1.1.0 20060810
[drm] radeon defaulting to kernel modesetting.
[drm] radeon kernel modesetting enabled.
GSI 60 (level, low) -> CPU 0 (0x0000) vector 51
[drm] initializing kernel modesetting (RV730 0x1002:0x9495 0x1458:0x0028).
[drm] register mmio base: 0xCFFD0000
[drm] register mmio size: 65536
ATOM BIOS: GV
radeon 0000:80:00.0: putting AGP V2 device into 4x mode
radeon 0000:80:00.0: GTT: 512M 0x60000000 - 0x7FFFFFFF
radeon 0000:80:00.0: VRAM: 1024M 0x7FFFFFFF - 0xBFFFFFFE (1024M used)
[drm] Detected VRAM RAM=1024M, BAR=256M
[drm] RAM width 128bits DDR
Problem I'm suffering now is just low 3D performance, but I think it is not related to hardware, but more radeon driver problem which I plan to solve soon. Thank you for valuable information about AGP cage compatibility with rx2620. The last piece of secret would be finding configuration of fans - I don't want my workstation to produce noise as server.

[MG]

I have HP ZX6000 machine (cousin of rx2600 server) and after some little tricks I was able to run Radeon HD 4650 AGP card in it. Main problem would be lack of any Molex connector to feed modern card VRM's, if card needs only +12V for their supply, you could tap to CPU VRM's feed line. If you card also needs +5V, things would be more tricky, althogh my particular 4650 from gigabyte won't need any +5V from molex supply. I can report, that KMS and DRI partially works with this card.

Do you perhaps have any pictures to show of this configuration? I have an ATi Radeon HD4670 (AGP) here, which also has an additional/external power requirement. Especially now that I'm planning to reinstall Gentoo, this time hopefully with DRM/DRI, it's definitely an interesting thing to try. I was going to go with an HD5450 (PCI), for obvious reasons, but the HD4670 should be a bit more interesting...