Originally posted by Louise
View Post
Announcement
Collapse
No announcement yet.
Linux 2.6.32 To Get R600 KMS Along With 3D
Collapse
X
-
Originally posted by Ex-Cyber View PostSo is it pretty reasonable to expect "classic Mesa" R600 3D support to land in the first round of 2010 distro releases?
Comment
-
Originally posted by pvtcupcakes View PostWill the new radeon KMS eventually use UXA? Or is that only for GEM and not TTM?
What I'm less clear about is the Gallium Xorg state tracker. It's supposed to implement EXA + Xv, and use KMS for modesetting to let you remove the radeon/radeonhd driver entirely. But I don't know if it's implementing EXA like the existing drivers do, or if it's relying on the memory managers since they're required for Gallium, or what. So it might be some sort of hybrid approach. Can any developers comment on whether it's even going to be used? I see on the feature matrix that it's marked in progress, so I assume that it is, but I don't know if it is considered sufficient to completely replace radeon or if some people consider it too generic or incomplete.
Comment
-
Originally posted by smitty3268 View PostIt won't, pretty much everyone is in agreement that UXA is only valuable for integrated graphics that share system memory. AMD has a few of those, but it's not worth supporting an entire architecture just for 1 or 2 models.
Originally posted by smitty3268 View PostWhat I'm less clear about is the Gallium Xorg state tracker. It's supposed to implement EXA + Xv, and use KMS for modesetting to let you remove the radeon/radeonhd driver entirely. But I don't know if it's implementing EXA like the existing drivers do, or if it's relying on the memory managers since they're required for Gallium, or what. So it might be some sort of hybrid approach. Can any developers comment on whether it's even going to be used? I see on the feature matrix that it's marked in progress, so I assume that it is, but I don't know if it is considered sufficient to completely replace radeon or if some people consider it too generic or incomplete.
Comment
-
Originally posted by nanonyme View PostOpenGL 3.0 for radeon will be built on top of Gallium3D so it'll be those r300g and r600g driver effort ratios instead + the effort that it takes to actually implement OpenGL 3.0 over Gallium3D.
Comment
-
Originally posted by bridgman View PostFor the Mesa features marked "Mostly", 6
For GLSL, 21
Gallium 3xx-5xx, 18
Gallium 6xx-7xx, 33
Not sure about units yet. Probably different units for each line item
Seriously, most of the remaining work is bug fixing, eg things like text corruption when typing with Compiz active. Richard is probably also going to add support for the draw_prims driver hook, which will bring the 6xx/7xx code closer to 3xx/5xx and should deal with a few of the remaining app problems.
Past that, I think the focus will shift to GLSL and Gallium3D, plus maybe some power management and new GPU support.
I just noticed there seems to be a few more "Done" boxes in the Suspend Support and Console Restore lines too(great stuff!)!. An estimate of when the R700 column for those rows will no longer read "Unknown" would be much appreciated also (I'm really itching to buy a 4770 or maybe even a 4850).
It's really nice to see all this work finally starting to near relative completion. Great stuff.
Comment
-
Originally posted by oblivious_maximus View PostWhat about TVout and Power Management support? Any chance of a rough estimate of when we can expect to see the feature matrix show "Done" all the way across those rows (for the radeon driver anyway, not radeonhd), or an estimate of how far along those features currently are? The article mentions KMS tvout support, will that mean feature parity with fglrx for svideo output options (last I heard you could only do NTSC at 800x600 - I want 640x480)?
Better power management is next on our list once r6xx/r7xx 3D support stabilizes a bit more.
Comment
Comment