Messages

LINK: MLTools

Link is dead?

Omh, I actually managed to produce a pull request! Goodbye cvs :-) ... https://bitbucket.org/hudson/magic-lantern/pull-requests

Make patch file or make pull request to your repo.

I added a patch file above - I'm not very accustomed to Mercurial/git and other distributed thingies yet, imho it was a mistake men ever came down from trees and stopped using cvs :->

Works on my 60D, including scroll.

After the last "-O3 fix", it now also works again if compiled w/ Linaro 4.7 :-)

The -O3 binary may not load on 60D because it may be too big. Try adding this in CFLAGS: -DCONFIG_5D3_MINIMAL.

Thanks again, that did it, -O3 now works on my 60D, too.

That, and I would have loved to have separate pull requests for audio and menus. But a1ex just accepted the full pull request it so....

Doesn't work on 60d (should it? anything else required except replacing autoexec.bin?), ml menu simply refuses to show

You need to pull before updating

Thanks, that works - old school /me is used to Subversion where "svn update" is working for the simple minded just fine :-p

PS: you could add this step to http://magiclantern.wikia.com/wiki/Build_instructions ... I expected this to be conclusive so I didn't feel the need to wade through the Mercurial doc.

This is a bit embarrassing, but I just cannot get Mercurial to update my repository. Even if there is a update "hg update" just shows "0 files updated, 0 files merged, 0 files removed, 0 files unresolved". If I try to force the newest revision via "hg update -r 00110a6f83aa" it says "abort: unknown revision '00110a6f83aa'!". This is what "hg summary" shows:

parent: 4756:04ef6f499dc2 tip
delete splash screen
branch: unified
commit: 1 modified
update: (current)

A fresh checkout via "hg clone https://bitbucket.org/hudson/magic-lantern/ -u unified" gets the new files, but of course kills all local changes. Argh - help please!

I'm usually changing a line in menu.c to beta_warned=1 because I know I compiled it myself :-p

But maybe it'd be convenient to include a generic option that is switchable through Makefile.user. The other option would be to wrap all the beta code in a macro, reducing the build size a bit for release builds.. just an idea.

EDIT: Here's the patch, just add -DCONFIG_RELEASE_BUILD to CFLAG_USER ...

Code Select Expand

# HG changeset patch
# User Marsu42
# Date 1348137927 -7200
# Branch unified
# Node ID ae35f7a27e6e1358606a7e5afe49c909e707c7de
# Parent  00110a6f83aa7c05bb19f46c71c456f29ffedd13
Option to skip beta warning & some optimization CFLAGS (disabled by default)

diff -r 00110a6f83aa -r ae35f7a27e6e Makefile.user.default
--- a/Makefile.user.default Thu Sep 20 10:38:31 2012 +0300
+++ b/Makefile.user.default Thu Sep 20 12:45:27 2012 +0200
@@ -19,7 +19,7 @@
PYTHON=python2

# You can customize CFLAG here
-#CFLAG_USER = -mlong-calls \
+#CFLAG_USER = -march=armv5te -mcpu=arm946e-s -O2 -DCONFIG_RELEASE_BUILD \

# Naming convention for Magic Lantern builds:
# General rules:
diff -r 00110a6f83aa -r ae35f7a27e6e src/menu.c
--- a/src/menu.c Thu Sep 20 10:38:31 2012 +0300
+++ b/src/menu.c Thu Sep 20 12:45:27 2012 +0200
@@ -155,7 +155,12 @@
*/
}

+#ifdef CONFIG_RELEASE_BUILD
+int beta_warned = 1;
+#else
int beta_warned = 0;
+#endif
+
void
draw_beta_warning()
{


Congratulations - I hope this gives quite a $$$ boost to development, too.

Glad to see they're learning.

No, they're not - at $2099 the 6d has horrible specs, it's not "mini-5d3" but a "high image quality tourist camera". Even ignoring the Nikon d600 it's no competition even to the 5d2 because ml adds some gimmicks like 3+ bracketing that Canon sees as selling points for the 6d. The one exciting thing is wifi remote control,. But the af is a mess - it has no real, but only a hybrid cross type points with lenses of f2.8+ and just one with f4- lenses - they traded af precision for low light capability of -3ev (1dx/5d3: -2ev).

It has just been presented, nobody knows when it'll hit the shelves yet.

It's announced for December, since it's a new sensor first quantities might be low, so don't get your hopes up esp. knowing the recent Canon delays.

EDIT: um, sorry, for the rant, couldn't resist, I'm quite disappointed since the 6d is not for me. But on the bright side, with the bad 6d af people will *love* magic lantern focus peaking :-)

I've never heard of this before? Do you have a reference to cite? I've never seen the meter change from the current conditions, even under the lowest light that I can still acquire AF with my fastest F/1.4 lenses.

... see http://www.canonrumors.com/forum/index.php?topic=6819.0

[deleted, brain does not work before coffee] :->

What about -mfloat-abi?

Though I am rather imtimate with OpenWrt and my mips router, I'm no arm compiler insider :-o ... What I did was just compile Linaro 4.7 with the arm scripts from Lauchpad (and not summon-arm) and add the flags nomad suggested, other than that I left the whole thing at it was except -O2 and -O3. For other options I can only read it, too: http://gcc.gnu.org/onlinedocs/gcc/ARM-Options.html ... and in this case it'll tell you to set it as soft because the arm core inside the eos cameras certainly doesn't have a floating point unit.

I'm using GCC from summon arm. I think its arm-elf.  I'll update to newer gcc and see if that helps. I'm using the march stuff. how do I add ftune or fcpu?

Maybe you should try arm-non-eabi, that's what I've compiled. I added the march stuff by using USER_CFLAGS (see first post), but you can also do it the foolproof way by replacing every "-march=armv5te" in Makefile by "-march=armv5te -mcpu=arm946e-s".

How do I turn on VFP? I think its virtual floating point.

I changed nothing further in the Makefile, what compiler are you using? With the gcc versions I compiled myself it doesn't throw any error when using -ftune -or -fcpu. Try the binary arm from Launchpad if it works on your platform (doesn't on my x64 Ubuntu). And ff you want I can upload the build gcc build archive somewhere, the one from arm on launchpad has some bugs I had to workaround.

I tried the cflags user and it didn't change size.

On my box, CFLAGS_USER for some reason or another sometimes isn't picked up by the main Makefile, make sure it gets through by using make V=1 and looking at the gcc lines! Or use the fool-proof version and Makefile.inc anyway. The problem simply is that the current Makefile is indeed quite a mess.

The -O3 binary may not load on 60D because it may be too big. Try adding this in CFLAGS: -DCONFIG_5D3_MINIMAL . This macro doesn't enable any 5D3-specific things, but only enables a minimal feature set (this) and the benchmarks are enabled. I've tried the macro on 5D2.

I used the 60d-only autoexec.bin from the 60D.111 directory - should adding -DCONFIG_5D3_MINIMAL do anything to this, i.e. is the 5d2/5d3 code compiled even into into the 60d binary?

But you might be correct, with -O2 "Free Memory: 70k + 1226k" .. what's the meaning of this anyway, maybe you could add an explanation in the source like "70k flash + 1226k ram".

And this too... I bet DigicIV has some overclock wiggle room.

This is proven by Canon: The 1dx uses the same af and cpu, but is faster than the 5d3 due to "higher voltage".

my main concern would be to get 1080P60 and 720P120 as it would just help me so much in action sport.

... and hdr video! At least continuous 1080p/50 would be stellar, well for us PAL users that is :-)

1. cpu optimization:

I tried different optimization flags for the arm cpu and would advise you use "CFLAGS_USER= -march=armv5te -mcpu=arm946e-s" as it reduces the autoexec.bin size by -12% while the "CFLAGS_USER= -march=armv5te -mtune=arm946e-s" only cuts 6%, both result in no performance changes in the zebra benchmark.

2. gcc optimization:

On my 60d, a -O2 version is 20% faster in zebras than -Os. However, -O3 crashes the camera, so I cannot say how much faster that would be. The problems have to be one or some of the added flags over -O2, i.e. "-finline-functions, -funswitch-loops, -fpredictive-commoning, -fgcse-after-reload, -ftree-vectorize, -fvect-cost-model, -ftree-partial-pre and -fipa-cp-clone" ... with try & error it would be possible to find the culprit and exclude it like for example "-O3 -fnoinline-functions" if anyone has time to spare.

3. gcc version:

The Linaro gcc 4.7 shows no fps improvement over vanilla fsf 4.6. That isn't really a surprise, many Linaro optimizations are for the latest arm cores, and it's only the zebra test that was tested. Still, as I wrote before Ubuntu & Linaro have switched to Linaro and it certainly doesn't hurt. I'll run this compile on my camera and see if any regressions occur, but since few things changed from gcc 4.6->4.7 I don't expect any.

I put it like this in makefile.inc... I don't know how to add this to makefile.user... is it even taking the flags out of there. I put -Wcomment to try to turn it off but I think I'm doing something wrong

Just adding zebra.o with -O3 to Makefile.inc does nothing - do make V=1 and check what parameters reach gcc. The only thing that does work is editing Makefile.inc and change the global flags, and the whole -O3 compile crashes my 60d.

edit: I created a new topic for benchmarks, since this one was really about user prefs in the makefile ... see http://www.magiclantern.fm/forum/index.php?topic=2609.0

Did the O3 flags actually optimize anything?

The -O3 I compiled produced an err70 on my 60d, so I can't tell. But according to Alex only the 50d had problems, but for other cameras compiling at least time-critical modules should improve speed. If I knew where to put the -O3 directives in the Makefile, that is - argh.

Enable focus peaking first

Ah, well, that's more like it :-> ... but for a benchmark the timing is much too rough, it should have at least some decimal places behind sec and fps.

And to ask for the n-th time, sorry to be a bother: Where do I put the -O3 optimization lines for zebra.o and so on for them to be recognized? If I can't compile an optimized version, providing benchmark results hardly makes any sense.

Anyway, You can add alex's code like this....Maybe....

... or maybe not :-p as this was the first thing I tried, it's ignored (check the output w/ V=1). Actually I'm used to use cross-compilers because I hack OpenWrt frequently, but ml's Makefile is really horrible in comparison to OpenWrt's buildroot.

Concerning the new benchmark: How it that supposed to work? On my 60d it just goes into play mode, displays "0 sec = .... fps" and that's that. If I get it to work I'm happy to tell you if my compile with Linaro 4.7 is any faster than the standard arm.

One more .  Now we can add CFLAGS like this.

+1 .. but global CFLAGS don't seem to be that useful, I tried a compile with global -O3 and it was much larger & didn't run.

Alex suggested different flags only for some modules like this:...

Code Select Expand


# compile some modules with -O3 for increased speed
zebra.o: $(SRC_DIR)/zebra.c
$(call build,CC,$(CC) $(CFLAGS) -O3 -c -o $@ $<)


... but I still don't know where to put this block (anywhere I tried it was ignored) - any hints :-p ? And of course it would be esp. nice if such compile exceptions would go into Makefile.user, too, so the repository files are untouched locally.

I Went ahead and pushed it. Copy Makefile.user.defaults to Makefile.user and keep only the options that you want to customize

You should do the same to plugins/Makefile.top, or users still have to change that for the compiler path. Or even better, make the plugins directory pull the compiler variables from the main Makefile.user