Radeon vs. RadeonHD: http://www.phoronix.com/vr.php?view=12052
Announcement
Collapse
No announcement yet.
Full EXA Composite For R300-500 GPUs
Collapse
X
-
-
Originally posted by an0n1m0us View PostThis news makes very little sense. I was told in an IRC chat that the Radeon driver was dead, that it was a case of RadeonHD slowly becoming usable and the proprietary driver as the only two options. Also doesn't Alex work for AMD now? Or was that somebody else. If so, why isn't this EXA support going into RadeonHD?
- separate driver for newer chips, duplicate the acceleration code across the two drivers (radeonhd)
- one driver with separate modesetting code for older & newer chips, one copy of the acceleration code (radeon)
All of the acceleration work being performed recently (Textured Video, EXA rotate & blend, 3D) uses the 3D engine, which in turn requires DRI support in the driver. Today the radeon driver has DRI support but radeonhd does not, so in the short term acceleration work is being done using radeon. Adding DRI support and porting across the existing 2D & video acceleration code is top priority for radeonhd, since that will allow acceleration work to be done using radeonhd, not just in radeon.
As long as we keep the acceleration code common between the two drivers, work done in one driver will be able to immediately benefit the other anyways.Last edited by bridgman; 19 March 2008, 08:28 AM.Test signature
Comment
-
Ah, I had remembered a few quotes from the radeonhd developers along the lines of "we're trying to keep things similar to make sharing code easier" from the forum and from FOSDEM talks. I guess the drivers diverged enough for this to be no longer the case.
EDIT: Thanks for the clarification of modesetting / acceleration.
After reading today's article, my big question is which method leads to kernel-level modesetting, ideally, platform independent (non-x86) kernel-level modesetting?
I'm a tad confused as to what AtomBIOS actually is. When I heard it being discussed before, the idea of parsing and scripts, made me think it was a way to keep the interface high-level, by passing tokens to the GPU, it then turned these into all the necessary register changes internally. Thus it not only kept the driver smaller, but let the CPU focus on other things. If that's what it does, I'm okay with using it so long as docs are released. If AtomBIOS is just a way of putting x86 blobs in firmware, i.e. the tokens are turned in x86 assembly for the CPU, I think the Novell developers are right, and it should be avoided.
Comment
-
Originally posted by yoshi314 View Posti would not mind having two separate drivers. r5xx and newer have some substantial changes to 2d acceleration, and it seems pretty reasonable to have a separate driver for these cards.Last edited by agd5f; 19 March 2008, 10:51 AM.
Comment
-
Originally posted by Tillin9 View PostI'm a tad confused as to what AtomBIOS actually is. When I heard it being discussed before, the idea of parsing and scripts, made me think it was a way to keep the interface high-level, by passing tokens to the GPU, it then turned these into all the necessary register changes internally. Thus it not only kept the driver smaller, but let the CPU focus on other things. If that's what it does, I'm okay with using it so long as docs are released. If AtomBIOS is just a way of putting x86 blobs in firmware, i.e. the tokens are turned in x86 assembly for the CPU, I think the Novell developers are right, and it should be avoided.
Comment
-
Originally posted by Tillin9 View PostAh, I had remembered a few quotes from the radeonhd developers along the lines of "we're trying to keep things similar to make sharing code easier" from the forum and from FOSDEM talks. I guess the drivers diverged enough for this to be no longer the case.
Originally posted by Tillin9 View PostAfter reading today's article, my big question is which method leads to kernel-level modesetting, ideally, platform independent (non-x86) kernel-level modesetting?Test signature
Comment
-
Originally posted by bridgman View PostBoth methods could work fine for kernel modesetting. I think Dave (the kernel DRM maintainer) is leaning towards AtomBIOS because it allows the modesetting code to be smaller and require fewer changes for new GPUs, but that is more of a preference than a black/white choice.
Comment
-
Thanks for all the clarification. If AtomBIOS is just a lookup table designed so that drives can be smaller and documentation needs not be at the level of set this register, then set that register, I think its more than okay. Especially if everything is being documented anyway.
Just to mention I'm eagerly waiting for kernel modesetting, I have a MIPS box I'd love to equip with an X1550.
Comment
-
Originally posted by Tillin9 View PostThanks for all the clarification. If AtomBIOS is just a lookup table designed so that drives can be smaller and documentation needs not be at the level of set this register, then set that register, I think its more than okay. Especially if everything is being documented anyway.
Comment
Comment