Page 1 of 3 123 LastLast
Results 1 to 10 of 27

Thread: The Embedded Linux GPU Mess & How It Can Be Fixed

  1. #1
    Join Date
    Jan 2007
    Posts
    14,894

    Default The Embedded Linux GPU Mess & How It Can Be Fixed

    Phoronix: The Embedded Linux GPU Mess & How It Can Be Fixed

    Earlier this week Qualcomm released an open-source 2D/3D kernel driver for their Snapdragon SoC that's found within the Nexus One, Dell Streak, and many other mobile phones. However, it was just the kernel driver that leveraged their own driver design and no open-source user-space driver, which leads to a dirty mess. David Airlie, the DRM maintainer within the Linux kernel, will not accept open-source kernel drivers that is only used by a closed-source component and as such there's been a lengthy mailing list discussion over the past few days...

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

  2. #2
    Join Date
    Feb 2009
    Location
    Poland
    Posts
    72

    Default

    The best part of this blog post:

    (the cake is a lie)
    Portal tells the truth

  3. #3
    Join Date
    Dec 2008
    Posts
    82

    Default

    Unfortunately, all the "magic" is now in the software more than in the hardware... So the user space bits are what those companies want to keep secret.
    They may also use third party components for audio/video decoding, that they can't disclose.
    All in all, David is right, their must be some kind of "hero" in a company which has nothing to loose by playing totally the open-source game. Thus, a company delivering both competitive and free OpenGL(ES) stack with their drivers would have a key advantage on the embedded market, and may be a "game changer". This, I think, would force others companies to re-think their strategy.

  4. #4
    Join Date
    Jul 2007
    Posts
    404

    Default

    The thing that I think Airlie touches on here that is key is that these companies sell *hardware*. The drivers may contain magic voodoo, but it's magic voodoo written for *their* hardware. To the extent to which it *might* be used to benefit their competitors, if the various hardware manufacturers cooperate, they can all reduce their driver development overhead and spend more money developing better hardware.

    Hardware mfg's shouldn't be competing on software. Especially for an open-source OS. Build better hardware and give us support for it.

  5. #5
    Join Date
    Dec 2008
    Posts
    315

    Default

    I know. Why don't we try to make the entire world kiss your ass over your stupid little phone. I'm so sick of monopolists trying to get everybody in the world to kiss their ass because their stupid little phone is the "the chosen one".

  6. #6
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,463

    Default

    Quote Originally Posted by TechMage89 View Post
    The drivers may contain magic voodoo, but it's magic voodoo written for *their* hardware.
    You would be surprised how little of the magic voodoo is hardware specific. Quite a bit of the proprietary driver techniques would be portable to competitors hardware, and even more so to a new competitor who independently designed hardware that was architecturally similar to yours.

    Quote Originally Posted by TechMage89 View Post
    To the extent to which it *might* be used to benefit their competitors, if the various hardware manufacturers cooperate, they can all reduce their driver development overhead and spend more money developing better hardware.
    If all of the hardware vendors contribute fairly to the common development effort, that's true. The problem is that it also effectively funnels benefits from vendors who do contribute to vendors who do not (ie the ones who aren't spending much on R&D in the first place). I suspect all the vendors agree that allowing open source developers to program their hardware is a Good Thing - the challenge is making that possible without giving up too much of your hardware advantage. That said, it can be done (and IMO should be done); it's just not as easy as some of the claims suggest.

    Quote Originally Posted by TechMage89 View Post
    Hardware mfg's shouldn't be competing on software. Especially for an open-source OS. Build better hardware and give us support for it.
    Strictly speaking I don't think many hardware mfgs would agree with that. If you can give your hardware a competitive advantage via investing in software developoment it's not clear how removing that advantage and commoditizing the hardware benefits the hardware vendor.

    Again, I'm not saying that vendors shouldn't support open source driver development, just that many of the seemingly obvious arguments don't actually hold up when you look at them more closely. I still think opening up hardware is a Good Thing, but if you want to understand why you haven't seen the wholesale rush to open source driver support that those arguments predict it's good to try to see things from the hardware vendor's POV as well.

    Bottom line is that you need arguments which make sense to a hardware vendor. Making sense to everyone else is nice but doesn't get the hardware opened up. Dave's post seemed like a good step towards refining those arguments.

  7. #7
    Join Date
    May 2007
    Posts
    319

    Default

    Quote Originally Posted by bridgman View Post
    You would be surprised how little of the magic voodoo is hardware specific. Quite a bit of the proprietary driver techniques would be portable to competitors hardware, and even more so to a new competitor who independently designed hardware that was architecturally similar to yours.
    Like CPUs for example? we've had open compilers and java JIT for years it doesn't seem to have stalled development at all, in fact there is a lot more hw differentiation at things like power consumption and memory interfaces, things aren't as easy as just throwing together an ISA, porting gcc and selling the IP. I don't believe this for embedded GPUs. If someone is only doing small amounts of R&D it'll reflect more in the hardware than in the software. like I guarantee most of these vendors have rather shit shader compilers. They are competeing on power and price rather than throughput I expect.

    Dave

  8. #8
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,463

    Default

    It's a bit different in the CPU world because the API standard is still the instruction set, not a much higher level interface like DX or OpenGL. In the CPU world locking up the instruction set still makes a big difference. You may be right about hardware representing a bigger chunk of the secret sauce in the embedded space - I don't think that's the case in the PC market to the same extent though.

  9. #9
    Join Date
    Feb 2009
    Posts
    45

    Default

    Quote Originally Posted by bridgman View Post
    You would be surprised how little of the magic voodoo is hardware specific. Quite a bit of the proprietary driver techniques would be portable to competitors hardware, and even more so to a new competitor who independently designed hardware that was architecturally similar to yours.
    In that context, it has always surprised me a bit that both Mesa itself and most (all?) of the drivers are X11 licensed rather than something like LGPL.

  10. #10
    Join Date
    May 2007
    Posts
    319

    Default

    Quote Originally Posted by bridgman View Post
    It's a bit different in the CPU world because the API standard is still the instruction set, not a much higher level interface like DX or OpenGL. In the CPU world locking up the instruction set still makes a big difference. You may be right about hardware representing a bigger chunk of the secret sauce in the embedded space - I don't think that's the case in the PC market to the same extent though.
    The PC market isn't an indicator is this situation, the first point I made is that the PC market is all driven by Windows development, in the embedded space, Windows is to Linux, what Linux is to Windows in desktops, but they seem to be trying to enforce the same mindset.

    Dave.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •