Screen banking revisited
Neil Fazakerley (464) 124 posts |
Having finally upgraded my gaggle of monitors to standard 1080p widescreen models (1920 × 1080), my Basic graphics progs can no longer use screen banking for 16m or 64k colour modes. I’m stuck with 256 colours for what were previously very nice animated graphics demos, but look cr*p in 256. Is there any way I can program the Pi to bank in 1080p 64k colours. I’ve seen some posts here and on the R-Pi forums that suggest changing settings in config/txt to assign more GPU memory, changing max pixel clock and various other settings etc. Also, has anything improved banking-memory-wise with the Pi 3, or the latest versions of RO? Any suggestions appreciated. |
Jeffrey Lee (213) 6046 posts |
The big problem with screen banks on the Pi is that we don’t get very good feedback from the GPU. We don’t know how much free memory it has, and we don’t know what the size limits are for framebuffers. So to try and avoid any problems the current implementation errs on the side of caution – it will try and limit the maximum framebuffer size to 8MB, the maximum height to 4095, and the maximum number of screen banks to 7. Since you can’t tell RISC OS how many screen banks you want, the driver will allocate as many screen banks as possible while still fitting within those limits. I.e. screen_banks = max(1, min(8MB/screen_bytes, 4095/screen_height, 7)) So for 1080p you should have three screen banks in 256 colour modes (4*1080 > 4095), two screen banks in 64K colour modes (1080p @ 16bpp is just under 4MB), but only one in 16m colour modes. At some point I’ll have to take another look at the code and either see if there’s a better way of doing things, or start hassling the Pi firmware team about any firmware-related issues that are causing problems. |
Neil Fazakerley (464) 124 posts |
Thanks for the info Jeffrey. So is there any way to force the OS to ignore its assumed GPU limits (config/txt or whatever, as DavidS suggests)? Like most RO Pi users, my machine is dripping with unused memory. Looks like I need a minimum 12MB framebuffer to achieve triple banking in 64k colours. I take it 64k double banking isn’t much use, due to the way the Pi handles screen flyback/refreshes. It certainly produces lots of redraw flashes and tears on my machine. |
Jeffrey Lee (213) 6046 posts |
Not at the moment, no. |
Jeffrey Lee (213) 6046 posts |
Update: There’s been a firmware fix which has broken the logic which BCMVideo was previously using to determine the number of screen banks. However it’s also revealed the logic which the firmware uses to limit the virtual framebuffer size (and in turn the number of screen banks we can use). https://www.raspberrypi.org/forums/viewtopic.php?f=28&t=5851&start=475#p1105321 BCMVideo 0.43, which should appear in tomorrow’s ROMs, has been fixed to apply the same basic limit as the GPU. So the new calculation for max number of screen banks is: screen_banks = max(1, min((gpu_mem-23)*1024*1024/screen_bytes, max_framebuffer_height*2/screen_height) gpu_mem and max_framebuffer_height correspond to the values in config.txt, with defaults being 64 and 1200 respectively. So assuming gpu_mem is left at its default, you should be able to get three screen banks in 1920×1080 by setting max_framebuffer_height to 1620 or higher. (The gpu_mem check is something I added to try and avoid problems if people use a lower GPU memory limit than normal, e.g. 32MB) N.B. there’s also a bug with the latest firmware version that appears to stop hdmi_pixel_freq_limit from working: https://github.com/raspberrypi/firmware/issues/732 |
Neil Fazakerley (464) 124 posts |
Thanks for that Jeffrey: a happy accident that will mark a major improvement for Risc OS R-Pi animated graphics! |