Automatically free zebra RAM

fudgey

1705
a570is

« on: 04 / January / 2009, 08:13:05 »

Advertisements

This patch (to trunk 665) makes CHDK free RAM reserved for Zebra
#1 before a script is run
#2 if zebra shortcut key is pressed to disable zebra
#3 after half shoot is released

It does not release Zebra RAM if zebra is disabled from the Zebra menu, because I didn't know how to do that.

I think #3 probably makes #1 and #2 unnecessary, but I'm not sure if it's a good idea to be mallocing and freeing zebra RAM each half-shoot. It seems to work well, but I didn't do any benchmarks!

It would be nice because then some other memory-hog (like edge overlay) would start correctly even if zebra is enabled, and zebra would just fail to draw if there's not enough RAM for both. But then again with RAM being released instantly it will be harder to notice while debugging other things that a random crash was due low RAM. Alternatively, memory hogging parts of code (like edge overlay) could attempt to release zebra RAM at startup. I already did this for script startup.

This #3 can be disabled by removing a few lines from the very end of the diff:

Code: [Select]

@@ -2601,6 +2603,7 @@
         if (!kbd_is_key_pressed(KEY_SHOOT_HALF)) {
             zebra = 0;
             draw_restore();
+            gui_osd_zebra_free_memory();
         }
         return;
     }

So what do people think? How should it be done?

release_zebra_memory.diff (2.03 kB - downloaded 104 times.)

Logged

reyalp

14117

Re: Automatically free zebra RAM

« Reply #1 on: 18 / January / 2009, 05:12:18 »

My liberal interpretation of this is checked in as svn 683. Far better to manage it in one place, allocating on every half shoot should be fine.

Logged

Don't forget what the H stands for.

hiker_jon

284

Re: Automatically free zebra RAM

« Reply #2 on: 20 / January / 2009, 16:58:54 »

Hi,
Maybe a way to avoid these memory problems would to use the unused viewport buffers to stash viewport data. I don't claim to understand all of the fine points of this (see my stereo pairs post:http://chdk.setepontos.com/index.php/topic,2974.0.html), but sometimes it can work well. If you need ram for a viewport in play mode use vid_get_viewport_fb() or maybe vid_get_viewport_live_fb() (but I have had some problems using this.) In rec mode use vid_get_viewport_fb_d().

It used to be that vid_get_viewport_fb() would not get overwritten in play mode. In the CHDK builds it does get overwritten when you move to display another image.
I don't think that vid_get_viewport_fb_d() gets overwritten in rec mode.

For instance this code works well in rec mode for edgeoverlay:
   if((mode_get()&MODE_MASK) != MODE_PLAY)
   {
      img = vid_get_viewport_fb();
      imgbuf = vid_get_viewport_fb_d();
   }

Note that one must be careful not to try to free this memory.

Jon

Logged

fudgey

1705
a570is

Re: Automatically free zebra RAM

« Reply #3 on: 20 / January / 2009, 17:29:49 »

Quote from: hiker_jon on 20 / January / 2009, 16:58:54

Maybe a way to avoid these memory problems would to use the unused viewport buffers to stash viewport data.

Sounds like a good idea to me!

Current implementations work but especially edge overlay requires too much RAM for some cams to handle. Many cameras have more than one play mode viewport buffer too, so zebra and edge overlay could even have buffers of their own (if those features even need to coexist?).

But vid_get_viewport_fb_d() is quite likely still broken for some cameras, at least partially.

And I vaguely remember some that play and rec mode viewports aren't the same size in some cameras? So care must be taken to avoid overflows.

Logged

reyalp

14117

Re: Automatically free zebra RAM

« Reply #4 on: 20 / January / 2009, 21:22:03 »

I'm wary of using the frame buffers unless we find functions or variables that indicate which ones the canon code is using. Figuring this out would be good for other reasons too.

Logged

Don't forget what the H stands for.

hiker_jon

284

Re: Automatically free zebra RAM

« Reply #5 on: 05 / April / 2009, 21:52:24 »

Hi,
After using my mod to edgeoverlay for a while I have made a change and thought I would post it here. My original modification was to use vid_get_viewport_fb_d() for imgbuf instead of mallocing ram for the buffer. vid_get_viewport_fb_d() is used for the play viewport and I thought it would be free to use during record mode as a spare memory buffer.

Sometimes it would work, but sometimes it would fail. It would always work fine for the initial display of edges on a half-press. After taking one photo the routine is supposed to freeze the edges from that photo and display them when composing the second photo. This feature would sometimes break. I tracked down the problem to the following:

NOTE: I only have A720 and A590 cameras to test, so this applies only to these cameras.

vid_get_viewport_fb_d() reads its buffer address from another address. That address can hold two different buffer addresses. For the A720 the two addresses are 0x104B8F50 and 0x105C26D0. For the A590 the two addresses are 0x104B8F50 and 0x105C2080. Strange that the first address is exactly the same for both cameras.

The second of the two addresses is also in a list of addresses kept at vid_get_fb_base(). There are 4 buffer addresses kept starting at that location. One of these addresses is picked by vid_get_viewport_live_fb() depending on the contents of yet another memory location. Very complicated! At any rate I have found that when vid_get_viewport_fb_d() gave the second address the problem occurred. So I modified my code to not use vid_get_viewport_fb_d(), but to always use the first address.

Code: [Select]

		imgbuf = vid_get_viewport_fb_d();
		if ((strcmp(PLATFORM,"a720")==0 ) ||  (strcmp(PLATFORM,"a590")==0 )) imgbuf = (char *)0x104B8F50;

Here is my guess for the reason for the complicated arrangement of addresses:
Originally Canon started out with one fixed address for the play viewport. Later on they found that they could speed things up by flippng between two different addresses for the viewport. They choose the second address from another set of buffer addresses that were used for different things. The original address is always only used for the play viewport. The second address is used sometimes for other stuff (record live_fb).

Jon

Logged