Announcement

Collapse
No announcement yet.

Intel Linux Graphics On Ubuntu Still Flaky

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

  • #31
    Originally posted by mtippett View Post
    Profiling is for developers, benchmarking is for users.

    Benchmarking determines a macro issue that needs attention [...]
    Picking the wrong benchmarks you can prove anything. My point was clear from the beginning and you try to argue.

    Originally posted by mtippett View Post
    As has been mentioned before, if people are concerned about the quality or correctness of the benchmarks themselves, by all means, invest the effort into getting cairo-perf-trace into PTS.
    As I pointed out already: It's not a question of PTS itself, but the chosen benchmarks.

    PTS puts to much emphasis on the number of benchmarks they include:
    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

    Your posting confirms this: "Give me cairo-perf-trace ..."

    Originally posted by mtippett View Post
    What does happen though is the parties that are implicated by the performance issue actually begin to communicate
    If phoronix would be testing the remaining ~ 100 - 3 = 97 PTS benchmarks and would file a bug report for each of them, we would have even more discussion.

    I appreciate digging out performance issues! But given that there are only 12 people working on intel drivers:

    we should really stick to relevant ones. Phoronix has a great visibility and with that visibility comes repsonsibility.

    Comment


    • #32
      Nice to see some progress even if I don't have an Intel IGP.
      Hope the ati drivers will mature faster because the RS690M is no longer supported by Catalyst drivers. I want to go on with my old savegames.

      Comment


      • #33
        I think Michael just had a bad netbook. I tested Padman, Urban Terror and Tremulous without issue on my netbook. 9.10 Alpha 3 is already a big improvement over 9.04. Results are here:

        Comment


        • #34
          Originally posted by 7oby View Post
          Picking the wrong benchmarks you can prove anything. My point was clear from the beginning and you try to argue.
          However, at least the JXRenderMark tests were developed to emulate common paths of Java2D's XRender pipeline.
          So you are right, JXRenderMark is a microbenchmark, however it was been designed to mimik real-world behaviour of real-world to allow driver developers to optimize their drivers for some piece of real software.
          Thats why a large GPU manufacturer uses it for nightly regression testing.

          The problem is this:
          If you report a performance bug against a large piece of software, they won't listen because they don't want to investigate it on their own. If you write small benchmarks you are ignored, because thats only microbenchmarks.
          Some JXRenderMark tests show a horrible regression, e.g. scanline based rendering got 50% slower.
          So if your app is not cairo based *caught, caught*, you are out of luck!

          After all, I don't consider a driver mature which requires a syscall + GPU stall per XPutImage!


          > I appreciate digging out performance issues! But given that there are only 12 people working on intel drivers
          I don't know any other oss driver, which has 12 full time working on it.

          - Clemens
          Last edited by Linuxhippy; 03 August 2009, 07:36 AM.

          Comment


          • #35
            Originally posted by Linuxhippy View Post
            However, at least the JXRenderMark tests were developed to emulate common paths of Java2D's XRender pipeline.
            So you are right, JXRenderMark is a microbenchmark, however it was been designed to mimik real-world behaviour of real-world to allow driver developers to optimize their drivers for some piece of real software.
            I agree with aspects of this post.

            A suitable analogy is that of a big city. You can look at the macro effeciency of the city's ability to move people around, or to a particular event - this is like a "real world" benchmark. You can then profile different control points to determine if there is some part of the urban planning (the architecture) that is flawed for a particular traffic flow.

            To "manage" the urban traffic flow almost every city puts in traffic flow information around traffic lights as well as on the major traffic paths ("known choke points" and "common code paths").

            Ideally these paths allow characterization of the bigger problems and if you keep traffic flowing at these check points you can generally keep the city flowing nicely.

            Now of course, the difficulty is choosing the check points that represent the common traffic (or performance) conditions that will affect real world usage.

            A second issue to consider is relevance of the benchmarks. x11perf - in it's day was a great tool for analyzing the entire Xlib path. There were stippled lines, ellipses and everything that the athena toolkit used on a regular basis, so if you had a performance issue reported, you could contrast old x11perf results agains new results. Most likely in any given performance issue, there was a particular test that lay fair and square on the active path for the performance issue.

            Most developers have neither the time, nor the interest to create a test app that covers the large proportion of their API. Consequently we start moving out to large applications and hoping to benchmark them. To benchmark them you need either a higher level benchmark framework to capture a profile, or you need intrinsic benchmarkability somewhere in the pipe.

            You still end up creating a representative benchmark for a particular application flow. If you as a user don't have the same usage pattern similar to the "real world application" benchmark, you basically out of luck. Likewise, if the application changes and the benchmark isn't updated, you may be tuning for the wrong thing.

            A great example of this is Wine. They have switched recently to using RENDER for doing most of their display compositing. If a representative benchmark doesn't include RENDER, then the real-world benchmark isn't worth anything anymore. *BUT*, you will know that a micro-benchmark (such as, say, JXRenderMark), will probably give you an indication of the RENDER performance.

            Each has their place, but something is better than nothing.

            The problem is this:
            If you report a performance bug against a large piece of software, they won't listen because they don't want to investigate it on their own. If you write small benchmarks you are ignored, because thats only microbenchmarks.
            Some JXRenderMark tests show a horrible regression, e.g. scanline based rendering got 50% slower.
            So if your app is not cairo based *caught, caught*, you are out of luck!

            ...
            Another great point.

            I proxy a large number of issues into AMD. When an issue gets my attention and begins to move into the driver team, I generally refuse to bring in a either a macro benchmark or a monolithic application.

            I ask for either a representative benchmark of the bottleneck they are expecting, or I ask for a reduced test case that demonstrates the problem.

            Most developers are aware of the behaviour of their code, and what happens under different work loads. Unsurprisingly, due to their understanding of the code getting the above doesn't cause too many issues. We typically get a smaller test-case demonstrating some problem or we get pointed to other micro-benchmarks that can serve as a proxy.

            Thanks for the great points.

            Comment


            • #36
              Originally posted by Linuxhippy View Post
              However, at least the JXRenderMark tests were developed to emulate common paths of Java2D's XRender pipeline.
              I appreciate the Java XRender effort and the posted benchmark as well.

              It seems the general user or at least I will not profit from it:

              . requires "-Dsun.java2d.xrender=True" launch option, which only very few people are aware of and know how to enable. Definitely not the out-of-the-box experience - besides possible visual corruption bugs.

              . The only major java app that I use is Eclipse, which is based on SWT for GTK+ and though GTK+ uses XRender I don't know whether there's an intersection of the functions used by GTK+ and JXRender Benchmark.

              . Most java apps that I write are headless server apps and backend components. However I once wrote an application for a digital astronomical camera, which made heavy use of Java2D and in particular "BufferedImage" to store and manipulate 16-bit grayscale images (histograms, gamma corrections, zooming). However: "BufferedImageOps are not accalerated because XRender does not provide functionality required to accalerate those features."

              Seems I currently don't have a use case for XRender performance for me. But as I said: The effort itself is very valuable.

              --

              To determine whether Ubuntu Y.X has regressed or improved user performance I suggest four benchmarks measuring

              . compiz
              . firefox
              . Adobe flash
              . one OpenGL based game

              performance. I also appreciate micro benchmarks, but meaningful ones. Even using 2560 x 1600 displays I can't image of an application that is limited by GTK Radio Button rendering performance, but I immediately recognize if scrolling performance degrades. I don't know whether the latter is included in one of the low level benchmarks.

              Storage Review provides a very clear explanation of their testing methodology:

              You learn what each micro benchmark measures and how to judge whether this particular aspect matters to you or not.

              Maybe phoronix can provide something like this and we start a DISCUSSION about which tests to include for reviews.
              Last edited by 7oby; 05 August 2009, 03:27 AM.

              Comment


              • #38
                God, that's horrible performance

                Comment


                • #39
                  Originally posted by combuster View Post
                  Me too. Similar hardware should yield similar results.

                  So, people that use the new driver and kernel don't have proof that the results are wrong, but their experience says they're wrong.

                  Now, we have someone with the same type hardware fail to reproduce the results. Puzzling....

                  Comment


                  • #40
                    Unreal Tournament 2004 -
                    800x600 it's ok. Playable.
                    1024x768 it starts stuttering.
                    1280x1024 forget it.
                    ---------------------------------
                    Glxgears -
                    800 -> 1100 fps sometimes 24000 fps <-- weird
                    ----------------------------------
                    Nexuiz - awful but manages
                    ----------------------------------
                    Blender 3D latest
                    trash
                    ----------------------------------
                    KMS has some quirks. External LCD's suffer.
                    Kernel Mode Setting.
                    ----------------------------------
                    I own a few games and I've run a few tests and I'm sick of hearing about performance improvements from the Intel developers. They need to shut up and fix this. No more announcements until it's fixed.

                    Ubuntu needs to back port fixes!
                    ----------------------------------------------------

                    http://anholt.livejournal.com/41306.html yeah right

                    Intel right now sucks on every distrubution.

                    Comment

                    Working...
                    X