Page 4 of 10 FirstFirst ... 23456 ... LastLast
Results 31 to 40 of 99

Thread: Linux 2.6.32 To Get R600 KMS Along With 3D

  1. #31
    Join Date
    Aug 2008
    Location
    Finland
    Posts
    1,671

    Default

    Quote Originally Posted by Louise View Post
    6 BEST? If that also applies to OpenGL 3.0 compliance, that's something I can live with

    Adding OpenGL 3.0 support to each of the GPU's sounds like an enormous task?
    OpenGL 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.

  2. #32
    Join Date
    Aug 2008
    Location
    Finland
    Posts
    1,671

    Default

    Quote Originally Posted by Ex-Cyber View Post
    So is it pretty reasonable to expect "classic Mesa" R600 3D support to land in the first round of 2010 distro releases?
    Sounds reasonable especially if distros won't wait for a release if it takes too long but just go with a git snapshot. (as in, I'd assume it'd be even more useful then since it can even now run games)

  3. #33
    Join Date
    Jul 2009
    Posts
    416

    Default

    Will the new radeon KMS eventually use UXA? Or is that only for GEM and not TTM?

  4. #34
    Join Date
    Oct 2008
    Posts
    3,173

    Default

    Quote Originally Posted by pvtcupcakes View Post
    Will the new radeon KMS eventually use UXA? Or is that only for GEM and not TTM?
    It 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.

    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.

  5. #35
    Join Date
    Dec 2007
    Posts
    2,395

    Default

    Quote Originally Posted by smitty3268 View Post
    It 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.
    It's not clear that it would be of much use on our IGPs either. There are also improvements for EXA that are coming down the pipe that would need to be ported to UXA to be able to use them there.

    Quote Originally Posted by smitty3268 View Post
    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.
    The Xorg state tracker is just like the GL or video state trackers. Once they are implemented they will work on any gallium driver. Once there is a gallium driver any state trackers should just work for the most part. That's what's neat about gallium.

  6. #36
    Join Date
    Jul 2008
    Posts
    565

    Default

    Awesome news, can't wait to see decent open source 3D.

  7. #37
    Join Date
    May 2008
    Posts
    598

    Default

    Quote Originally Posted by nanonyme View Post
    OpenGL 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.
    I can understand that. it must be a lot more fun to work on Gallium rather than classic Mesa.

  8. #38
    Join Date
    Jan 2008
    Posts
    112

    Default

    Quote Originally Posted by bridgman View Post
    For 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.
    What 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)?

    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.

  9. #39
    Join Date
    Nov 2008
    Location
    California
    Posts
    61

    Talking

    Hoo-Ray! Arch Linux will get r600 OpenGL by Christmas!

  10. #40
    Join Date
    Dec 2007
    Posts
    2,395

    Default

    Quote Originally Posted by oblivious_maximus View Post
    What 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)?
    TV-out on avivo chips (r5xx-r7xx) should can be considered pretty close to done at this point (add Option "ATOMTvOut" "TRUE" to the device section of your xorg config to enable). Scaling of just about any mode works. Only tv-out on the pre-avivo chips (r1xx-r4xx) is limited to 800x600.

    Better power management is next on our list once r6xx/r7xx 3D support stabilizes a bit more.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •