Announcement

Collapse
No announcement yet.

ATI R600g Gains Mip-Map, Face Culling Support

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #71
    Originally posted by glisse View Post
    if i were to redo KMS today there is few major things i would change.
    If and when there will be a comprehensive radeon KMS documentation, this stuff would probably deserve to be included. As in, post-implementation thoughts, how could it be better if someone ever wants to go back at it.

    Comment


    • #72
      Originally posted by netkas View Post
      latest r600g and ioquake3
      Some patience? Probably more sense to check git log on which features have been implemented and then go try with the respective demos to see if the implementations are sound and work.

      Comment


      • #73
        Actually, I'm quite impressed that it runs ioquake already. Once it can run OpenArena more or less like r600c, I'll switch

        Comment


        • #74
          Originally posted by pingufunkybeat View Post
          Actually, I'm quite impressed that it runs ioquake already. Once it can run OpenArena more or less like r600c, I'll switch
          Agreed! I saw those screenies and was amazed because it wouldn't even run glxgears awhile back... Once it can properly run OpenArena it's time for me to switch and do daily build of the gallium

          Comment


          • #75
            Hint: don't do a daily build. Read git log for new features. It's faster than compiling Mesa.

            Comment


            • #76
              I think the best way to improve things would be to find out how to attract more individual developers and companies to help in development of Mesa and Gallium, or fund such development (and/or doing any of these yourself).

              Perhaps some cool tutorial on how to make a game work by implementing a new OpenGL extension for Mesa, or adding a feature to r600g or nv50g would help in that (obviously, it would be retrospective analysis on something already added).

              Another interesting avenue could be attempting to add OpenCL support to server applications.
              If significant gains can be demonstrated, good GPU drivers would become a must in the Linux server market, which is very significant.
              I'm not sure however whether this can be done for a significant share of server applications.

              And finally, getting third parties (or even employees of the GPU company itself, but that's harder) with NDA access to specifications and/or proprietary code to leak them will also obviously help (especially for very unfriendly companies like nVidia and Imagination).

              Longer term, a move to Larrabee-style dumb GPUs with stable ISAs (and "graphics-on-compute" programming models) will likely make driver writing much easier and allow sharing much more between GPUs, hopefully obsoleting ad-hoc proprietary driver stacks.

              Comment


              • #77
                Nightly builds don't bother me... I have cron already running a build script when my computer is idling anyway...

                Comment


                • #78
                  Oh, and it would be nice if AMD could somehow speed up the release of their Evergreen Mesa code (and ideally r700->evergreen 3D register differences too), so people who bought recent cards can actually contribute...

                  Comment


                  • #79
                    Originally posted by bridgman
                    There wsn't really much to release until the last week or so... the devs have been working through major rendering problems. I saw glxgears run "ok" for the first time on Friday.
                    Out of curiosity: did the system you saw glxgears working have new enough DRM that vsync worked? I noted Michael's system didn't.

                    Comment


                    • #80
                      There wasn't really much to release until the last week or so... the devs have been working through major rendering problems. I saw glxgears run "ok" for the first time on Friday.

                      We can't really write useful "here's how to program it" documentation or know what parts of the registers specs need to be included until we've figured out how to make it work ourselves...

                      Comment

                      Working...
                      X