Kodi Community Forum

Full Version: Allwinner A10 : Is XBMC ported to MALI-400MP ?
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
An exception for what ?
(2012-08-19, 02:41)Shivansps Wrote: [ -> ]And the guys with the hardware are the ones on the losing end as always...

There is no way to make a exception for the android version?

I can understand your dissapointment and frustration, hence try to imagine how I feel.

But it is Allwinner who just made fun of the whole XBMC community. Looking on the unproffesional acts I got the impression the Allwinner company is not that big, hence the reason why the same people their names keep popping up and the have only ONE VPU software developer! It is just one of those companies that growed to big to fast for their own good. The had a hit with their A10 SoC in the chinees tablet market. That kicked them to the top of the ladder, but it is NOT the type of conpany that belongs their and therefor will fall of that same ladder quite hard and fast anytime soon.

The dual core cortex A9 (AMlogic) will soon take over. Followed by Tegra3. I give it about half a year and A10/A13 has fallen of the ladder.

Now to come back to XBMC;
The XBMC Android version still runs ok-isch on the device. SD material can be played on the Mele, IF streamed from LAN. Wifi is still a bit buggy.

We can only hope, that the other XBMC devs can tap into the android media framework, but I guess that needs a rewrite of the included players.

I saw that the lead developer of the Android Diceplayer is looking into adjusting XBMC to utilize a external player. He might better put his effort in rewriting his player to be included into XBMC as separate player (We already have dvdplayer, omxplayer, why not android-player)

For the allwinner A10, hope should be put into this guy.

https://plus.google.com/1044115025184558...ciMRdFqnu2

If not with, then without allwinner, right? Maybe allwinner should talk to him.

As for the amlogic, i'm still searching for some hardware details, but I assume it also has it's 'own VPU'?
One thing I do not understand: Pivos gives help for xbmc devs. But is it enough? They are not the chip producer, do they know everythigh about the chip which is needed? Amlogic spec information not needed for developing (like Allwinner case)?
Thanks
(2012-08-19, 11:11)oliv3r Wrote: [ -> ]For the allwinner A10, hope should be put into this guy.

https://plus.google.com/1044115025184558...ciMRdFqnu2

If not with, then without allwinner, right? Maybe allwinner should talk to him.

As for the amlogic, i'm still searching for some hardware details, but I assume it also has it's 'own VPU'?

Like I already said on Google+, I will contact him to see if we (the community) can do anything to help him out.
(2012-08-19, 11:11)oliv3r Wrote: [ -> ]As for the amlogic, i'm still searching for some hardware details, but I assume it also has it's 'own VPU'?

https://github.com/Pivosgroup, uboot, kernel and userland source code are there. What details are you looking for ?
(2012-08-19, 17:40)davilla Wrote: [ -> ]
(2012-08-19, 11:11)oliv3r Wrote: [ -> ]As for the amlogic, i'm still searching for some hardware details, but I assume it also has it's 'own VPU'?

https://github.com/Pivosgroup, uboot, kernel and userland source code are there. What details are you looking for ?

Source code or programming documentation for the VPU Smile I found some 'simple player' demo on the amlogic site but they include some closed userland libs.

I did find out the amlogic SoC includes their own VPU.

Also, I thinkt hey kernel code is against the android kernel? Or are all drivers mainlined allready? That would be cool.

I know Mali kernel bits should be mainlined, just the OpenGL bits are either closed source, or highly experimental.


Anyway, if their VPU bits are up on github and opensourced, why would there have been so m uch fuss even about the A10 Smile When the AML allready rocks :p

@oliv3r, mali, ump and opengles userland is always closed source on any device. Need an NDA from ARM to get the source code for those but as long as they work as advertised, who really cares. Also, they are system libs and you are permitted to link to system libs under GPL.

All Amlogic userland and kernel drivers are open, they are present in the pivos github. Firmware is closed, it's not likely that one would even have the tools to compile them anyway nor understand the internals of those devices. Again closed source for firmware is permitted and as long as it works, who really cares.

mali is not mainlined back into kernel sources because it is version dependent with userland. Generally forget mainlining arm device sources back to kernel, there are too many different implementations and each has their own tweaks and such. This is not desktop ubuntu here.

The kernel on pivos github IS the android kernel, I just fixit up and configure to work with a linux userland.

In general, you don't need to talk to the VPU, the kernel drivers do that and you want userland access anyway. Talking to the VPU is very complicated and unless you fully understand everything about it, you will epic fail. AML has codecs in userland there so you can roll your own player, or you can use libamlplayer like we did in XBMC.
I dont understand how a company such as a AllWinner can come up with one of the best (if not the best) video decoder out there, and then do this to people trying to use it!

Ive seen the video decoder on the single core amlogic A9(Ainol Novo 8), and is bad compared to cedar, too bad, it relies way too much on cpu. I not sure if the dual core one is any better, i bet its the same one, just performs a bit better because of the dual core cpu... but im not sure on this.

That was the main hype about the A10(and multi format), i can give it a 40mbps file and it will still playback it, even undercloked.

Im a bit tired of arm really, and mips too, i think i just gona buy a x86 htpc and get over with, which is bad because i have 2 tablets that i dont use anymore(broken touch) that i could use them to the job.
@Shivansps, you are kidding right ? I can play raw decrypted bluray and idle down to 600MHz, the only cpu going on is the demux feed. Can't get less than that.
Maybe is improved on the AML8726-M6, on the AML8726-M3(800mhz) that i had on my Novo 8, it was better than the VPU (or wharever is on the JZ4770 that it cant even play a +8mbps file), but i was never able to playback OK any of my 1080p mkv (15 to 20mbps). Maybe it was a firmware issue, but it never worked for a high mbps file...

At that point i had 3 tablets, the Novo 7 Basic with JZ4770, his VPU is bad, but it can play 480P videos for over 11 hours, i use it for a portable media player (even today with his broken touch because it has a IR remote), the Novo 7 Aurora (A10) and Novo 8 (AML8726-M3), i got rid of the Novo 8 basically because it was good for nothing compared to the other two.

The A10 was just.... too good, about 250mhz is all it needs to playback all my mkvs, to give you an idea. So bad that AllWinner tuned to be that kind of company, what a waste.
Ahhh, so you just are commenting from a user standpoint as to what plays and what does not and not knowing what the actual hardware can do. That makes sense now. Must be older implementation/firmware on those devices then.

(2012-08-19, 23:54)davilla Wrote: [ -> ]@oliv3r, mali, ump and opengles userland is always closed source on any device. Need an NDA from ARM to get the source code for those but as long as they work as advertised, who really cares. Also, they are system libs and you are permitted to link to system libs under GPL.

All Amlogic userland and kernel drivers are open, they are present in the pivos github. Firmware is closed, it's not likely that one would even have the tools to compile them anyway nor understand the internals of those devices. Again closed source for firmware is permitted and as long as it works, who really cares.

mali is not mainlined back into kernel sources because it is version dependent with userland. Generally forget mainlining arm device sources back to kernel, there are too many different implementations and each has their own tweaks and such. This is not desktop ubuntu here.

The kernel on pivos github IS the android kernel, I just fixit up and configure to work with a linux userland.

In general, you don't need to talk to the VPU, the kernel drivers do that and you want userland access anyway. Talking to the VPU is very complicated and unless you fully understand everything about it, you will epic fail. AML has codecs in userland there so you can roll your own player, or you can use libamlplayer like we did in XBMC.
Oh wow, it saddens me to see your standpoint with regard to the binary blobs.

Having firmware be closed is acceptable, under the GPL and even in FOSS terms. Ideally, even firmware should be open though.

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 Smile

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.
(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 Smile

Welcome to the real world of company policies and protected IP Smile 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.

(2012-08-20, 15:56)davilla Wrote: [ -> ]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.

Sorry, I normally lurk but just want to chime in.

Even though the people who care about those features normally are not the people who have the technical knowledge to do something about it, if there are Kickstarter-style campaign to raise money to attack specific, popular feature/issues - such as Android port, certain chip's hardware acceleration etc. I suspect a lot of people would be interested to chip in and pay for experts' time, experts that wouldn't normally be interested to work for free on project that they have no stake/interest in; or to pay for expenses of the devs so they can spend more time on the project than they could for free.

The problem with regular project donations is that you are never sure that you're money is put into improving the aspect of the software that you personally need/care about, and as a result there's never that much feedback the development progress of that feature which you care about. If there's a campaign set-up to attack specific issues such as Android port, I'm willing to put my money where my mouth is to get features I care about closer to reality.

In the end, it couldn't hurt to do an interest check to see which issue is popular and is feasible (seeing as A10 can't proceed without Allwinner's suppport beyond lip service).