Announcement

Collapse
No announcement yet.

Is Windows 7 Actually Faster Than Ubuntu 10.04?

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

  • #81
    Originally posted by haplo602 View Post
    I see that deanjo is the only resonable person here ....

    GL vs GL benchmarks are only one (and minor) part of graphics performance in Ubuntu vs W7 ... If we don't get DX vs GL comparisons, it's meaningless. Come on ... the majority (I meant 99%) of W7 graphics will run DX (9,10,11) so the tests should include that as well. I'd propose the Unigine tests to be run with correspinding GL/DX profiles (9/10 vs 3.x and 11 vs 4.0 when available). Only then we will see the true picture.

    I guess the misc tests will be fine for the most part.
    Actually, there is little point in that. D3D is known to lead GL by about 10% (plus or minus a few percent) in recent versions of Windows. There are outliers, but that is what it boils down to.

    Comment


    • #82
      What I was usually experiencing games under Linux are more CPU dependent then on Windows. In example, UT2k4 was smoother on Windows then on Linux when there were many objects visible and replacing CPU always helped.

      Comment


      • #83
        I've been trying to decide whether to choose Windows 7 or Ubuntu 10.4 as an operating system for my new PC. It's good that I came upon this thread and I got some good ideas. Thanks for helping me make the choice. Now, I can decide but I won't reveal it.
        ________________

        Comment


        • #84
          When in doubt, you can always dual-boot

          Comment


          • #85
            Thank you Michael for all the effort you spend to provide tools and articles allowing us to make a point about the current status of Linux. The syllogism is quite simple: Since windows is a good game platform and Linux beats Windows in a lot of tests then Linux is a good gaming platform too!

            I'm not dissatisfied about the results. I recall that a few years ago it was impossibile even to think about gaming on Linux. Now we have benchmarks that prove that not only this is technically possibile but might even become a reality considering that Steam is around the corner.

            Comment


            • #86
              Originally posted by BlackStar View Post
              Actually, there is little point in that. D3D is known to lead GL by about 10% (plus or minus a few percent) in recent versions of Windows. There are outliers, but that is what it boils down to.
              not quite true. the difference is the engine optimisation for DX or GL, also the drivers for DX have tweaks for various games/engines that GL drivers lack. so the overall experience will differ more than 10%.

              getting unigine running in DX11 vs GL4 and then comparing to linux GL4, I think there could be some telling differencies ...

              Comment


              • #87
                Originally posted by haplo602 View Post
                not quite true. the difference is the engine optimisation for DX or GL, also the drivers for DX have tweaks for various games/engines that GL drivers lack. so the overall experience will differ more than 10%.

                getting unigine running in DX11 vs GL4 and then comparing to linux GL4, I think there could be some telling differencies ...
                I'd wager that if you are seeing larger than 10% differences running the same code on D3D vs GL, then either the engine is badly written or you are hitting a driver bug. This 10% figure is sometheing I've seen come up relatively frenquently on opengl.org forums.

                The major problem of OpenGL is not its performance but something rather more fundamental: it's the subpar, legacy-ridden API design that is rooted firmly in the '90s. The rest of its problems (driver instability and feature disparity) stem primarily from that.

                Comment


                • #88
                  Originally posted by BlackStar View Post
                  The major problem of OpenGL is not its performance but something rather more fundamental: it's the subpar, legacy-ridden API design that is rooted firmly in the '90s. The rest of its problems (driver instability and feature disparity) stem primarily from that.
                  And that's FUD. That 90s design has been removed from the API. If you don't load the compatibility extension, you won't even be able to use it.

                  Comment


                  • #89
                    I notice dramatic differences in performance of the ATI Catalyst Linux driver on Ubuntu depending on whether compositing is enabled or disabled. For instance, with compositing disabled, 2D performance of the Catalyst driver is as sluggish as the open source Intel driver was in 2007! It takes up to a second for each refresh of scrolling the window in Chrome. I notice a similar tanking of FPS in 3d games without compositing. It seems that the Catalyst Linux driver is only competitive with compositing *enabled*, which you'd think would actually decrease performance, but due to the architecture of the graphics system, it actually makes everything way faster.

                    Since I haven't installed Ubuntu 10.04 LTS and tried the default desktop with the video cards you're using, I'd be interested to know whether or not compositing was enabled when you conducted these tests. Please advise.

                    Oh, and the same applies for Windows 7 -- except that I've noticed Win7 compositing tends to hurt 3d performance slightly. The difference between Aero and stacked window manager is less dramatic on Windows though.

                    Comment


                    • #90
                      Originally posted by Remco View Post
                      And that's FUD. That 90s design has been removed from the API. If you don't load the compatibility extension, you won't even be able to use it.
                      You are mixing up API functionality with API design. Please don't, they are not the same thing: OpenGL 3.3/4.0 is modern in functionality but legacy-ridden in design. The original OpenGL 3.0 proposal would have fixed both issues in one go but the design was scrapped as too ambitious. The resulting spec only fixed 50% of the issue (functionality), leaving the broken design intact.

                      Why is the design broken? Because it forces you to either stall the pipeline or aggressively reset state for every single operation. Want to stream in model data without disrupting rendering? You have to save the current array object binding (introducing a stall), bind the new array object, stream the data and finally restore the original array object. Same thing for element array objects, vertex array objects, textures, renderbuffers, framebuffers, pixel buffers and programs, multiplied by the number of middleware libraries you are currently using (want to use a 3d model loader? Maybe a text renderer or a UI library? Better save all your state because they might trample everything).

                      None of this should be necessary in a modern API. None of this is necessary in Direct3d.

                      Just take a look at the suggestion thread for OpenGL n+1. Direct state access is in nearly every single post there.

                      Comment

                      Working...
                      X