Looks nice. I'll try to implements the scaler in Xargon as a POC.I wanted to try a different approach so I first took hq2x (running on cpu) and optimized it (using some ideas from dsp version and using arm/neon assembly).
The unoptimized version takes 38.6 ms to scale 320x240 16-bit image. The optimized version takes 16.5 ms. The optimized source is in the attachment, in case someone is interested.
Then I rewrote the dsp version to work from bottom to top (instead of from top to bottom like the arm version).
Afterward I let the dsp and arm version run in parallel, stopping when they met somewhere in the middle.
The resulting time was about 8.5 ms to scale the image. Adding the time to invalidate caches and copy the result from dsp version to form a full scaled image, the result was about 10.5 ms.
At 60fps that's still not really useful on original Pandora (leaving about 5ms per frame for the rest of the program), but you could make an easily used library which hides (almost) all dsp work from the programmer.
It also shows that the task running on dsp doesn't have to be a separate task running asynchronously from the main cpu - in some cases you can split your data in two parts and process them in parallel (on dsp and the main cpu).
View attachment 12374
Well, I'll start with the full arm, than I'll contact you for the arm+dsp version.
I can change it to use the same prototype, I can change it to use the same palette format (array of 256 32-bit values, upper 16 bits are zero), I can relax the restriction that width must be divisible by 4, but adding it to the bundle - no.
What's wrong with OMAP3's scalers compared to GP2X one? They can also downscale.Part of me kinda misses the GP2X hardware scalers just for transparency sake... would love to see a scaler that could be used to resize BOR mods made for PSP to the Pandora resolution, but now that I think about it, might be better off seeing how it's implemented in ppsspp and maybe working from there as it's not an integer scaling.
http://notaz.gp2x.de/cgi-bin/gitweb.cgi?p=sdl_omap.git;a=blob;f=README.OMAP;hb=HEADNotaz: I might just not be t3h ub3r n3rd enough to fully understand the Pandora hardware still, just remember that Paeryn's SDL (I think...) could init to whatever resolution I threw at it, then even zoom in/out on stuff on demand if/when I wanted Omap3's scalers may be perfectly capable of this, but I'm not sure how to do this myself...
The GP2X did have a fine scaler but only for a YUV layer and I don't think I ever got around to supporting it, the RGB scaler was a basic coarse one. By the looks of if to change the scaling on notaz's you change the env_var SDL_OMAP_BORDER_CUT and/or SDL_OMAP_LAYER_SIZE and re-call SDL_SetVideoMode(). My method worked nicely since I didn't have to go through the display driver (I just set the hardware registers directly) and was based on code I wrote outside of SDL. Though notaz's use of env_vars is a better way to add the functionality rather than my hack of adding extra functions.Notaz: I might just not be t3h ub3r n3rd enough to fully understand the Pandora hardware still, just remember that Paeryn's SDL (I think...) could init to whatever resolution I threw at it, then even zoom in/out on stuff on demand if/when I wanted Omap3's scalers may be perfectly capable of this, but I'm not sure how to do this myself...
Exophase: you're probably right there, fairly certain that it was just a coarse scaler...