Announcement

Collapse
No announcement yet.

When It Works, Intel Core i5 2500K Graphics On Linux Are Fast!

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

  • When It Works, Intel Core i5 2500K Graphics On Linux Are Fast!

    Phoronix: When It Works, Intel Core i5 2500K Graphics On Linux Are Fast!

    After a month of headaches for Intel and myself, there are now Sandy Bridge graphics benchmark results from the Intel Core i5 2500K under Linux to finally publish. Sandy Bridge was a tough launch for Intel in terms of the Linux coverage with the media having problems building a working driver stack and then when I finally got my hands on a CPU, I ran into an entirely different set of show-stopping problems. The developers still have not solved the biggest original issue yet, but Intel sent out a new motherboard and another CPU and it happens to "just work" nicely under Linux. When using the latest bits of their open-source Intel Linux graphics code, the performance on the Core i5 2500K is actually quite impressive compared to other open-source Linux drivers.

    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

  • #2
    Comparison with current-gen Intel IGP?

    Michael, would be great if you could do a comparison with current Core IronLake IGP to have a better idea what to expect when upgrading from current gen to SandyBridge.

    With my Core i7 920 (IronLake), I noticed a HUGE improvement between 4x and 10x in some GL apps after upgrading to Mesa-git compared to Mesa 7.9.

    Tip for mesa-git adventurers: if not building in /usr/lib, don't forget to set LIBGL_DRIVERS_PATH otherwise the older DRI driver will still get loaded by the newly built libGL (which works but do not give *that* big performance increase).

    Comment


    • #3
      How did you test integrated graphics with an ASUS P8P67-M PRO board? P67 has got no graphics support at all.

      Comment


      • #4
        Originally posted by Kano View Post
        How did you test integrated graphics with an ASUS P8P67-M PRO board? P67 has got no graphics support at all.
        Err P8PH67.
        Michael Larabel
        https://www.michaellarabel.com/

        Comment


        • #5
          That does not exist, maybe a P8H67-M PRO? Did you try booting via UEFI, that's what i would have done.

          Comment


          • #6
            Goodness. 12-self-referencing links in six consecutive paragraphs. This is a record to my knowledge, even for phoronix.

            Comment


            • #7
              Neat article. I'm not sure how to interpret the last (OpenBenchmarking.org) graph though.

              Comment


              • #8
                Originally posted by mattst88 View Post
                Neat article. I'm not sure how to interpret the last (OpenBenchmarking.org) graph though.
                Because there is nothing else like that on the net... It's just a tease till end of month when the heatmap to be explained
                Michael Larabel
                https://www.michaellarabel.com/

                Comment


                • #9
                  Originally posted by Michael View Post
                  Because there is nothing else like that on the net... It's just a tease till end of month when the heatmap to be explained
                  I'm sure there are lots of meaningless graphs on the net Michael

                  I'm almost sure this is showing where the performance is relative to other cards. If the red line is on the right does that mean it's the best card benchmarked?

                  Trying to figure out what the black lines mean though

                  Comment


                  • #10
                    Don't buy the Intel 6-series H67/P67 chipsets!

                    The problem occured in Intel?s 6-series H67/P67 chipsets that has two sets of SATA ports. One set handles four 3 Gbit/s drives and the other works with a pair of 6 Gbit/s drives. The transistor of concern is located in the PLL (phase lock loop) clock tree of the 3 Gbit/s controller. The circuit was biased at too high a voltage for the design and this resulted in an excessively high leakage current. This in turn changes the system's characteristics and causes the controller to fail. The other controller is unaffected as well as it has its own PLL.

                    Comment

                    Working...
                    X