Running scalers on DSP

[M-HT]

A minor optimization in the version using cpu and dsp.

The results (320x240) are now:
hq2x 16 to 16 - 9.9 ms
hq2x 8 to 16 - 9.7 ms
hq3x 16 to 16 - 13.6 ms
hq3x 8 to 16 - 13.5 ms

View attachment hqx-dsp+arm.zip

 

[_jr_]

It's probably obvious, but I have no experience with the DSP. If one uses enough buffers, could the DSP version scale in parallel to my app rendering? E.g. with 4 buffers, two for rendering and two for displaying each, could the DSP scale from the just rendered to the not displayed buffer, giving free scaling (at the cost of triple buffering latency)?

 

[notaz]

If your DSP scaler is fast enough, sure. But there is a cache problem, you have to get ARM to write out the data from it's cache into the shared memory and that is quite expensive operation.

There is a workaround of marking the memory write-through cached, but then your renderer will suffer if it does a lot of processing because ARM will be forced to send each write to RAM instead of just doing everything in it's much faster cache.

 

[_jr_]

Thanks! Since I'm too stupid to find the data: how long would the cache flush take for a 320x240x16 bitmap?

 

[levi]

You don't have the flush the bitmap.  You (ideally) just have to flush the data cache, because that will be full of the last cache size of bitmap that you wrote, but if you tell the DSP to work on the bitmap before you flush that cached data out, the last cached bit will still have the old data in it.

I don't know how big the D cache is on the A8 chip, but traditionally it's a matter of kilobytes.  Not nearly big enough for a full-screen bitmap.  But accessing non-cached memory is slow, so flushing that many bytes is also a bit of a drag.  I'm not sure how many bits can be written at the same time, but if it has to be done 32-bits every RAM tick, that's a long way off the hundreds of MHz the CPU runs at on cached instructions.

 

[_jr_]

Well, the bitmap will be around 150K if I calculated correctly. I think the DM3730 has a larger cache. 256K? Is it only possible to flush the whole cache? How fast is writing back the cache? 10 MB/s or 100MB/s? It's probably all on TI's site, but these modern CPUs are too difficult for my 6502 training

 

[PokeParadox]

A minor optimization in the version using cpu and dsp.

The results (320x240) are now:
hq2x 16 to 16 - 9.9 ms
hq2x 8 to 16 - 9.7 ms
hq3x 16 to 16 - 13.6 ms
hq3x 8 to 16 - 13.5 ms

View attachment 27396

The ".out" is the precompiled binary for the DSP?
In which case could you give an "idiots" guide on how to try using this without having to install the TI compiler?

 

[M-HT]

Short instructions:

The code needs c64_tools by bsp to compile.
Directory 'dsp' contains code that runs on the dsp - the compiled version is in the 'bin' directory (file hqx_dsp_area3.out), so you don't need the TI compiler.
Directory 'dsp' contains code that runs on the cpu.
Directory 'include' contains file you should include in your program (dsp_hqx.h) - it contains the exported functions.

At the beginning call dsp_hqx_initialize(maxwidth, maxheight) to initialize the dsp and the scalers; the file hqx_dsp_area3.out must be in the current directory; maxwidth and maxheight is the max resolution of the scaled image; maxwidth is limited to 32-320.

At the end call dsp_hqx_deinitialize() to deinitialize the dsp.

The scaling functions are dsp_hq2x_8_16, dsp_hq2x_16_16, dsp_hq3x_8_16, dsp_hq3x_16_16. The parameters are the same as my neon scalers.