Announcement

Collapse
No announcement yet.

Intel's Special Driver For Poulsbo Uses Gallium3D

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

  • Intel's Special Driver For Poulsbo Uses Gallium3D

    Phoronix: Intel's Special Driver For Poulsbo Uses Gallium3D

    Yesterday afternoon we ran a story on a new Linux driver for the Intel Poulsbo chipset, which right now is known for being notorious with its troubling Linux support. However, Intel apparently had been working on a new "special driver" that the Linux Foundation was showing off recently in Munich at a mobile development camp...

    http://www.phoronix.com/vr.php?view=NzY2Mg

  • #2
    bam! that's very interesting. and it's funny to see that they use TTM instead of GEM.

    it's an interesting mix of closed and open source software. too bad that it can't be 100% open source.

    Comment


    • #3
      SoC support

      If this works with Sodaville, does this mean it'll work for Sodaville's predecessor, Canmore? Canmore also has a Poulsbo integrated in the SoC.

      Comment


      • #4
        That would have been excellent news if the Gallium3D driver wouldn't be closed source. But it's still better than a fully closed source stack.

        Comment


        • #5
          I'm just happy if I finally have a working driver!!!

          The netbook they used looked like an MSI U110, which currently does not work at all with Linux poulsbo drivers as far as I've tried it...

          Comment


          • #6
            Wait. Correct me if I'm wrong, but if the new driver uses Gallium3D, that would mean all calls from the closed driver will pass through the open Gallium3D layer...

            So doesn't that mean that it would be quite easy to trace exactly what the closed source driver is doing and then create an open source driver that does the same?

            Luke.

            Comment


            • #7
              The new DRM code, which the developers will be working on merging upstream soon (after a failed attempt with their older code),
              I just hope it will not be accepted ... VIA tried the same and it wasn't accepted or was it in the end ?

              Anyway a year ago I said somewhere on those forums that intel is the number one as far as open drivers go and AMD/ATI is second (and nvidia non existant ) Right now though AMD/ATI is IMHO the number one. The poulsbo mess moves intel to a second place.

              Comment


              • #8
                Originally posted by Kazade View Post
                Wait. Correct me if I'm wrong, but if the new driver uses Gallium3D, that would mean all calls from the closed driver will pass through the open Gallium3D layer...

                So doesn't that mean that it would be quite easy to trace exactly what the closed source driver is doing and then create an open source driver that does the same?

                Luke.
                I think that's the idea. PowerVR are being jerks, so Intel have given them what they want in a way that completely undermines them.

                Comment


                • #9
                  Originally posted by Ant P. View Post
                  I think that's the idea. PowerVR are being jerks, so Intel have given them what they want in a way that completely undermines them.
                  I'd concur...but don't make the rumblings of that TOO loud.

                  If something does come of it, it'd be nice to have FOSS drivers for the OMAP3...

                  Comment


                  • #10
                    Originally posted by Svartalf View Post
                    I'd concur...but don't make the rumblings of that TOO loud.

                    Agreed. There's no reason a debug version of mesa couldn't be used to create an open-source version of this driver, and Intel very well knows this... but as you said, mum's the word. Except that it's already been posted publicly...

                    On the other hand, I'm really glad to see usable 3D acceleration, and in addition to video acceleration, for PowerVR chips in Linux. I could definitely see a future use for a mini-ITX atom/arm + powervr board as a mythtv front end, especially if there's full video decode acceleration. The power use should be fantastic, and it might still have enough performance for NES/SNES emulation (dare I hope for N64?).

                    Comment


                    • #11
                      They could just as well fork Mesa into that 3D support blob as well, making it impossible to trace Gallium3D calls, couldn't they? That's at least how I understand Mesa's MIT license.

                      Comment


                      • #12
                        the closed-source component, which is the Gallium3D code to provide some fast OpenGL acceleration

                        Why is it that the really useful stuff is never open source?

                        Comment


                        • #13
                          this news about blob-thing sucking from "new api for easy and simple driver implementation" is a very very disturbing.

                          bad tendency.

                          even whole "GEM except TTM, UXA instead EXA, overcomplicated stuff over 'modesetting_drv'\Gallium" wasn't cheering at all...

                          Comment


                          • #14
                            This is not as cool as you might think.

                            First, this driver uses an older Gallium API, probably version 0.1, so most of the current tools and state trackers won't magically work until it's updated.

                            Second, although dumping Gallium calls is a very easy trick due to trace and rbug, it doesn't help since those calls are one level above the closed-source layer. Since the DRM is open-source, however, you could definitely just use a trivial state tracker like python or dri to dump tiny bits of state, revenge-style, out of DRM, and build a reverse-engineered driver that way.

                            Third, Imagination has historically been absolutely horrible about code licensing terms, and I for one will not be surprised if this code includes the same "I agree to not reverse-engineer this shit for any reason" clause as the license that came with their GLES blob for OMAP3xxx chipsets. I was part of a team last year (the OSWALD project) that wanted to use SGX code and the team ended up shipping no 3D at all because of the licensing conditions. You may note that TG/VMWare has been sitting on this code for a while, and that's because Imagination's a company that really just doesn't like the open-source community.

                            ~ C.

                            Comment


                            • #15
                              Just when I thought Intel was becoming less evil!

                              Comment

                              Working...
                              X