Announcement

Collapse
No announcement yet.

A Big Comparison Of The AMD Catalyst, Mesa & Gallium3D Drive

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

  • #31
    Originally posted by marek View Post
    The Mesa state tracker and Mesa core slow things down. Some state tracker optimizations are being worked on and that should make the performance a little better. The whole thing could be made faster if the classic driver interface was dropped and both the core and the state tracker were merged together and simplified. This won't happen until Intel jump over to Gallium. Intel are still doing the majority of work on Mesa, so we can't just ignore them.
    What great news! Go X.Org!

    Comment


    • #32
      Originally posted by BlackStar View Post
      No, that won't cut it. Compiz *can* do what you suggest, but this 'feature' is extremely userunfriendly and is thankfully disabled by default. If you disable compositing for fullscreen windows and a notification pops up, you are in for a flicker-fest.

      This is 2011 after all, even IGPs have more than enough horsepower to compose a 2 or 3MP desktop.
      It works fine in KWin

      Comment


      • #33
        Originally posted by pingufunkybeat View Post
        It works fine in KWin
        KWin also flickers when enabling compositing. Curiously though, it does not flicker the other way around (disabling compositing.)

        If that could be somehow fixed, it would be a huge improvement.

        Comment


        • #34
          I bought a Radeon 9800 SE (The saphire atlantis one) and put it in my dual PII@300Mhz ... AGP 2x

          It run compiz quite well... but games appear severly CPU limited lol dunno if its in the game or the driver though.

          Comment


          • #35
            Originally posted by 89c51 View Post
            marek since you are a dev and probably know more on the subject do you see Intel dropping classic and going Gallium and if when whats the timeframe.

            i remember reading that they were not keen on making the jump
            Intel appear to be in love with their GLSL compiler and they want to generate code directly from the GLSL IR. I think they don't want to exchange that for TGSI, it would be like a step backwards for them.

            Comment


            • #36
              Originally posted by Mr James View Post
              Now that is what I call AMD support.
              I call it. "Give us Speecs an the Community do the rest" ......

              Originally posted by evolution View Post
              I hope they also fix the UVD1/UVD1+ H264/VC-1 problems in r600 generation cards (HD2xxx/HD3xxx) on both Windows / Linux OS's.
              What problem? DXVA works like an charm for my HD3850 under Windows 7. I use MPC-HC and XBMC. Please node that the HD2 and HD3 Series can only decompress 1 Stream.
              PS: I Update my driver each month.

              --------------

              It's only a matter of Manpower. So great job to all OpenSource Driver Devs.

              Comment


              • #37
                Originally posted by marek View Post
                Intel appear to be in love with their GLSL compiler and they want to generate code directly from the GLSL IR. I think they don't want to exchange that for TGSI, it would be like a step backwards for them.
                Maybe if someone replaced Gallium TGSI with their compiler IR they might take another look. I guess at this point we're down to hoping VMWare might do that, since the OSS devs are busy working on drivers and Intel isn't showing any interest.

                Comment


                • #38
                  Wow, so r600g is usable? The Gallium feature matrix indicates otherwise, but it hasn't been updated in a few months. http://xorg.freedesktop.org/wiki/GalliumStatus

                  Good work, graphics-stack programmers!

                  Comment


                  • #39
                    Originally posted by cb88 View Post
                    It run compiz quite well... but games appear severly CPU limited lol dunno if its in the game or the driver though.
                    I'm not sure about the r300 driver, but the r600+ drivers are quite CPU limited, and I think that r300g is too, at least at some things.

                    Comment


                    • #40
                      Originally posted by Wyatt View Post
                      Wow, so r600g is usable? The Gallium feature matrix indicates otherwise, but it hasn't been updated in a few months. http://xorg.freedesktop.org/wiki/GalliumStatus

                      Good work, graphics-stack programmers!
                      r600g is better at some things and worse at some things than r600c now, and most of the current effort is going into r600g.

                      r600g is faster, but less stable than r600c for me. I switch back and forth.

                      Comment


                      • #41
                        Yah.. r300g is still CPU limited at least to some extent. I'm only getting 10 or less FPS out of openarena on a 2xPII@300Mhz w/ radeon 9800 SE (not nearly as fast as the 9800 Pro but still respectible)

                        Course its common knowledge that openarena is quite CPU limited itself...

                        It might have improved some in the last month though.. since I checked

                        Are there any benchmarks/games that are severly GPU limited but light on the CPU I could try?

                        Comment


                        • #42
                          i read about CPU being the bottleneck (or one of) and i have to ask.

                          how come the blobs are not affected by it?? or is just that the other optimizations they have compensate for that??

                          Comment


                          • #43
                            Originally posted by 89c51 View Post
                            i read about CPU being the bottleneck (or one of) and i have to ask.

                            how come the blobs are not affected by it??
                            That's a wrong question. "It" doesn't exist as an entity. A bottleneck is not an entity that exists, it's just a behavior resulting from non-optimal code. Otherwise we would use bottleneck firewalls so that those evil bottlenecks are kept out :-P

                            The blobs are written with performance in mind. If they weren't, people would not buy the cards. The open source drivers and surrounding stack are not written with performance in mind. The developers struggle to make the stuff work as it is. Trying to match the performance of the blobs at the same time would probably mean that we would have to wait another 10 years for the drivers.

                            Comment


                            • #44
                              Originally posted by 89c51 View Post
                              i read about CPU being the bottleneck (or one of) and i have to ask.

                              how come the blobs are not affected by it?? or is just that the other optimizations they have compensate for that??
                              To clarify, the blobs are CPU limited on most of those tests as well. It's just that they are optimized to use less CPU and so perform much better. I suspect that in a shader heavy test the results might be closer together because it would rely more on the GPU and less on the CPU, but I really don't know if that's true or not. Michael's never really tried that kind of situation on any of these tests.

                              Comment


                              • #45
                                The binary drivers are also multi-threaded, which helps to hide CPU overhead *if* you have at least 2 cores.

                                Multithreading mostly helps when drawing is the bottleneck, however, but some of the initial profiling efforts suggest that state changes may be a bigger time sink than drawing right now. Not sure if that has been confirmed though.

                                Comment

                                Working...
                                X