Copy 320X240 Buffer To 240X320 Screen


Alex. said:
Contiguous reads doubled the speed, terrific :) And Notaz's mmuhack is brilliant, I get an extra 30 fps in 320x240 mode, and 8 fps in 240x320.

But now tear runs at 170 fps, and no-tear runs at 88. I tried removing the inner loop and use macros like KungPhoo, but that actually makes it a little slower.

Code:
Uint16* dst = (Uint16*)a_screen->pixels + WIDTH * HEIGHT;
const Uint16* src = a_pixels;

for(int i = HEIGHT; i--; dst += WIDTH * HEIGHT + 1) {
    for(int j = WIDTH; j--; ) {
        dst -= HEIGHT;
        *dst = *src++;
    }
}

Would be interested in why the loop might be faster than the manual unroll. Can someone check the ASM produced?
 
Last edited by a moderator:
crow_riot said:
here u go: http://www.gp32x.de/board/index.php?/topic/48042-mmuhack-as-kernel-module/page__hl__mmuhack


Code:
	g_dev_mem = open("/dev/mem", O_RDWR);
	g_memregs16 = (volatile unsigned short*)mmap(0, 0x20000, PROT_READ|PROT_WRITE, MAP_SHARED, g_dev_mem, 0xC0000000);

	void wiz_wait_vsync_poll()
	{
		typedef enum
		{
			DPC_HTOTAL     = 0x307C,
			DPC_VTOTAL     = 0x3084,
			DPC_VSWIDTH    = 0x3086,
			DPC_VASTART    = 0x3088,
			DPC_VAEND      = 0x308A,
			DPC_CONTROL0   = 0x308C
		} wiz_dplc_regs_enum;

		while((g_memregs16[DPC_CONTROL0] & (1 << 10)) == 0);
		g_memregs16[DPC_CONTROL0] |= (1 << 10);
	}

Does not work for me. Freezes the device.
 
Last edited by a moderator:
[quote name='KungPhoo' date='18 December 2009 - 02:41 PM' timestamp='1261143688' post='788630'


Does not work for me. Freezes the device.
[/quote]

can only think of firmware issues, iirc the timing is different with different firmware versions. never tried that by myself though. best to try with 1.1.0 :)
 
KungPhoo said:
Would be interested in why the loop might be faster than the manual unroll. Can someone check the ASM produced?

More icache misses on the first iteration. Especially with the compulsary dcache misses interleaved. There would be potential for more TLB misses. These differences would be pretty minimal though.

KingPhoo said:
Does not work for me. Freezes the device.

Did you make g_memregs16 volatile?
 
Last edited by a moderator:
News from ikari:

http://dl.openhandhelds.org/cgi-bin/wiz.cgi?0,0,0,0,23,271
 
Thanks everybody! Now I've successfully modified SDL library to eliminate diagonal tearing with it.
http://dl.openhandhelds.org/cgi-bin/wiz.cgi?0,0,0,0,46,272
 
Nice job, ikari. :) I quickly tried a few SDL applications (Wind and Water, Gianas Return, Blix2x, Sqdef, X-com, Scumm) and they all seem to work without problems. Even Fenix games seem to work with this library (I tried Snake on Dope)
You can see a little performance loss with some demanding apps (Gianas Return, Scumm).
 
ikari; Do you think you'd be able to modify SDL to also allow 240x320 access for those who want to handle the orientation themselves?
 
KungPhoo said:
notaz said:
KungPhoo said:
Does not work for me. Freezes the device.
Since g_memregs16 is a pointer to shorts, you need to divide all addresses by 2.
I don't understand that?
Just replace all g_memregs16[DPC_BLABLA] with g_memregs16[DPC_BLABLA / 2] (or g_memregs16[DPC_BLABLA >> 1] if you prefer shifting).
 
Last edited by a moderator:
Exophase said:
ikari; Do you think you'd be able to modify SDL to also allow 240x320 access for those who want to handle the orientation themselves?
Exophase; Well, I'm not sure. But I'm also working about it. Currently I'm replacing "/dev/fb0" to "/dev/mem" for full hardware access.
 
Last edited by a moderator:
Will this new version of the sdl library also work on emulators like vice, uae4all and such and remove the tearing?

Regards

André

PS. Just tried on the amiga emu and the tearing is removed in the menu but the games are rotated 90 degrees.
 
ikari said:
Exophase; Well, I'm not sure. But I'm also working about it. Currently I'm replacing "/dev/fb0" to "/dev/mem" for full hardware access.

Be sure to use mmuhack as well.
 
Last edited by a moderator:
Tearing when waiting for vblank!!

AHHH! Now I'm waiting for the vblank to finish and then do the flip. However, the flip takes longer than the vblank, thus I get a tearing now on this position:
tnvblank.png
I'm using /dev/fb0 btw.
 
This is probably a completely stupid question/idea, but why not use a 3D surface of 320x240 & use the 3D hardware to blit that one rotated 90°?
This way you can still use a framebuffer (that you memcopy to the texture of your surface) and don't have to rotate anything by hand.
 
Amon_Re said:
This is probably a completely stupid question/idea, but why not use a 3D surface of 320x240 & use the 3D hardware to blit that one rotated 90°?
This way you can still use a framebuffer (that you memcopy to the texture of your surface) and don't have to rotate anything by hand.

http://www.gp32x.de/board/index.php?/topic/50916-tissuegl/
 
Last edited by a moderator:
KungPhoo said:
Tearing when waiting for vblank!!

AHHH! Now I'm waiting for the vblank to finish and then do the flip. However, the flip takes longer than the vblank, thus I get a tearing now on this position:
tnvblank.png
I'm using /dev/fb0 btw.

You have to start using double buffering, meaning you probably can't use /dev/fb0 anymore. Use or look at the code for libcastor.
 
Last edited by a moderator:
KungPhoo said:
Tearing when waiting for vblank!!

AHHH! Now I'm waiting for the vblank to finish and then do the flip. However, the flip takes longer than the vblank, thus I get a tearing now on this position:
tnvblank.png
I'm using /dev/fb0 btw.

i don't know if it is an option for you, but did you try "tissueGL" (http://www.gp32x.de/board/index.php?/topic/50916-tissuegl/) lib?
 
Last edited by a moderator:
Back
Top