(2012-08-20 15:56)davilla Wrote: (2012-08-20 13:02)oliv3r Wrote: Having the binary blobs for the mali GPU closed, is just a huge step back and will cause problems in the end. A step back, as Both intel and AMD show, that it's quite possible to have Open Source Video drivers. You can argue that 'this isn't ubuntu Desktop', but why not? You can use one of these socs, and make very low powerd desktops from them?
I think the whole point of opensource, is not having a blob somewhere and 'as long as it works, who cares'. Why would we want to use things like Linux in the first place? Anyway, that's a discussion for elsewhere entirely.
I don't know on which bits the lima driver leans for the mali, but if you say that the opensource kernel bits and userland bits are that dependant on eachother, chances are the Lima driver has its own KMS bit. Luckly lima is slowly progressing further and further, because some people actually do care 
Welcome to the real world of company policies and protected IP I take a practical approach to open source, not a fanatical. Userland Mali/Ump/Opengles have always been closed source, embedded, desktop or otherwise. Like I mentioned, it takes an NDA from ARM to obtain source code. And it's not just ARM/Mali, ImgTech and others do the same thing. These are system libs and closed source system libs are permitted under GPLv2. Nothing new here. Nothing really to discuss.
The Intel/AMD driver suck, everyone knows it. Is it because they are open source ? Not sure. I run Nvidia cards in my desktop linux boxes, why... Because it just works and their hardware decode using vdpau just smokes intel/amd.
Lima driver is an interesting project and I give it several years before it reaches a viable stage but by then GPUs will be much, much more complicated and I suspect Lima will fall behind from insufficient resources. All these open source drivers are great but, the number of persons that are actually qualified to understand and make sensible changes/improvements are quite small, and the number who are interested enough to do it, even smaller.
Here's a my lesson in FOSS... I (with Jarod) worked with Broadcom to open source their kernel and userland code for the CrystalHD. The CrystalHD has valid decoding licenses from Broadcom attached to the hardware. That means a FOSS solution for hw decode of h264, mpeg2 and vc1 that includes proper licensing attached to every single device. We pushed it out into the open and not one open source person besides us EVER looked at improving the code. No one. zero. zip, nada. If I had not put it into XBMC, I doubt than any other OpenSOurce media app would have picked it up. Open Source is great but the reality is that the number of people that can actually look at kernel/device code and understand much less improve it is quite small. Now if this is how something 'simple' like CrystalHD was treated, anything more complex such as a video driver becomes even less likely to receive attention and resources that it needs to be practical.
I'm doing it again with Pivos, we pushed everything public with the hope that the FOSS userland will support and provide Pivos with the resources to further product development and improvements. It remains to be see if this will be a successful business model.
(2012-08-20 13:02)oliv3r Wrote: Back to Amlogic, if all amlogic userland and kernel drivers are open (except the mali driver of course) then a fully FOSS device can be built, correct? Or is the VPU userland also binary only? With VPU support, I didn't really mean kernel/userland mode, but rather binary only mode, again, firmware is okay to be closed blob.
I suggest actually looking at the source code provided, all of your questions are answered there. I chose Amlogic SoC for Pivos specifically because of the amount of source code available. The only binary blobs are the firmware that gets loaded to the VPU and audio DSP. VPU is handled in kernel driver, audio DSP is handled in userland. Both methods are permitted under GPLv2. So with Amlogic, you are about as FOSS as you are going to get in the real world of companies that spend large amount of resources to license, design, test and manufacture ARM SoCs.
You are very right with regards to the broadcom support. I actually have one. I bought it specifically because it was opensource. I haven't done 'much' with it, it's in my new htpc to be
As for changes bug/fixes. Is there anything needed? It works as advertised, right? But I'm sure, that if in 3 years time, some kernel stuff may change, or some user land adaptions will be required someone will step up to do the work
You are very much right however. The people who understand and are able to work on these things are minimal. It's complex stuff without a doubt. Is it because nobody wants to do the work? Nah, I think most people consider it 'done', no? There already is serious lack of manpower for a lot of projects.
I even understand, to an extend, your practical standpoint, maybe less much your reasoning, "If it works, who cares". I know that certain things will only work with blobs and there's nothing we can do about it (mali gpu for example). In such a situation, absolutely. Using the blob is the only option and for practical reasons needs to be used. It's not however something to aim for!
In any case, I'll take a deep look into the AMLogic bits of the pivos git repo, but I was unaware that, besides the firmware and the binary mali blob, it was in such good (FOSS) shape. As said, firmware is acceptable and until lima works well enough to support XBMC, mali blob will be too. And thus native FOSS XBMC hardware is a reality then!
Back ontopic
If Allwinner doesn't want to get aboard, who needs them, there's an alternative. Having A10 support would be nice, but unless it's at least as 'open source' as pivos/amlogic, A10 will be irrelevant.
P.S. Divilla, all said and done, Big Kudos to you for the work you've done so far
Search
Help