Announcement

Collapse
No announcement yet.

ATI R600 Gallium3D Driver Continues Advancing

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

  • #91
    Note that it's possible that Fedora not using TLS might slow me down a bit. Dunno whether there's a significant penalty. (I'm not using SELinux)
    Will try with newer stuff soon and recompiling things with TLS a little later.

    Comment


    • #92
      Originally posted by monraaf View Post
      The excessive memory consumption I'm seeing with hl2 is probably something with wine.
      hmmmmm.. maybe. maybe not.

      Take a look at this file (current revision) and search for r600_delete_ps_shader.

      wine has some quirks where it's frequently re-creating shaders, so I'd imagine that this leak will hit harder in wine games.

      At least it's a known leak.

      Comment


      • #93
        OK, I've tried r600g.

        In my tests, it is 2x slower than r600c in openarena. I get solid 60fps with classic, struggle to get solid 30fps with gallium. This is with vsync, so only rough numbers.

        KWin bails out complaining that the effects are too slow. I didn't try disabling the checks. It works fine with classic.

        Still, nice progress. I haven't noticed any rendering artifacts or lockups, so things re progressing nicely.

        Comment


        • #94
          R300g v. R300c

          Originally posted by xiando View Post
          I "imagine" development is going forward as indicated by mesa git log, http://cgit.freedesktop.org/mesa/mes...t=grep&q=r600g



          My distro does not provide binary packages... and I do eselect mesa set r600 classic when I'm done checking out how the current r600g is doing.



          The way FOSS works hasn't really changed much the last 15 years, but I am glad I could help you release all that supressed anger.
          While R600c leads now, I honestly don't expect it to maintain that lead for long, if the performance gains by R300g are anything to go by. R300g is now actually starting to show up in distribution testing cyclss (and not just Ubuntu, where it has completely replaced R300c, but Debian/Arch/Gentoowide). However, there have been other changes in the Linux graphics firmament (Flash plugin behavior in particular), and if you have hardware that changes over to R300g for Xorg support (basically, Radeon 9200 through the X1K series) you will have no idea whether to yell at Tungsten (who did a ton of contribution work toward the new server) or Adobe (however, because of issues with Flash that are not unique to Linux, I feel on safer ground yelling at Adobe for the sorry state of their Flash plugin).

          As I stated earlier, some distributions have already swapped out R300c for R300g during their test cycle; Ubuntu is the most well-known, with Maverick Meerkat kicking 10.10 RC out the door this week. I have two GPUs that I've been throwing at the new server - an AMD AIW 9700 Pro and an X1650 Pro, both in AGP flavor. The test platform otherwise is a P4 2.4 with 512 MB of DDRr333, 40 GB WD PATA HDD, and, as staed, Kubuntu 10.10 RC. From straightforward seat-of-pants observations, R300g loses nothing peerformancewise compared to R300c, and is actually more stable than R300c driving KDE (which, in the 4.5.1 iteration included with Maverick Meerkat, places more demands on Xorg than older versions of KDE); this would actually make KDE 4.5.x a viable option with legacy AMD hardware, which has not really been the case (except among masochistic types due to both performance and stability issues).

          Because R300g is a drop-in replacement, as long as you have Xorg 1.9 and Mesa 7.9 or later, if your GPU is covered by this server, you need do nothing in the way of post-change fiddling, which ususally isn't the case with a point release of Xorg, let alone point releases of both Xorg and Mesa, coming down the pike.

          Comment


          • #95
            Originally posted by PGHammer View Post
            and not just Ubuntu, where it has completely replaced R300c
            As I stated earlier, some distributions have already swapped out R300c for R300g during their test cycle; Ubuntu is the most well-known, with Maverick Meerkat kicking 10.10 RC out the door this week.
            I believe this is all wrong. Quoting from the maverick mesa debian/rules file:
            Code:
            # We should switch to r300g soon, but it won't support UMS.  Stick
            # with r300c for now
            R300g loses nothing peerformancewise compared to R300c, and is actually more stable than R300c
            Maybe for KMS, but UMS (classic) still beats the pants off KMS (classic or gallium) in many cases. And some users need UMS because of KMS bugs.

            Comment


            • #96
              Originally posted by pingufunkybeat View Post
              In my tests, it is 2x slower than r600c in openarena.
              Would you mind explaining the concept of "2x slower"? Because "slowness" is not a measurable metric that you can multiply.

              I suggest you re-encode that brainfart in proper fractions. I.e. "1/2 speed".

              Comment


              • #97
                In my tests, it does not work at all
                ## VGA ##
                AMD: X1950XTX, HD3870, HD5870
                Intel: GMA45, HD3000 (Core i5 2500K)

                Comment


                • #98
                  What KMS bugs?

                  Originally posted by tormod View Post
                  I believe this is all wrong. Quoting from the maverick mesa debian/rules file:
                  Code:
                  # We should switch to r300g soon, but it won't support UMS.  Stick
                  # with r300c for now
                  Maybe for KMS, but UMS (classic) still beats the pants off KMS (classic or gallium) in many cases. And some users need UMS because of KMS bugs.
                  What KMS bugs?

                  The only bugs I've ever seen in KMS have been related to something outside of Xorg server control (such as kernel issues prior to 2.6.34). The classic *radeon* Xorg server has supported KMS since Xorg 1.8, and that includes all the way back to the original (R100/Radeon 7000, if you want to be picky); this server is still used by hardware too old to be supported by R300c/g or R600c/g. I'm using an AMD Radeon 7500 (an R100/RV200 part) in Kubuntu 10.10 RC, where KMS is enabled by default (kernel is 2.6.35-22), and I haven't had a lick of trouble with KMS, despite the ancient hardware. The issue may be present in applications I don't use (such as WINE); however, even WINE is a kludge.

                  I won't say that there *are* no bugs still; however, I personally haven't experienced any that are related directly to the FOSS AMD server efforts in any way/shape/form in the aplications I use.

                  Therefore, the question stands.

                  Comment


                  • #99
                    Originally posted by droidhacker View Post
                    Would you mind explaining the concept of "2x slower"? Because "slowness" is not a measurable metric that you can multiply.

                    I suggest you re-encode that brainfart in proper fractions. I.e. "1/2 speed".
                    Twice as slow is half as fast. Measured in terms of fps in open arena.

                    Now go get laid, you stuck up cunt.

                    Comment


                    • It Depends On Where The User Is Coming From

                      Originally posted by RealNC View Post
                      I don't really believe they be grateful. Your average Ubuntu user expects his stuff to work and doesn't know much about what Gallium3D is.
                      It still depends on where the user is coming from (as is the case with any new/upgrading user). Despite their reputation for it-largely-just-works, 'buntu has been known to take steps that no other Debian-based distribution (including rolling releases such as sid) is willing to take (such as working with AMD to gain customized Linux Catalyst driver releases, and going with newer kernels, such as 2.6.35-22 in the Maverick Meerkat RC). It is for this reason that I have added an older P4 to my test platform regime in order to observe the state of R300g (which has actually replaced R300c in Maverick Meerkat, and is available as a drop-in replacement for Lucid Lynx via both xorg-edgers and x-swat PPAs). My Evergreen_accel testbox needs a motherboard swap (BIOS in the current mobo has locked up); further, xorg-edgers has been having issues with compiles from this branch (this is something I've observed both prior to and since my meltdown), so I am taking this look in the meantime. I have noticed that R300g is more stable than R300c, especially considering that KMS is now enabled by default in Maverick, and under far heavier loads than the older R300c/UMS combination (even with UMS and R300c, KDE was largely for masochists; however, KDE is now actually usable, KMS and all, on anything driven by R300g).

                      It is also why I asked the question earlier of another poster in this thread that complained about bugs in KMS. Other than issues relating entirely to older kernels (anything older than 2.6.34 has known issues supporting KMS, and that is regardless of distribution), I have not seen any (either in posts in various fora, here, or personal observation). I want documentation/bug reports; otherwise, I have to take such comments with a large saltmine from Siberia.

                      Comment


                      • Originally posted by PGHammer View Post
                        What KMS bugs?
                        <snip>
                        Therefore, the question stands.
                        I am not saying that everybody has issues with KMS, and I think most users share your personal experience of flawless KMS. It is just random issues you'll see in bug trackers and forums, where "radeon.modeset=0 fixed my problem thx". Hopefully this is soon history, but for now having the UMS fallback is nice. Just look back at when our intel user friends got their driver stripped of all "legacy"... Fortunately the radeon developers care about backwards compatibility and maintenance.

                        Comment


                        • Originally posted by tormod View Post
                          Just look back at when our intel user friends got their driver stripped of all "legacy"
                          I still have LOTS of BIG problems with Intel and KMS.
                          ## VGA ##
                          AMD: X1950XTX, HD3870, HD5870
                          Intel: GMA45, HD3000 (Core i5 2500K)

                          Comment


                          • Originally posted by pingufunkybeat View Post
                            OK, I've tried r600g.

                            In my tests, it is 2x slower than r600c in openarena. I get solid 60fps with classic, struggle to get solid 30fps with gallium. This is with vsync, so only rough numbers.

                            KWin bails out complaining that the effects are too slow. I didn't try disabling the checks. It works fine with classic.

                            Still, nice progress. I haven't noticed any rendering artifacts or lockups, so things re progressing nicely.
                            What CPU ? What GPU ? How much RAM ? What kernel/ddx version and what mesa git commit. I am trying to find a config where r600g perform significantly slower but so far i only have config were it's at same level or little bit slower but definitly not 2 times slower (i have all vsync stuff off)

                            Comment


                            • Originally posted by glisse View Post
                              What CPU ? What GPU ? How much RAM ? What kernel/ddx version and what mesa git commit. I am trying to find a config where r600g perform significantly slower but so far i only have config were it's at same level or little bit slower but definitly not 2 times slower (i have all vsync stuff off)
                              I just noticed you implemented color tiling on R600g
                              To be honest it didn't work without color tiling (I had to reboot X), but now it works fine so I did some more benchmarks.

                              Openarena, 2560x1600, Very High quality.
                              R600c + color tiling: 92.3 fps
                              R600g + color tiling: 15.9 fps

                              Is it slow enough? HD 3870, 2 GB of ram, Athlon 64 3800+X2. Kernel: yesterday's drm-radeon-testing. ddx and mesa are today's snapshots.
                              ## VGA ##
                              AMD: X1950XTX, HD3870, HD5870
                              Intel: GMA45, HD3000 (Core i5 2500K)

                              Comment


                              • Originally posted by PGHammer View Post
                                R300g (which has actually replaced R300c in Maverick Meerkat
                                You still want to debate this?
                                It is also why I asked the question earlier of another poster in this thread that complained about bugs in KMS. Other than issues relating entirely to older kernels (anything older than 2.6.34 has known issues supporting KMS, and that is regardless of distribution), I have not seen any (either in posts in various fora, here, or personal observation). I want documentation/bug reports; otherwise, I have to take such comments with a large saltmine from Siberia.
                                If you are referring to my post, I was definitely not "complaining". I explained why distributions are happy to keep the UMS fallback that classic provides. I am not gonna wade through e.g. ubuntuforums.org to find examples for you, but as an example from my own experience even 2.6.35 KMS locks up for me due to fd.o bug 29389, and earlier kernels have no power management...

                                Comment

                                Working...
                                X