• 1
  • 2(current)
  • 3
  • 4
  • 5
  • 9
XBMC on A7 (5s and mini retina) does not use HW acceleration
#16
(2014-02-12, 12:29)Memphiz Wrote: @linusyang - nice work ... we will discuss how to make use of your work after gotham release.

Thanks. However, there are many workarounds in my current forked version, which should be replaced with real solutions. Smile

All changes can be found at my forked version. (https://github.com/linusyang/xbmc/tree/darwin-arm64)
But I thinks I should show the changes briefly to devs.

Here is the summary of them:

3rd-party libs (tools/depend)
  • configure.in: allow use_cpu to accept arm64 (since I use --with-cpu to specify arm64); remove several unused cflags (e.g. mcpu, mfpu) (new clang just ignores them); add cflag "-Wno-error=implicit-function-declaration" (important, else clang will show bunch of errors when building)
  • pcre: disable jit support (sadly current pcre doesn't support jit on arm64)
  • openssl: change Makefile "-arch armv7" to "-arch $(CPU)"
  • libmad: add "--disable-aso" when running configure
  • libmpeg2: patch to fallback to c code instead of neon asm (neon asm on aarch64 is changed a bit, all 32-bit neon cannot directly run on arm64)
  • mysql: add macro to detect arm64
  • libffi: move to an experimental version for aarch64 support: https://github.com/zwaldowski/libffi-iOS...-ios-fixes

ffmpeg
  • lib/ffmpeg: completely move to latest git version of ffmpeg with aarch64 support (of course patched with all xbmc customized patches)
    (Yeah, I know I am a bit lazy. We can just backport the aarch64 part Tongue)
  • gas-preprocessor.pl: move to working aarch64 compatible version: https://github.com/libav/gas-preprocessor
  • configure.in (at XBMC root dir): do not hardcode use_cpu. set FFMPEG_EXTRACFLAGS to empty for arm64. (else gas-pp.pl will fail with wrong parsing of arguments. Maybe we can improve the argument detection of gas-pp.pl)
  • lib/DllAvUtil.h: include "libavutil/frame.h". redefine AVCODEC_MAX_AUDIO_FRAME_SIZE since the macro is deprecated in new ffmpeg.

other changes
  • disable all neon optimization code (all 32-bit neon cannot directly run on arm64, so we may need to rewrite this part.)
    (some references: http://chromasoft.blogspot.com/2013/12/i...-code.html and http://www.linaro.org/documents/download...e729c0425d)
  • add check routines of __arm64__ beside __arm__ macro for detecting arm64 build correctly.
  • CoreAudioAEHALIOS.cpp: CRITICAL BUG HERE we need to check result of AudioUnitGetProperty to decide whether it is necessary to run AudioUnitSetProperty. Otherwise, CAUOutputDevice::EnableInputOuput() will always fail! (quick fix: change "if (hasio)" to "if (!ret && hasio)" and initialize "hasio = 0")
    (I nearly gave up the arm64 port because of this bug before I could figure it out Tongue)
  • XMemUtils.cpp: hardcode page size to 4096: http://stackoverflow.com/questions/21552...statistics
  • DVDVideoCodecVideoToolBox.cpp: I removed the video clamp for arm64 devices and confirmed to be able to play 1080p videos smoothly. Maybe A7 chip is powerful enough Smile

Hope this will be helpful to our devs. Blush
Reply
#17
losing neon is going to hurt Sad
Reply
#18
Memphiz, can you handle getting the CoreAudioAEHALIOS.cpp fix into Gotham ? Also check the new AE darwin sink if it's needed there ?
Reply
#19
1. I have split out the offtopic shit to its own thread: http://forum.xbmc.org/showthread.php?tid=186061 <- Guys you already knew it was offtopic and just continued posting that crap *grrr*

@davilla will take care of that later that day - also i would say its not so bad to loose neon on those a7 64 bit arms - those are beasts Wink

@linusyang mhhh would be cool if you could change your branch to rebase on top of master instead of merging master into yours. That way we clearly see all your changes on top of head (not sure how easy it is to change this from your current branch but a simple git rebase upstream/master might do the trick?).

edit:

@davilla - pr for the AE/CA fix planted - there is no call to getproperty kAudioOutputUnitProperty_HasIO in the AE ios sink at all - so its not needed in the current state.
AppleTV4/iPhone/iPod/iPad: HowTo find debug logs and everything else which the devs like so much: click here
HowTo setup NFS for Kodi: NFS (wiki)
HowTo configure avahi (zeroconf): Avahi_Zeroconf (wiki)
READ THE IOS FAQ!: iOS FAQ (wiki)
Reply
#20
(2014-02-12, 16:43)Memphiz Wrote: 1. I have split out the offtopic shit to its own thread: http://forum.xbmc.org/showthread.php?tid=186061 <- Guys you already knew it was offtopic and just continued posting that crap *grrr*

@davilla will take care of that later that day - also i would say its not so bad to loose neon on those a7 64 bit arms - those are beasts Wink

@linusyang mhhh would be cool if you could change your branch to rebase on top of master instead of merging master into yours. That way we clearly see all your changes on top of head (not sure how easy it is to change this from your current branch but a simple git rebase upstream/master might do the trick?).


Hi Memphic,

yes sorry for that... thanks for the splitting!

Let me know if you need testing, I can learn to cross compile to arm64 Smile
Reply
#21
(2014-02-12, 16:27)davilla Wrote: losing neon is going to hurt Sad

@davilla That's quite true. Falling back to C is not an ideal solution. Confused
So we need to port 32-bit style neon to 64-bit style for a real fix.
(I've attached some reference links in previous post for porting neon to arm64)

@Memphiz Sorry for the mess of my current fork. I will rebase it later to be cleaner.
When I am ready, I will post a new link here. Smile
Reply
#22
(2014-02-12, 17:29)linusyang Wrote:
(2014-02-12, 16:27)davilla Wrote: losing neon is going to hurt Sad

@davilla That's quite true. Falling back to C is not an ideal solution. Confused
So we need to port 32-bit style neon to 64-bit style for a real fix.
(I've attached some reference links in previous post for porting neon to arm64)

@Memphiz Sorry for the mess of my current fork. I will rebase it later to be cleaner.
When I am ready, I will post a new link here. Smile

Linus,

DVD support was failing on the 32 version as well... it's not specific to your version

EDIT: actually, it was fixed today Smile http://forum.xbmc.org/showthread.php?tid=164942
Reply
#23
(2014-02-12, 16:43)Memphiz Wrote: @linusyang mhhh would be cool if you could change your branch to rebase on top of master instead of merging master into yours. That way we clearly see all your changes on top of head (not sure how easy it is to change this from your current branch but a simple git rebase upstream/master might do the trick?).

(Edited)
@Memphiz New rebased fork is available here: https://github.com/linusyang/xbmc/tree/darwin-arm64. Hope this one is better. Smile

Moreover, this fork uses XBMC's current version of FFmpeg. All aarch64 neon optimization for FFmpeg is backported. All patches can be found in the "patches" dir at lib/ffmpeg, with patch number from 100 to 108.

@TheTroll new code is sync to the latest XBMC's git code. Please wait for uploading built deb package. Smile
Reply
#24
Thanks linus!
Any idea what could go wrong on the PVR plugins ? I looked at the code and it fails in one of the tests at the beginning of "Create".
Reply
#25
(2014-02-13, 20:02)TheTroll Wrote: Thanks linus!
Any idea what could go wrong on the PVR plugins ? I looked at the code and it fails in one of the tests at the beginning of "Create".

New build is uploaded at https://github.com/linusyang/xbmc/releases.

About PVR plugins, I think the 64-bit port of XBMC should be all right, but there might be bugs of the plugin itself. These PVR plugins should be updated to support arm64 as well.

But since I never use any PVR plugins, I don't know how to run and debug it. I have no idea about how to fix these bugs at current stage. Sorry for this. Confused
Reply
#26
PVR plugins would have to be built the same. Also addon info expanded to support arm64.
Reply
#27
Hi,

thanks linus, I confirm that DVD ISO are working now ...
As for the PVR plugin, it remains the same (which was expected).

(2014-02-13, 21:38)davilla Wrote: Also addon info expanded to support arm64.


Hi Davilla,

do you think it is the reason of the error 6 ?
Reply
#28
show me
Reply
#29
(2014-02-14, 01:08)davilla Wrote: show me

Here is the VNSI error:

20:22:28 T:4448124928 DEBUG: Loading: /private/var/stash/Applications.YtQtM6/XBMC.app/XBMCData/XBMCHome/addons/pvr.vdr.vnsi/XBMC_VDR_vnsi.pvr
20:22:28 T:4448124928 ERROR: ADDON: Dll VDR VNSI Client - Client returned bad status (6) from Create and is not usable
20:22:28 T:4448124928 INFO: Called Add-on status handler for '6' of clientName:VDR VNSI Client, clientID:pvr.vdr.vnsi (same Thread=no)
20:22:28 T:4448124928 WARNING: UpdateAndInitialiseClients - failed to create add-on VDR VNSI Client, status = 6
20:22:28 T:4448124928 WARNING: UpdateAndInitialiseClients - failed to load the dll for add-on VDR VNSI Client, disabling it
Reply
#30
HW acceleration is working great with some MKV samples I have.
Though, it fails with livetv streams.
For instance this file :

https://mega.co.nz/#!B4wkHADS!zUowAHeIdf...5uKShr8_js

triggers a VTP open failure, with no error code ...

Any idea ?
Reply
  • 1
  • 2(current)
  • 3
  • 4
  • 5
  • 9

Logout Mark Read Team Forum Stats Members Help
XBMC on A7 (5s and mini retina) does not use HW acceleration2