+- XBMC Community Forum (http://forum.xbmc.org)
+-- Forum: Development (/forumdisplay.php?fid=32)
+--- Forum: Feature Suggestions (/forumdisplay.php?fid=9)
+--- Thread: [LINUX] XBMC for Linux port to ARM architecture CPU and SoC chips? (/showthread.php?tid=35139)
- McGeagh - 2011-04-12 18:45
davilla Wrote:If you have patches, we would love to get them into trunk. Remember that we need to watch out for tegra2 as it's armv7 is non-standards, ie. no neon and vfp is vfpv3-d16.
Its rather annoying, because only the Cortex A9 has NEON as an option... and more annoyingly, only nvidia (to my knowledge) have gone with the A9 without NEON...
damn you nvidia!
ideally, we will need to do a NEON, VFP (for those without NEON) and VFPv3-d16 (to keep tg2 happy) version of all of those functions.
- phusho - 2011-04-13 09:22
topfs2 Wrote:xbmc uses X to create the egl surfaces and setup the gles context, it also uses it for input. So you'd need to patch that in order to get it to run outside X, it is for sure possible, just noone have done it yet.http://www.youtube.com/watch?v=8dyJrzq2kxY
Getting it to start without X should be the first part, then get it to pull input events is the next.
no comment
- McGeagh - 2011-04-13 11:06
phusho Wrote:http://www.youtube.com/watch?v=8dyJrzq2kxY
no comment
correction, no one who seems willing to push patches back, has done it...
btw, why are you using load multiples for your asm floor function? fldd and fsts will do fine
you are doing a lot of work that we are very interested in, please, provide patches so theres no duplication of work being done.
thank you
- phusho - 2011-04-13 12:43
McGeagh Wrote:correction, no one who seems willing to push patches back, has done it...I am almost done with system work and will post some of the patches. I am afraid I am working on some older clone already ...
btw, why are you using load multiples for your asm floor function? fldd and fsts will do fine
you are doing a lot of work that we are very interested in, please, provide patches so theres no duplication of work being done.
thank you
For multiple store and load I have problems with compiler and it will keep mumble about fldd and fsts that something is not right with them ... also gcc optimize parts of code I don't want and such
Edit: before time I had posted one patch about DrawQuad and it was never commited as I know ... You can write me PM for more info about patches I wand to commit
- McGeagh - 2011-04-18 13:37
EDIT: I looked into the DrawQuad patch, and it was commited, just the trac didnt reflect this. it does now.
We do appreciate any and all patches you can provide us. Thanks
also, i have written some VFPv3 code for the mathutil functions, but havent had a chance to test it to make sure it works (mainly because i dont have a board with vfpv3 setup). If anyone does and would like to be the guinea pig, that would be very helpful.
phusho, your version looks like VFPv2 to me, so please keep them. having the different versions will ensure backward compatibility.
I have not looked into nvidias own VFPv3-D16 crap, nor NEON yet, but both would be very good to have eventually.
- phusho - 2011-04-18 15:23
McGeagh Wrote:EDIT: I looked into the DrawQuad patch, and it was commited, just the trac didnt reflect this. it does now.
We do appreciate any and all patches you can provide us. Thanks
also, i have written some VFPv3 code for the mathutil functions, but havent had a chance to test it to make sure it works (mainly because i dont have a board with vfpv3 setup). If anyone does and would like to be the guinea pig, that would be very helpful.
phusho, your version looks like VFPv2 to me, so please keep them. having the different versions will ensure backward compatibility.
I have not looked into nvidias own VFPv3-D16 crap, nor NEON yet, but both would be very good to have eventually.
IDD it is VFPv2 for arm1176JZF-S
- McGeagh - 2011-04-18 15:47
after a bit of research, vfpv3-d16 is no different to standard vfpv3 (except has half the available double-registers... of which we are only using 1) so it should work for tg2 too.
i am unsure if vfpv3 code will work on vfpv2 though (says it is backwards compatible)
Also there is no need to do a NEON version, as that will only give a performance increase if it were vectorised... and currently that is not the case if changing mathutils only.
I will try test my vfpv3 and commit later.
- phusho - 2011-04-19 10:06
McGeagh Wrote:after a bit of research, vfpv3-d16 is no different to standard vfpv3 (except has half the available double-registers... of which we are only using 1) so it should work for tg2 too.
i am unsure if vfpv3 code will work on vfpv2 though (says it is backwards compatible)
Also there is no need to do a NEON version, as that will only give a performance increase if it were vectorised... and currently that is not the case if changing mathutils only.
I will try test my vfpv3 and commit later.
send me the code I will test it on my board for vfpv2 compatibility
P.S. It seems that VFP code run much slower on NEON capable CPU-s. e.g there is test of VFP matrix multiplications on iPhone 3GS and VFP code is slower than ordinary C code and much slower than NEON code ... go figure it out.
- McGeagh - 2011-04-19 11:07
NEON is seperate to the VFP. Although neon can do VFP instructions, it will only give performance benefits if the code can be vectorised.
As for it being slower than C code, its entirely possible that the c compiler is smarter than whoever wrote the VFP code, and therefore optimised it better.
I am indeed trying out various different methods, and will be testing to see which version, is the best performance... this could mean standard C code may be the winner! I will keep you informed.
As for giving you my current code, i have realised an error and am working to fix it. so once i do that, ill send you the change.
Telechip, Nvidia Tegra2, OMAP4, etc - PeterW - 2011-04-19 17:33
Hello,
I have followed this thread for a while and realised that there are quite a few SoCs around on which members of this forum have more or less sucessfully installed XBMC. What would be the recommended platform?
I presume whenever developers are reporting about the port of XBMC to one or the other platform, what kind of baseboard they are using, e.g. for Telechip or Nvidia Tegra?
Kind regards,
peter