Author Topic: Task control. (Read 9688 times)

1% · « **on:** October 10, 2012, 08:55:25 PM »

The new task changes seemed to speed up fine detail peaking for me.

What about canon tasks? I see priority and # of canon tasks is pretty high but some seem useless like face detection, etc.

Can any of the canon tasks be killed or re-prioritized?

a1ex · « **Reply #1 on:** October 10, 2012, 08:58:31 PM »

I didn't change any priority, just stack size (should have zero impact on speed). Compiling with -O3 has some effect.

I'd rather not mess with Canon tasks. They can be re-prioritized and killed (never tried, but I remember reading somewhere... probably in some older vxworks code).

g3gg0 · « **Reply #2 on:** October 10, 2012, 10:14:50 PM »

high p-number means low priority.
maybe thats what you mean.

a1ex · « **Reply #3 on:** October 10, 2012, 10:19:11 PM »

To kill a Canon task, just add a TASK_OVERRIDE macro with an empty function.

1% · « **Reply #4 on:** October 10, 2012, 11:13:40 PM »

That LV face runs all the time and uses some mem and cpu. I thought lower numbers were higher pirority. Movie writer is like 0x11. ML tasks all higher.

a1ex · « **Reply #5 on:** October 11, 2012, 07:38:39 AM »

ML's highest priority task should be the liveview one (with zebras and magic zoom) - that number was choosen small enough to avoid flicker in MZ (sort of), but have little or no effect over movie recording (if you go lower, recording may stop more often).

a1ex · « **Reply #6 on:** October 11, 2012, 09:58:39 AM »

BTW, g3gg0's tskmon is fantastic - it now prints all bottlenecks and tasks that require attention.

g3gg0 · « **Reply #7 on:** October 11, 2012, 12:21:37 PM »

hehe thanks

thats just a few lines of code

1% · « **Reply #8 on:** October 11, 2012, 03:47:07 PM »

So high 20s are top priority and the file I/O are prioritized lower from looking through the task manager.

But still confusing why idle task is so high priority and why power manager uses mem/cpu and is also high priority unless I have it backwards.

So 0x1D = high priority and 0x10 is low priority? I have this right?

BTW booting 600D with cache hacks appears to give me more memory and faster overall but then separate wave causes full freeze if I pump lots of data into it (i.e) stereo input from PC. Maybe the latest commits fix that. I'll have to check after work.

coutts · « **Reply #9 on:** October 12, 2012, 01:34:01 AM »

not sure about DryOS but in VxWorks like the 5dc there are functions to simply pause a task, or halt it. Maybe that's less destructive than deleting the task.

a1ex · « **Reply #10 on:** October 12, 2012, 07:05:11 AM »

0x10 is higher priority than 0x1D.

I think PowerMgr task uses all idle time to execute HLT (didn't look inside though).

ML has two ways of allocating memory for itself: by changing the BSS limit (which actually shrinks the malloc memory pool) or by shrinking the AllocateMemory pool. Both methods create some free space which won't be altered by Canon code, so ML can load safely there. If it's enough RAM for the first method, that one is used. If not... the second one is used. I'm not sure which method is used by "cache hack" boot, as I couldn't find the constants for 600D, but you should use the second one.

Another thing: use the task widget to see which Canon tasks seem useless. For example, on 5D3, aewb task is using 8% CPU out of 26% total in 24p standby (globaldraw off), even in manual movie mode (where it does nothing). Hint: try call("aewb_enableaewb", 0).

1% · « **Reply #11 on:** October 14, 2012, 05:27:32 AM »

Code: [Select]

#define HIJACK_CACHE_HACK_BSS_END_ADDR 0xFF0110D0 
#define HIJACK_CACHE_HACK_BSS_END_INSTR  0xE3A01732
#define HIJACK_CACHE_HACK_INITTASK_ADDR 0xFF0110DC

Those will boot 600D.

Cache hacks uses code cache of arm CPU. I don't see it allocating anywhere. Code cache has a limited size, does it not? How many hacks can we do, are we limited?

It does allocate in boot-hack.c, but shouldn't it be the similar to the old boot method? I actually have more memory free with the cache hack boot.

I tried killing face detection with cache hacks at boot and I kept it from starting but many things call on this function and would also have to be patched. Something like at least 10 spots. Otherwise you get an assert on face.c This process does make tiny jpegs and uses ram + slows down LV and whatever else its used in.

My CPU usage is 70% in LV so killing some of these things might help make everything a bit better. I see aewb too stealing cycles and LVC_DEV (probably not so useless), LV_FACE, LVFACE, LEAK(?), AVIREAD(!), CTRLSRV(?), VOICE, SOUND, WAVREADER, PTP/eyefi/usb stuff.

Not all using CPU but most using some memory.

a1ex · « **Reply #12 on:** October 14, 2012, 08:13:15 AM »

For startup, ML allocates RAM by shrinking either the malloc or the AllocateMemory pool. For 600D, you should shrink the second one, as the binary is usually bigger than the free space in the first one.

1% · « **Reply #13 on:** October 14, 2012, 06:46:16 PM »

cache boot wasn't running the camera specific init tasks, only the standard one. I think its *fixed* now. heheh, that's where the "extra" memory came from.

Danne · « **Reply #14 on:** March 08, 2019, 10:31:47 AM »

Old thread but why not.
Regarding small hacks and on eosm this line in mlv_lite.c:

Code: [Select]

call("aewb_enableaewb", unhack ? 1 : 0); /* for new cameras */Is causing autofocus to shut off during filming. Confirmed working again commenting out this very line:

Code: [Select]

// call("aewb_enableaewb", unhack ? 1 : 0); /* for new cameras */
I guess it will cause some extra overhead and I don´t know how useful auto focus is when filming but there are other cameras affected.
Started checking this after bilal gave some hints discovered from ArcziPL.
Question. Could this be fixed and still shut off aewb in small hacks?

a1ex · « **Reply #15 on:** March 08, 2019, 11:05:57 AM »

I doubt. This disables some parts of LiveView in Canon firmware, mostly related to autoexposure and white balance. Autofocus might require them, as Canon changes the LiveView brightness during that. It might be possible to patch Canon code, but figuring out what exactly to patch is not trivial.

One option would be to change defaults (fewer side effects, but a bit slower) and update the help for that menu item. That way, users who want the best performance will see what other features will be affected. Possible issue: if, at the default setting, the newer builds will be slower, some users may complain.

ArcziPL · « **Reply #16 on:** March 08, 2019, 11:11:31 AM »

Great Danne, that you nailed it down!

Was already once shortly discussed
https://www.magiclantern.fm/forum/index.php?topic=9741.msg203805#msg203805
but with no fix or whatsoever. Seemed everyone is using MF during filming.

So did I... after seeing how ugly the typical "hunting" of the AF is.

The topic was back again yesterday as I was testing conflicts of lossless compressor with other resources (this includes AF due to hint from a1ex) and Bilal was wondering if 70D is using DPAF in RAW recording. I believe in a cam like 70D, i.e. with DPAF it might be really cool to use AF for videos.

Danne · « **Reply #17 on:** March 08, 2019, 11:21:36 AM »

Aha ArciPL. Missed those discussions back then, thanks for pointers!
a1ex. As it's low priority with af filming, at least on eosm, a sub menu item to small_hacks might be nice. I am testing it enabled for a while to check permance on eosm.

Danne · « **Reply #18 on:** March 08, 2019, 02:37:18 PM »

Maybe one can disable aewb only while not focusing, when halfshutter is pressed that is

EDIT: not working

EDIT2:
Testing this:
https://bitbucket.org/Dannephoto/magic-lantern/commits/7cbab54bde8a664d10478754ca58896d3ae65351

DeafEyeJedi · « **Reply #19 on:** March 09, 2019, 05:21:02 PM »

Interesting stuff... love diggin’ through old post!

News:

Author Topic: Task control. (Read 9688 times)