• 1
  • 2(current)
  • 3
  • 4
  • 5
  • 11
Win Win32 x64 XBMC x64 port - work in progress
#16
@Karlson2k. If you have any time over, could you please have a look at DownloadBuildDeps.bat and the associated download helper "scripts/dlextract.bat" to see if it's possible to add some kind of error checking? (See post #54: http://forum.xbmc.org/showthread.php?tid...pid1358119 )
1. XBMC: http://github.com/FlyingRat/xbmc (ffmpeg-head-inc-xbmc-patches)
2. FFmpeg: http://github.com/FlyingRat/FFmpeg (ffmpeg-head-with-xbmc-custom-patches)
3. XBMC-updated-FFmpeg-binaries (just dev snapshots, no regular distros)
Reply
#17
@Karslon2k: I don't want to slowdown you efforts here but for me it still isn't clear how much effort it would be to maintain 32/64 bit if it hits mainline. When we need to update a lib or add a new one it needs to be simple to produce the 64 bit version otherwise the 64bit port will fell behind or will be broken as I don't want to put much more effort into this afterwards. We already have a lot of addition into mainline (external player, AE, etc) which were requested to add and now nobody really cares about it and it is left to the few devs which are still there since the original authors (not necessarily team members) are gone.
And fyi a team member is looking into supporting the auto downloader for mingw32 as we really don't want to build mingw each time or upload again a compiled version of it.

Concerning the dep downloader scripts the main goal is to get rid of them sometimes. This will happen when every package will have a debian like structure (containing the path where the headers and libs are in). I do this for every updated lib but still many to go.
Always read the XBMC online-manual, FAQ and search the forum before posting.
Do not e-mail XBMC-Team members directly asking for support. Read/follow the forum rules.
For troubleshooting and bug reporting please make sure you read this first.
Reply
#18
@WiSo, I fully understand your doubts, moreover I agree with you. As XBMC grows, it's harder and harder to support it in really good state. Concerning Win x64 build, you point correct to trickiest part - the external libs. Let's split external lib situation into two cases: lib is ported to MSVC or lib require MinGW. In first case it's really simple to add x64 build and even easier to support it in future. In case of MinGW it can be little harder to add x64 build and support. BUT majority of libs are already work in x64 mode and in a few years almost every new lib or lib update will support x64 mode natively. So the only question is when to start support Win x64 mode in XBMC. On XBMC code side, all major builds (darwin, Linux and excluding Win32) already support x64 mode so it's already maintained. Win32 specific code needs very small effort to port it to x64. To summarize: it's not too hard to maintain win x64 build right now and it'll be even easier in near future. I can support it as separate fork of XBMC until team decide to merge in into mainline.
Some features will have smaller demand in future (like external player - the internal player is good enough already and will be better as XBMC developing), but other features will have receive higher demand over time. x64 is definitely second type feature. Think about upcoming H265 videos - you'll need every percent of CPU power to get smooth playback, until it'll be supported on GPU.
MinGW32 download can be automated very easy: you need only mingw-get (command line version) and small script for it. I use it already for downloading of MSYS part and MinGW32 tools for MinGW-w64 toolchains. I'll publish this script soon.

Current download scripts are kind of mess. No error checking (see PR 2385), no intermediate cleanup (so errors from one script may influence on other scripts and directories from several packages are combined (libs with libs, include with include)). If you are talking about simplified script, which just unpack ready package, than it's a great idea to move all combining logic from user to team-controlled environment.
Reply
#19
I didn't found a simple packaging mechanism on win so I write my own. Its far from being perfect but it served it purpose for most of us. If one has time to make it better, fine. If all precompiled libs are packed with the right directory structure no additional scripts are needed anymore. Also installing/updating/removing of a single lib might be worked out then.
But this needs time and people who support it. The win port is already only needy supported and the few devs left can't be burdened with more stuff. You see the forum is full of why does this not work and that not work and nobody is working on it. I'm afraid that sometime the same happens with 64bit.
For Linux and OSX its not that hard as they already compile every lib from scratch - windows doesn't.
And tbh I still don't belive that's much faster under 64bit then now. There're other parts which need to be optimized first. But still show me figures and I believe.
Anyway Mozilla stopped it 64 bit work and they'll know why...
Always read the XBMC online-manual, FAQ and search the forum before posting.
Do not e-mail XBMC-Team members directly asking for support. Read/follow the forum rules.
For troubleshooting and bug reporting please make sure you read this first.
Reply
#20
Another sidenote on the fork. Please indicate in the log thats not the mainline build (we could use a conditional 32/64 bit log line). That makes it easier to see if both version share the same bugs or we get new ones for 64bit. Can't imagine to have in future to test two platforms for bugs = more effort.
Always read the XBMC online-manual, FAQ and search the forum before posting.
Do not e-mail XBMC-Team members directly asking for support. Read/follow the forum rules.
For troubleshooting and bug reporting please make sure you read this first.
Reply
#21
@WiSo, I'm sure that things are not so bad. Smile
I'll add 'XBMC 64-bit experimental' to log.

About performance. I'm not sure that web browser is most CPU hungry app. Smile

I did my own test on video performance. You can reproduce it.
You need:
* heavy test clip (I used Ducks.Take.Off.2160p.QHD.CRF25.x264)
* GraphEdit (32 and 64 bit) or GraphStudioNext (32 and 64 bit)
* LAV Video Decoder (32 and 64 bit, same versions). You can try FFDShow.
* PC with Windows 64-bit Smile
Render media file in GraphStudioNext (you can just drag-n-drop file).
Disable GPU decoding in Decoder.
Press play and wait until it finished.
Check 'Quality' tab in properties of Video Renderer.
In case of 64 bit decoder, I got 29.94-29.97 FPS and 0 frames lost. (CPU is Core i7 950)
In case of 32 bit decoder, I got 27.31-28.04 FPS and about 4-9% of frames lost. Several test runs.
I try to limit number of threads for decoder to 4 threads. Then I got 19-20 fps vs 17-18 fps

And unexpected result: with enabled GPU decoding (HD 7850) I have 29.95-29.67 and 0 lost on 64-bit vs 27.0-27.6 and about 10-12% lost on 32-bit. Edit: looks like GPU decoding is just not working, ether on this clip or in GrapStudio.
Reply
#22
just bumped into this post and this line in the OP:
Quote:libcec - will ask author for x64 port
the author (me) says: we've got native x64 almost since the start, but they are just not included in the zip on xbmc's mirrors.
opdenkamp / dushmaniac

xbmc-pvr [Eden-PVR builds] [now included in mainline XBMC, so no more source link here :)]
personal website: [link]

Found a problem with PVR? Report it on Trac, under "PVR - core components". Please attach the full debug log.

If you like my work, please consider donating to me and/or Team XBMC.
Reply
#23
@opdenkamp, that's nice. I was sure that it's not a problem. Smile
But I can't find binaries when following link on libCEC page: "Prebuilt binaries can be found at our packages site".
Could you point me to x64 binary?
Reply
#24
I may be completely blind here but are you working in any public repo? It sounds like a fun idea and I'd like to check it out.
The janitor, cleaner of cruft, defender of style. Also known as the unfunny guy that doesn't understand signatures.
Reply
#25
(2013-03-07, 23:44)Karlson2k Wrote: @opdenkamp, that's nice. I was sure that it's not a problem. Smile
But I can't find binaries when following link on libCEC page: "Prebuilt binaries can be found at our packages site".
Could you point me to x64 binary?

it's included in the libCEC update: http://packages.pulse-eight.net/windows/...latest.exe
you'll find the x64 binaries in C:\Program Files (x86)\Pulse-Eight\USB-CEC Adapter\x64 after installing. You'll only need libcec.x64.dll for XBMC
opdenkamp / dushmaniac

xbmc-pvr [Eden-PVR builds] [now included in mainline XBMC, so no more source link here :)]
personal website: [link]

Found a problem with PVR? Report it on Trac, under "PVR - core components". Please attach the full debug log.

If you like my work, please consider donating to me and/or Team XBMC.
Reply
#26
(2013-03-08, 10:19)Trem Wrote: I may be completely blind here but are you working in any public repo? It sounds like a fun idea and I'd like to check it out.
Are asking about repo with XBMC code?
You can't test XBMC x64 without needed libs. You can't even build XBMC without some libs.
So the answer is "not yet". Right now I'm focused on libs.

First post was updated with asking for help from team.
Need libs list cleanup.
It's a pity to waste time on unneeded libs.
Reply
#27
(2013-03-08, 13:07)Karlson2k Wrote: Are asking about repo with XBMC code?
You can't test XBMC x64 without needed libs. You can't even build XBMC without some libs.
So the answer is "not yet". Right now I'm focused on libs.

I was thinking of both xbmc and libs. Thinking was along the lines of possibly being able to help with a lib here or there.

Don't know if I would be able so I won't ask you to spend time fixing a repo for it though.
The janitor, cleaner of cruft, defender of style. Also known as the unfunny guy that doesn't understand signatures.
Reply
#28
@Trem, superb!
But for libs we need an working toolchain. Most libs are MinGW-compiled, so we need MinGW-w64. By build is almost finished and I hope soon will be published.
Besides MinGW-compiled libs, you can pick any lib marked as 'work not started' on first post and (if it MSVC-compiled lib) start working on it.

Or you can try to fix warnings in https://github.com/Karlson2k/oncrpc-win32/tree/Win-x64 or https://github.com/Karlson2k/libnfs/tree/Win32x64 (be sure to select correct branch!).
One of them (don't remember which one) have a problem: it use 'int' as socket handle, but on Win64 handle is 64-bit. So a lot of code needs some refactoring/fixing.
Reply
#29
http://savannah.gnu.org/bugs/?37981

Same path and same problem Wink

Which lib have you already?
Silverstone Grandia GD02-MT | AMD A8-3850 | Breakaway Audio Enhancer, HK AVR-365 | HKTS 30, Philips 50PFL7956H/12 21:9 3D
Reply
#30
Actually I have all libs, that are needed to compile other MinGW libs: dlfcn-w32, expat, gettext, glib, gmp, gnutls, libffi, libiconv, libxml2, nettle, plibc, pthreads-w32, xz, zlib.
Reply
  • 1
  • 2(current)
  • 3
  • 4
  • 5
  • 11

Logout Mark Read Team Forum Stats Members Help
Win32 x64 XBMC x64 port - work in progress5