The Embedded Linux GPU Mess & How It Can Be Fixed

[somedev]

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.

[bridgman]

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 ?

[somedev]

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.

[bridgman]

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.

[monraaf]

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

[droidhacker]

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?

[archibald]

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.