Announcement

Collapse
No announcement yet.

At Least Intel Admits They Have Too Many Drivers

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

  • At Least Intel Admits They Have Too Many Drivers

    Phoronix: At Least Intel Admits They Have Too Many Drivers

    Yesterday we found it interesting that Intel is not even able to ship their own Linux driver for their own hardware with their MeeGo operating system. The driver in question is their new EMGD driver for the Menlow and Tunnel Creek platforms that have a graphics core that's designed by Imagination Technologies rather than their own in-house intellectual property. The EMGD driver from Intel currently requires signing a Non-Disclosure Agreement with them to gain access to this driver, but it's not the only driver available that targets the Intel GMA 500 / GMA 600 graphics core that's derived from the Imagination Technologies PowerVR SGX 535...

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

  • #2
    FYI: I'm not actually a meego user... I'm only interested in meego as far as the potential for it to help get some kind of driver for gma500. I actually run Fedora 13 on my poulsbo tablet/netbook, and it just happens that meego lines up pretty good with Fedora 13.

    Comment


    • #3
      The bigger the corporation the more likely the lack of synergy to show up.

      Comment


      • #4
        Intel could just buy ImgTec and release specs.

        Comment


        • #5
          Originally posted by Adarion View Post
          Intel could just buy ImgTec and release specs.
          If only...

          I wonder if Intel's management realize just what they've lost. The Linux community will not be quick to trust them again.

          Comment


          • #6
            Originally posted by Adarion View Post
            Intel could just buy ImgTec and release specs.
            well ImgTec did not write the drivers Tungsten Graphics did

            here is a thread about it in imtec forum http://www.imgtec.com/forum/forum_posts.asp?TID=610#top
            Imagination licences a core to a customer (such as Intel) so that they can make a product. The customer then decides how to support this product and what will be supported on it. Different customers want different levels of involvement from Imagination to provide drivers for their product and to deliver these drivers to end users. In this case, Intel have chosen to control distribution of drivers themselves which means that Imagination don't distribute the drivers - I can't give you any. If there are none available from Intel then you should take this up with them.

            The agreements concerning how drivers are written, for which platforms and who writes them etc. are confidential and not something I can talk about on this forum.

            This issue is something we're aware of, have discussed and something I've even investigated myself so I appreciate your frustration and will pass on your concerns. I can't help more than that, I'm afraid.

            Comment


            • #7
              I got this feeling that Intel could not have got the next core done in time so this Poulsbo disaster is just a nasty quick interim solution. Or maybe their own team is too busy helping out the CPU crew to get shader cores into the 'CGPU'...

              It seems stupid for Intel to not create their own shit...

              Comment


              • #8
                Originally posted by V!NCENT View Post
                I got this feeling that Intel could not have got the next core done in time so this Poulsbo disaster is just a nasty quick interim solution. Or maybe their own team is too busy helping out the CPU crew to get shader cores into the 'CGPU'...

                It seems stupid for Intel to not create their own shit...
                Indeed Intel is lagging behind in terms of power efficiency when compared to ARM SoC's. They'll probably be able to lower power, but it seems wiser to first concentrate on CPU, and then attack GPU, than to try to attack both targets at the same time. I guess we'll have to wait and see what happens

                Comment


                • #9
                  Originally posted by ldesnogu View Post
                  Indeed Intel is lagging behind in terms of power efficiency when compared to ARM SoC's. They'll probably be able to lower power, but it seems wiser to first concentrate on CPU, and then attack GPU, than to try to attack both targets at the same time. I guess we'll have to wait and see what happens
                  Bullshit. They use the same GPU and VPU cores... As for the TDP of the SoC, it's more like a marketing hype. Intel gives number for the whole SoC. Some other people only give out numbers for the ARM CPU core.

                  As for the drivers, yes, Intel does write their own. And yes, the various Intel divisions probably don't share the same code. If true, this indeed is a stupid waste of resources.

                  Comment


                  • #10
                    Originally posted by gbeauche View Post
                    Bullshit. They use the same GPU and VPU cores... As for the TDP of the SoC, it's more like a marketing hype. Intel gives number for the whole SoC. Some other people only give out numbers for the ARM CPU core.
                    Oh really? So Moorestown is more/as power-efficient as a similar ARM-based SoC? And the same applies to non Imagination-based Intel chips? Especially as Moorestown is a two-chip solution (Lincroft + Langwell pair).

                    I've never trusted marketing hype, but I'm fairly certain that Intel SoC's still need more power than a similar ARM SoC. I'm also sure Intel will catch up.

                    As for the drivers, yes, Intel does write their own. And yes, the various Intel divisions probably don't share the same code. If true, this indeed is a stupid waste of resources.
                    They even write drivers for SGX chips? Or do they only add some layer to an existing driver provided by Imagination? Anyway that alas wouldn't change anything to the issue of NDA and multiple drivers.

                    Comment


                    • #11
                      The part that is really confusing in this whole mess is JUST WHO is writing all the different drivers?

                      If it is INTEL writing all the drivers, then they could release the source just fine.

                      If it is TUNGSTEN writing all the drivers, then if THEY had a brain, then all the different drivers are actually the SAME DRIVER with a little glue that was written by INTEL, in which case intel could at least release the GLUE.

                      Either way, intel can release SOMETHING. Especially now since they HAVE released at least THREE sets of binaries and two sets of glue.... psb (inc. glue), iegd (inc. glue), and pvr (for "PowerVR", not "Personal Video Recorder" --- no glue). Now once again, EMGD is supposed to come with glue, which is good, but this NDA nonsense is B.S. HOW EXACTLY can anyone justify the cost of developing a driver that NOBODY CAN USE??!??!?!?!? Frikkin retarded is what it is.

                      Comment


                      • #12
                        Just a note for anyone running FEDORA... there are now psb driver packages on rpmfusion-nonfree-updates-testing that are compatible with xserver 1.8 and kernel 2.6.33 -- this is thanks to Adam Will of Fedora (hobby work, NOT official), and several other people who work mostly on ubuntu.

                        Comment


                        • #13
                          With NDAs and specs, anyone can write a driver for a particular chip, however, you can't release what you've written unless the owner of the IP says you can. The owner of the IP can also make restrictions on redistribution even if it is in binary form.

                          Comment


                          • #14
                            Originally posted by agd5f View Post
                            With NDAs and specs, anyone can write a driver for a particular chip, however, you can't release what you've written unless the owner of the IP says you can. The owner of the IP can also make restrictions on redistribution even if it is in binary form.
                            IF they changed the blob enough that the glue would require any additional IP compared to the glue that they *already* released. Which I suppose is possible, but very badly though out. Not that ANY PART of intel's operation appears to be reasonably thought out

                            In fact, under the NDA's, Intel actually does have the full source code for all of the different SGX drivers applicable to hardware they sell... which means that they *could*/*should* arrange the blob portion such that it doesn't require any additional IP to be opened than what already is.

                            As for the restriction on redistribution in binary form... obviously that is true, but don't intel's lawyers actually read the stuff before agreeing to these things? It really makes no sense to agree to NDA's that prevent you from ever making any kind of use of the IP.... and evidently the PVR driver blob DID pass the requirements since it HAS been released.

                            Oh well.
                            At least we've got the old psb driver working with xserver 1.8 now... that's enough to satisfy me and probably the vast majority of others. Trying to figure out what intel is thinking is a real exercise in hair loss.

                            Comment


                            • #15
                              Note: as sad as the state of PSB appears to be, at least its better than nvidia. We've got a big enough part of the xorg driver code to be able to adapt it to newer version of the xserver.

                              Comment

                              Working...
                              X