PSRAM-less framebuffer strategy

[fcipaq]

Hi everyone,

I am very happy that I was able to grab on of the engineering-sample-ESP32-P4-Function-EV-Boards. And I am quite impressed by the power of the new uC.

I was able to get snes9x (a SNES emulator) running with ESP-IDF. While I got ~22 fps on an S3 (without frame dropping), I get around 55 fps on the P4.
Now, since the P4 came with a nice, hi-res MIPI display (with no internal FB), I wanted to stretch the image a little (pixel doubling). And this is where my problem lies:

From the emulator I get a pixel buffer (internal RAM). And writing that buffer strechted to the (PSRAM) framebuffer is super slow. Frame rate drops to about 50%. Now, I think it is not the best strategy to have a framebuffer in PSRAM when showing dynamic content that's changing every frame at 60 fps.
Now my question: How and where would I start if I wanted to use a line buffer (IRAM) that the CPU generates on the fly just ahead of the "beam" (maybe evoked by some kind of hsync interrupt). Would that be a feasable strategy? (Is this how the factory camera app example gets this super fast full screen refresh rates?)

Thanks in advance for any input!

[chegewara]

Hi,
do you mind to share snes code?

Im not sure it is what you are looking for but in menuconfig there is option:

Prompt: Select LVGL buffer memory capability

- PSRAM
- internal

[fcipaq]

Sure, I'll upload on Github in a couple of days (pretty busy week). It's based on github.com/ducalex/retro-go with very minor adjustments.

About LVGL: Thank you for the input, I'm however not using LVGL, just the driver that came with ESP-IDF.

[ESP_Sprite]

Not sure. The parallel RGB driver allows you to allocate a bounce buffer (effectively a line buffer, but it's usually a few lines to lower overhead) but I don't think the MIPI driver supports that yet.

[fcipaq]

Yeah, that's exactly what I had in mind (since I stumbled across this viewtopic.php?f=12&t=26793&start=10 thread a couple of days ago...
Maybe I'll just wait for the camera app example to get published (I was unable to find it). I mean, in that example the whole screen is updated with like 60 fps or so and that would be pretty fast with SPI flash in the middle.

[fcipaq]

Ok, I poked around in the esp_lcd driver a little. And I think this might be a feasible solution:

In esp_lcd_panel_dpi.c it is implemented that after a DMA transfer from the screen buffer to the display has completed, dma_trans_done_cb gets called back, which then rearms the DMA.
And I think it *should* be pretty straight forward, replacing the PSRAM buffers with IRAM buffers (each of them holding only a couple of lines). Then, when the DMA completes, dma_trans_done_cb needs to be modified so that it can swap a back buffer to the front (scanning out the new front buffer) and issue a semaphore, so the CPU can update the back buffer. This way, there would be no need for a full screen buffer.

I'll try this out and report back with the results.

[fcipaq]

The approach worked out. You can watch the results on Youtube: https://youtu.be/osw1QMM4Avs?feature=shared

In the link there's also a description to the Github Repo. Beware: it's hacky...

[chegewara]

Just an idea, did you try to run P4 with PSRAM clocked up to 200MHz?
Im not sure, but on P4 psram may be DMA capable, or at least you can caps malloc with DMA flag.

PS 200MHz is hidden, to enable it you have to use experimental features

[fcipaq]

Thanks for your suggestion. It already got the PSRAM running at 200 MHz. However to write the PSRAM I used the CPU (in a loop, hoping the cache would speed that up), because I wanted to stretch the image - so the data would be scattered and I'm not sure if the DMA is capable of doing that, I haven't looked into it.
At least I think this would not be trivial. You would need to double every pixel. And then scan out every line twice. And then respect the stride to the next line.

[chegewara]

Good job, and thanks for sharing code.