Graphic Filters

[CyberAxe]

just curious to why no one has attempted graphic filtering for the gp2x for when stretching or condensing games I'm sure its possible?

obviously it would slow things down and probably wouldn't be that much of a viable option until direct hardware access is granted I'd imagine so as to get full speed plus filtering?

of course i am only really referring to bi-linear filtering which is one of the quickest

 

[Hanz™]

I can imagine it wouldn't look that great, and would be slow.

 

[IanJ]

I can imagine it wouldn't look that great, and would be slow.

​

There's usually a whole 200Mhz of Arm940 goodness hanging around that could do this This is exactly what I'm working on for my Archimedes Emulator.

 

[Squidge]

Filtering the screen would be slow unless the emulator run well in advance of full speed.

Using the 940 for the task generally isn't practical, as the screen is 150KB, and the 940 only has a 4KB cache, so it'll spend most of it's time fighting the 920 for control of the data bus to main memory. It'll be quicker to use the 920 for the job in most cases.

 

[lucoxade]

Only the GameBoy realy needs a nicer rescaling and that runs pretty fast already. I hope it gets done.

 

[DaveC]

Yeah I would like it for gameboy. I wouldn't use it in other emulators but Gameboy is a bit too small at 1:1.

 

[Hanz™]

Only the GameBoy realy needs a nicer rescaling and that runs pretty fast already. I hope it gets done.

​

Ah yes that is true. I thought someone was suggesting it for snes or genesis or something.

 

[Radek]

Filtering the screen would be slow unless the emulator run well in advance of full speed.

I have to disagree here if we are talking about such things like supersampling/downsampling. At 4x ratio it should not be slow at any means. Heck there is already one game what it's doing it. Even my demo move over 100MB/s of data, process it and have some cycles left.

Using the 940 for the task generally isn't practical, as the screen is 150KB, and the 940 only has a 4KB cache, so it'll spend most of it's time fighting the 920 for control of the data bus to main memory. It'll be quicker to use the 920 for the job in most cases.

​

Let see... 150KB of data to process and 4KB of cache. Load/store bandwitch can be around 100MB/s when using ldm/stm. So 37.5 bulks to load and store * 30fps = 9MB/s and 6.666 mips to process one frame. That's over 80 machines cycles per every pixel. It looks doable for me.

Of course all that loading and processing data in bulks (scanlines, tiles, whatever only not random jumping using str/ldr). The manual locking the caches will help too.

It can be done like so (I was using scanline rendering aproach in my demo) and there some commercial examples of it as well. The PowerVR based 3d accelerators for an example. I have one (thought I'm not using it now) and it works very well thought might be tricky to implement.

 

[GpDogg]

for me, i much prefer seeing all the detail. Filtering is good for a pc monitor, i.i nes emulation in salx2 for example, it looks like a smooth painting!
But generally this eats the memory and cpu power a lot more.

If i could have SALx2 etc etc for a nes emu etc (you know, for older blockier games) that would be sweeeeet. but filtering for games with text? no fanx.

haha arkanoid would look like ur exploding coloured balls, not bricks haw haw haw!!

 

[Squidge]

What I'm thinking of is this:

[920]
Normal rendering -> hardware buffer -> LCD.
Normal rendering -> filtering -> hardware buffer -> LCD.

[920/940 Combo]
Normal rendering -> highmem memory buffer -> hardware buffer -> LCD.
Normal rendering -> highmem memory buffer -> filtering -> hardware buffer -> LCD.

With just the 920, you can filter your buffer and output direct to (unbuffered/uncached) LCD buffer.

With the 940, you have to render to (unbuffered/uncached) highmem, and then the 940 has to read the same data, and output that data to LCD. This would save CPU cycles, but it would be at the expense of higher memory bus utilisation. I think if the highmem could be cached for the 920, then it would be advantageous for the graphics filters, but it seems that it could actually be slower otherwise (due to higher memory bus usage).

 

[Radek]

What I'm thinking of is this:

[920]
Normal rendering -> hardware buffer -> LCD.
Normal rendering -> filtering -> hardware buffer -> LCD.

[920/940 Combo]
Normal rendering -> highmem memory buffer -> hardware buffer -> LCD.
Normal rendering -> highmem memory buffer -> filtering -> hardware buffer -> LCD.

With just the 920, you can filter your buffer and output direct to (unbuffered/uncached) LCD buffer.

With the 940, you have to render to (unbuffered/uncached) highmem, and then the 940 has to read the same data, and output that data to LCD. This would save CPU cycles, but it would be at the expense of higher memory bus utilisation. I think if the highmem could be cached for the 920, then it would be advantageous for the graphics filters, but it seems that it could actually be slower otherwise (due to higher memory bus usage).

​

In my demo I'm touching the framebuffer only once at only one scanline at time - for final write. So all intermediate results can fit in cache and I was using all registers (except the r13 and r15 for obvious reasons) to load/store via ldm/stm as many 32 bit words as possible (typicaly 8 for one pass). In effect the memory load was reduced dramatically, there isn't need for double buffering and with overdraw of 8 layers spanning the whole screen it can push over 30fps without problems at 16bpp.

Even at 60fps it's only 150KB * 2 * 60 = 17.5MB/s so it should not be problem to pass the data to 940T and get it back.

The icache on the 940T is 4K so it's 1K of Arm opcodes and twice that in thumb mode. It's lots of instruction for handcoded assembler. And according to the docs (there are even examples) the caches for 920T/940T can be controlled directly with locking up capability. I can imagine it could be used to significant advantage too as the programmer has much better clue what the code is doing that the cache controller can.