Page 3 of 3 FirstFirst 123
Results 21 to 27 of 27

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

  1. #21
    Join Date
    Jun 2010
    Posts
    10

    Default

    Quote Originally Posted by bridgman View Post
    I don't get this part at all. Graphics has changed so much in the last 10-20 years that driver techniques from that time are pretty much irrelevent.



    Other than a few "look Mom, I can use SIMD instructions to make video go really fast" papers I haven't seen much at all in terms of publicly available research on graphics driver implementation. There's a larger body of work on GPU compute but again that has very little to do with driver implementation.
    The nice thing about having changed so much in the ways they have changed, and starting from scratch at this point in time, you get to skip the foreplay of the intervening years. It is possible to dredge stuff up from other areas of computing and apply them where before you couldn't. If anything, it seems like all the stuff I was interested in before I got myself into the games ghetto - programming language design and implementation - is becoming more relevant as time goes on, not less.

    And, well, yeah, the majority of academic research is nonsense designed to get names on as many papers as possible - that is the nature of the game. I got published once and that was more than enough to turn me off from trying to do it again. But if you're looking in the right places and consistently, you find gems occasionally. I have many books and academic papers in my private collection that I think highly stand the test of time in terms of applicability, and offering general reasoning frameworks from which, without expending huge amounts of effort, one can devise ways to get within striking distance of state of the art.

  2. #22
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,386

    Default

    Agree 100%; I don't think there's enough cross-domain synthesis going on today but it really can help. That said, that's not the same as saying :

    R&D on the software side has in my observations followed merely this form: buy up software designers who already had the knowledge and/or interesting designs going for them before a penny was spent, and now they just get to apply that to one company or another's pet product
    ... unless you mean that only in the most generic sense. My interpretation of your statement was that you were talking about "buying up" experienced GPU driver developers, but maybe you just meant "buying up" experienced programmers with general knowledge, not necessarily developers who had worked on GPU drivers before ?

  3. #23
    Join Date
    Jun 2010
    Posts
    10

    Default

    Quote Originally Posted by bridgman View Post
    Agree 100%; I don't think there's enough cross-domain synthesis going on today but it really can help. That said, that's not the same as saying :



    ... unless you mean that only in the most generic sense. My interpretation of your statement was that you were talking about "buying up" experienced GPU driver developers, but maybe you just meant "buying up" experienced programmers with general knowledge, not necessarily developers who had worked on GPU drivers before ?
    Sometimes the former, sometimes latter. In the case of GPU development, more the latter than the former, but I think the extent to which a proprietary environment is purported to be needed to produce an experienced GPU driver developer is overstated, and this underappreciates the value of pre-existing competences in a developer. Due to the nature of patents and intellectual property in the hardware industry, the proprietary GPU vendors are the only environment really placed to put the cherry on top of the programmer experience sundae anymore, but it need not be so.

  4. #24
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,386

    Default

    Quote Originally Posted by somedev View Post
    but I think the extent to which a proprietary environment is purported to be needed to produce an experienced GPU driver developer is overstated, and this underappreciates the value of pre-existing competences in a developer
    I don't think anyone has stated that at all, actually, let alone overstated it. The open source development community produces some extraordinarily good developers... it just doesn't produce enough of them.

    The only things a HW vendor reasonably expects from proprietary development are (a) the potential for proprietarty advantage, and (b) the ability to move more quickly by managing most of the proprietary IP as trade secrets rather than having to rely entirely on the patent process for protecting that proprietary advantage.

  5. #25
    Join Date
    Dec 2008
    Posts
    984

    Default

    Quote Originally Posted by archibald View Post
    Because Linux isn't the only operating system to use them - the BSD users would probably be a little upset if somebody attempted to change the licence.
    Yeah those angry BSD folk with their pitchforks on a jihad against the GPL. But isn't BSD's biggest problem the shortage of developers working on the kernel side of the graphics stack (i.e. kms/dri2) ?

    Maybe they should ask Steve Jobs to throw them some crumbs

  6. #26
    Join Date
    Oct 2009
    Posts
    2,064

    Default

    The big important question still sitting on the table is this;
    the snapdragon's graphics core -- the "adreno 200" was designed by AMD and originally called the "z430".

    HOW MUCH does it have in common with GPUs for which AMD has released programming spec, i.e. R600? Certainly they didn't reinvent the wheel on it, therefore it must be made based on some common design. Do the open source kernel drivers that qualcomm just released give away any noteworthy similarities? Might it be reasonable to ADAPT the R600 driver to the adreno?

  7. #27
    Join Date
    Jul 2010
    Posts
    449

    Default

    Quote Originally Posted by monraaf View Post
    Yeah those angry BSD folk with their pitchforks on a jihad against the GPL. But isn't BSD's biggest problem the shortage of developers working on the kernel side of the graphics stack (i.e. kms/dri2) ?

    Maybe they should ask Steve Jobs to throw them some crumbs
    I'm not qualified to answer what BSDs biggest problem is (would anybody?), but I certainly don't think that all the BSD folk have a jihad against the GPL. Personally, I think they are different tools, both good for different jobs, but I'm sure many people disagree, and I harbour them no ill-will for doing so.

    With that said, as a BSD-user I should really be saying 'oh noes, teh non-freez GeePeeEll will eat ur codez!'

    Or, more seriously, I don't think that (what would amount to) a licence-motivated fork of X is in the best interests of either camp.

Posting Permissions

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