gpu_mem not set to 128 in latest demo build

[brandtdaniels]

cat /boot/config.txt gpu_mem=64 arm_freq=800

again those other elf files don't exist in the latest build:

pi@raspberrypi:/boot$ ls bootcode.bin config.txt fixup_cd.dat issue.txt kernel_emergency.img start_cd.elf cmdline.txt config.txt.backup fixup.dat kernel_cutdown.img kernel.img start.elf

so we need to update config.txt:

scripted

sed -ie "s/gpu_mem.*/gpu_mem=128/g" /boot/config.txt

[jefflunt]

Is there a performance difference? In testing on the 256 board some weeks ago 64 seemed to be the best overall setting. I can try it again tonight, but I'm curious what impact there is on the speed/quality of emulation.

[brandtdaniels]

Haven't tested to that extent...still working on initial development of some missing features...

[jefflunt]

I never did get around to testing 11 days ago when I mentioned. However, I am going through a round of testing tonight in an effort to get everything working in preparation for a release. I will test the 64 vs. 128 split on both the 256 and 512 boards and let you know if there is any noticeable difference.

[brandtdaniels]

also overclocking of cpu and/or gpu is another option.

[jefflunt]

Doesn't seem to make any difference in performance. I know that the petrockblog recommended a 128/128 split, but early on I found this to be sub-optimal. With the current state of things I can't see that it actually makes a positive performance difference.

[jefflunt]

Sure, but only if we find that we need it to get performance for some games. I don't want to shorten the life of anyone's Pi, even though I know they've announced that it no longer voids your warranty if you do it via the raspi-config menu.

If we find it's necessary for some games, we'll need to open a separate case for overclocking, or just add it to a "hacking guide" as part of the project documentation so people can tweak it themselves.

-Jeff

On Sun, Jan 6, 2013 at 12:49 AM, Brandt Daniels notifications@github.comwrote:

also overclocking of cpu and/or gpu is another option.

— Reply to this email directly or view it on GitHubhttps://github.com/normalocity/glint-nes/issues/27#issuecomment-11925207.

[brandtdaniels]

Dynamic memory splitting is now available:

http://elinux.org/RPiconfig#CMA_-_Dynamic_Memory_Split

[jefflunt]

Okay, but does it actually make any difference in performance or other important things, and how/why would we go about managing the memory at run time?