Announcement

Collapse
No announcement yet.

Intel's Linux Sandy Bridge Graphics Still Troubling

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

  • #11
    Originally posted by allquixotic View Post
    This is not news. I have tried various Nvidia, ATI and Intel open source drivers since 2007 -- everything from i915 to i965, nouveau, r600{c,g}, etc.
    I'm sorry you've had this experience, but it's certainly at odds with the reports we receive. The major distros typically ship feature rich and stable open source graphics drivers. For Intel, I can even say they ship support for the very newest hardware in most cases (sometimes they even support hardware that hasn't been released yet).

    That's not to say we don't have bugs, everyone does, and some of ours take longer than I'd like to get resolved (mine included). However, I tend to be a pretty harsh judge; every now and then I boot up Windows or use a vendor or binary driver and I suddenly feel much better about the quality of ours. I think we stack up fairly well against the competition, both hardware and software.

    Comment


    • #12
      Originally posted by jbarnes View Post
      every now and then I boot up Windows or use a vendor or binary driver and I suddenly feel much better about the quality of ours.
      Uhh... maybe you missed the news the last couple days?

      And ++ on Phoronix using the WebM compatible method for youtube embedding - I have no Flash and can't see anything here.

      And if Phoronix want's to be really nice, how about providing the set of instructions to walk us through the steps to build/install Sandy Bridge graphics support

      Comment


      • #13
        Hey, look what I found: http://www.lostcircuits.com/mambo//i...&limitstart=15

        It looks like OpenGL support isn't up to speed on Windows either.

        Comment


        • #14
          Originally posted by jbarnes View Post
          I'm sorry you've had this experience, but it's certainly at odds with the reports we receive. The major distros typically ship feature rich and stable open source graphics drivers.

          That's not to say we don't have bugs, everyone does, and some of ours take longer than I'd like to get resolved (mine included). However, I tend to be a pretty harsh judge; every now and then I boot up Windows or use a vendor or binary driver and I suddenly feel much better about the quality of ours. I think we stack up fairly well against the competition, both hardware and software.
          oh hi Jesse , nice to see you here
          (aka one of the [email protected] dev's in-case readers hubick etc didn't know)

          as regards "For Intel, I can even say they ship support for the very newest hardware in most cases (sometimes they even support hardware that hasn't been released yet)."

          what idea's do you have to help bring Intel’s Quick Sync Encode/decode ASIC to general linux use ?

          for instance have you had contact with Francois Piednoel (the Senior Performance analyst at Intel) that stated elsewhere he was writing a low level patch for x264 use (still unreleased as yet) and was looking for help defining its API and potential Linux use too.



          "October 16, 2010,Francois Piednoel:I am looking for one or few of the software Architects of x264 to help me to define the API we can agree on"

          " For Most of the world, SandyBridge acceleration will be accessable through mediaSDK , because it is the easiest way to do it.

          After taking with Loren, one thing was very clear, He was totally clear that the x264 community would not include a call to a DLL without any control of the encoding process. I understood his point, and toke on myself to go and try to get the autorization to turn around MEdiaSDK and give you guys direct access (That mean to the world) to the Magic of SandyBridge. Trust me, i got a lot of heat out of it."

          it seems he's a little flaky and didn't manage to release the code patch as promised in a timely manor so far, but perhaps the intel-gfx Intel dev's can perhaps get a better response time from him than the x264 devs on IRC did, and get functioning Encode/Decode and that low level API for Linux inclusion sooner.

          Comment


          • #15
            Originally posted by popper View Post
            what idea's do you have to help bring Intel?s Quick Sync Encode/decode ASIC to general linux use ?
            I don't know about Francois, but our team is definitely working on it, keep an eye on the mailing list for patches and status updates.

            Comment


            • #16
              This article made me feel a lot better about dropping the dough to fully update my current geforce 7050 based htpc instead of building a new machine based on SB. A phenom 9450e should be powerful enough for just about any sane use of an htpc anyway, and coupled with a 240gt w/ ddr5 it'll probably be faster for rendering/3d use despite the major disadvantage in processing power. Coupled with additional ram, a new SSD drive, and a 2250 dual encoder card to go with the 1600 currently in it and I should be good for a while.

              One of the reasons I was upset with intel and decided against building a SB htpc was the whole overclocking/h67/K-series integrated graphics debaucle. Ironically enough, the new phenom won't overclock for anything in this am2 board :| 2.5% above stock is the worst overclock I've had probably ever--I wish my bios would allow me to undervolt the thing. It's still benchmarking 20-40% higher on singled threaded applications than the x2 it's replacing which was running 400mhz faster.

              Comment


              • #17
                Sounds like SB will make a worthy upgrade for my Pentium 3 1.13

                Comment


                • #18
                  If it's GCC that is bailing on you I'd double check and make sure your not having memory issues on that system. That is the only time I've ever had GCC segfault at different points during a compile and it's a very common sign of memory corruption.

                  BTW, while I do not doubt that SB drivers suck at this point I have to say that I've been very pleased with the performance of my GMA x3100 under Linux. It's not fast and it's bad for games, but I can run my 3360x1980 with compiz under Ubuntu 10.10 with no sweat and has no problem playing back 1080 HDTV video that is encoded in lighter-then-H.264 formats, although with H.264 I only bother with 720p.

                  It's stable, power management works out of the box, and I did not extend a single finger to get it configured properly.

                  The only thing I want is that Intel focus more on Gallium instead of ignoring it completely. Gallium is the bomb and is why I am looking strongly at ATI.

                  I may get a SB board to upgrade to a ATI graphics card later on.

                  Comment


                  • #19
                    Originally posted by phoronix View Post
                    Phoronix: Intel's Linux Sandy Bridge Graphics Still Troubling
                    I have had none of the problems mentioned in this article. I wonder if the author has made some mistake with the build of X in some way.

                    I have an i5-2500K cpu on an asus p8h67-m pro motherboard with 8gb of ram.

                    using ubuntu maverick, there is no need to compile a newer intel Xorg driver. Just use the xorg-edgers ppa - all the hard work done for you - including a kernel 2.6.37.

                    Code:
                    sudo apt-add-repository ppa:xorg-edgers/ppa
                    sudo apt-get update
                    sudo apt-get upgrade
                    Compiz was a slight annoyance since the blacklist is compiled in, but it didn't take long to fix. to save some time, you can just download the modified maverick compiz from my ppa.

                    Code:
                    sudo apt-add-repository ppa:jools/sandybridge
                    sudo apt-get update
                    sudo apt-get upgrade
                    Compiz seems to be working mostly fine. Had a few minor graphical glitches with areas of the screen not being upated properly, but only happened once or twice, and no crashes.

                    i can run nexuiz fine at 1920x1080. no crashes (although it was only 30fps or so, but i didnt tweak any settings apart from resoluton)
                    openarea also worked, no glitches or crashes.
                    compiling a kernel with -j5 etc was also no problem.

                    this article does seem to spread a little fear to anyone thinking to upgrade, which is unfortunate, and I would recommend the author to perhaps have another as something certainly wasn't quite right with his setup.

                    I'm happy to test any software if someone is interested to know how it runs. I've been very please so far with the setup. The only thing not currently working is the machine doesn't wake up correctly from being suspended. But I can live without suspend for now.

                    Comment


                    • #20
                      hubick: yes I've definitely seen the articles, however one beta piece of software with new code is hardly reason to condemn the whole driver stack. There's a productive discussion already underway on the mesa list, and it looks like there's plenty of blame to go around (bugs in firefox, mesa, drivers). That often happens when an app runs through hitherto infrequently used code paths. Keep in mind that lots of games and apps run fine, so again I wouldn't say the driver stack as a whole is in bad shape, in fact I'd say it's pretty good (certainly better than ever).

                      drag & buzz, yeah that's what I'm thinking too. I've been talking with Michael over the last couple of days over irc, and it really feels like a system level issue of some kind, as opposed to driver bugs. But we'll narrow it down and figure things out one way or another.

                      As for Gallium, I agree it has some useful features and could save us some trouble, but don't get confused about it; it doesn't have inherently better performance than the classic drivers (in fact it adds some abstraction that could add overhead in some cases), it's mainly about making driver writing easier and sharing code for new features and APIs. So from a user's perspective it doesn't really matter if a driver uses Gallium internally or not, unless there's a specific feature that Gallium provides that your driver doesn't have (but even then there's nothing preventing your driver from adding that feature w/o moving to Gallium). Some of our developers are pretty convinced we can do a higher performance driver without Gallium, but of course it's hard to compare unless you have good classic and Gallium drivers for the same chip...

                      Comment

                      Working...
                      X