Page 2 of 3 FirstFirst 123 LastLast
Results 11 to 20 of 25

Thread: Mesa 7.5 RC3 Brings Build, Bug Fixes

  1. #11
    Join Date
    Aug 2007
    Posts
    153

    Default

    Quote Originally Posted by FallenWizard View Post
    MAD, I miss you in #zen-sources, you weren't there since ages.
    The features I needed in zen-sources have gone upstream. I don't really need it anymore. :3

    Maybe I'll /join again.

  2. #12
    Join Date
    May 2008
    Posts
    598

    Default

    Quote Originally Posted by MostAwesomeDude View Post
    As soon as KMS+GEM works on those cards, I'll add radeon softpipe support for them, which means that DRI2 SW rendering will work. After that, it'll be the long, slow road of porting r6xx-rewrite into the Gallium architecture.
    Last time we heard from Bridgman, I think he said that AMD now is working on writing the power management specs and example code.

    We haven't heard from the Novell developers in a long ting, and the last we heard from Red Hat was their work in KMS being their main interest.

    Do you have an update where things are going, and who is working on what?

  3. #13
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,284

    Default

    Alex pushed initial power management code (engine clock, clock gating, pcie lanes) a while back, then Yang added engine clock adjust to radeonhd. Matthias just published a patch to add clock gating to 5xx/rs6xx, and Alex wrote up a summary of the power management info & options in his blog :

    http://www.botchco.com/agd5f/?p=45

    In terms of who's doing what, the transition to KMS is still the main focus, with glisse working on merging in new TTM code and a number of devs working on getting the radeon-rewrite branch of mesa ready to merge into master. We're doing most of the 6xx-7xx 3d work, and again there the big effort over the last couple of months was moving across to the radeon-rewrite code base as well. MostAwesomeDude is still making progress on the 3xx-5xx Gallium3D port, and at least one other dev is contributing there as well.

  4. #14
    Join Date
    May 2008
    Posts
    598

    Default

    Quote Originally Posted by bridgman View Post
    Alex pushed initial power management code (engine clock, clock gating, pcie lanes) a while back, then Yang added engine clock adjust to radeonhd. Matthias just published a patch to add clock gating to 5xx/rs6xx, and Alex wrote up a summary of the power management info & options in his blog :

    http://www.botchco.com/agd5f/?p=45

    In terms of who's doing what, the transition to KMS is still the main focus, with glisse working on merging in new TTM code and a number of devs working on getting the radeon-rewrite branch of mesa ready to merge into master. We're doing most of the 6xx-7xx 3d work, and again there the big effort over the last couple of months was moving across to the radeon-rewrite code base as well. MostAwesomeDude is still making progress on the 3xx-5xx Gallium3D port, and at least one other dev is contributing there as well.
    Cool break down. It is always interesting to hear where things are going

    I remember Linus not being too keen on the KMS merge to the kernel. Have that been sorted out, or are there potential show stoppers there?

    Btw. I have read the Anandtech review of the much awaited Athlon II X2 250, and according to Wikipedia, it hit the channel June 2nd.

    I assume June 2nd is for the US. Do you have an estimate how long it takes for a new CPU to be available world wide, as I don't live in the US?

  5. #15
    Join Date
    Jul 2008
    Posts
    565

    Default

    Quote Originally Posted by MostAwesomeDude View Post
    After that, it'll be the long, slow road of porting r6xx-rewrite into the Gallium architecture.
    I thought Gallium3D was supposed to greatly simplify the writing of drivers. Or is it simpler, but still not incredibly easy?

  6. #16
    Join Date
    Dec 2007
    Location
    Germany
    Posts
    364

    Default

    Quote Originally Posted by Yfrwlf View Post
    I thought Gallium3D was supposed to greatly simplify the writing of drivers. Or is it simpler, but still not incredibly easy?
    It's not neccessarily simpler nor easier, but the code will be a lot cleaner (easier to debug and stuff) and once you've got it working, Gallium3D provides access to the whole range of state trackers (e.g. OpenGL 1-3, video decoding acceleration, OpenCL, network debugging, etc).

  7. #17
    Join Date
    Jul 2008
    Posts
    565

    Default

    Quote Originally Posted by NeoBrain View Post
    It's not neccessarily simpler nor easier, but the code will be a lot cleaner (easier to debug and stuff) and once you've got it working, Gallium3D provides access to the whole range of state trackers (e.g. OpenGL 1-3, video decoding acceleration, OpenCL, network debugging, etc).
    So then it *is* simpler if you want things like OGL and whatnot...if it didn't make it simpler to write and manage "fully-featured" drivers, then there'd be utterly no point in Gallium3D.

    I think I could condense down the entire point of software into that, actually. Better software has more features as well as making it easier to create those and future features and create content in general. (ok and of course tack on the usual less buggy, performs better, etc, but I lumped those into "features")

    Look forward to the day when you can easily snap in a few things to create the program you want, or better yet just think about it. It's coming, but needs to hurry the $!@# up.

  8. #18
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,284

    Default

    Quote Originally Posted by Yfrwlf View Post
    I thought Gallium3D was supposed to greatly simplify the writing of drivers. Or is it simpler, but still not incredibly easy?
    Yeah, I think that sums it up pretty well. Using Gallium rather than the classic Mesa hardware driver model seems to take the task from "mind-numbingly difficult" to "a lot of hard work", which of course is a significant improvement.

  9. #19
    Join Date
    Jul 2008
    Posts
    565

    Default

    Quote Originally Posted by bridgman View Post
    Yeah, I think that sums it up pretty well. Using Gallium rather than the classic Mesa hardware driver model seems to take the task from "mind-numbingly difficult" to "a lot of hard work", which of course is a significant improvement.
    OK, whew, sanity check passed. ^^

    Too bad there's not some way of making it excruciatingly easy!

  10. #20
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,284

    Default

    There is... we could go back to making GPUs the way we did 10 years ago, where the GPU registers more or less matched the OpenGL state variables

Posting Permissions

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