Frame Rate, Frame Sync, And Diagonal Tearing Occlusion


Exophase

Nothing good will ever come of Exophase.
Joined
Sep 21, 2006
Messages
10,307
Age
40
Location
Cleveland OH
Some numbers about the Wiz's video default video timings:

Horizontal clocks per line: 330
Lines per display: 335 (320 in active display, 3 in vertical sync, 7 from vertical sync to start of active display, 327 from start of vertical sync to end of active display.. there's probably a fudge factor of something else in there)
Frame period: 11.3167ms, measured with timers.

That gives a VCLK period of ~0.102367us, or 9.769MHz.. it's possibly really 10MHz take some roundoff.

This is 88.365 frames per second, which is not a good refresh rate for games. So I changed the number of VCLKs per horizontal line to 487 and got 59.89Hz, and waited for vsync on every frame. Good, except now the diagonal tearing was MUCH more noticeable. Like, on every frame.

So I figured I'd push my luck and try for 120Hz to get the best of both worlds. And sure enough, it seems to work fine. It's hard to tell if the diagonal tearing is better or worse than it was before - obviously it won't every go away completely. It's something that happens when the display update aligns with the OLED's refresh rate. If the OLED is being driven at 60Hz then I think something that's not a multiple of 60Hz will actually be better. Unfortunately, that doesn't synchronize well with games. I don't really know what the best solution is and will probably experiment more. Once we get something out of the way to eliminate landscape mode then things might be different.

If anyone wants to play around with it too, here are some register locations (offset from 0xC0000000)

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


Here's a wait for vsync:

CODE
void wiz_wait_vsync_poll()
{
while((wiz_reg16(DPC_CONTROL0) & (1 << 10)) == 0);
wiz_reg16(DPC_CONTROL0) |= (1 << 10);
}


I modified DPC_HTOTAL to change the number of clocks per line.
 
So how does OLED tolerate messing with display timings? F100 LCD starts showing faint diagonal lines or left border becomes a little brighter on certain timings.
 
notaz posted on May 29 2009 at 10:24 AM said:
So how does OLED tolerate messing with display timings? F100 LCD starts showing faint diagonal lines or left border becomes a little brighter on certain timings.
I have not seen any visual degradation at all at 120Hz. Maybe this can be chalked up to AMOLED's high response times.
 
Last edited by a moderator:
notaz posted on May 29 2009 at 11:24 AM said:
So how does OLED tolerate messing with display timings? F100 LCD starts showing faint diagonal lines or left border becomes a little brighter on certain timings.
I used your 120 Hz settings in the GP2X without problems :D .
 
Last edited by a moderator:
Why are you doing DPC_HTOTAL - 243? Just do 243...

wiz_reg16(DPC_HTOTAL) = 0xf3;

Like that.

You don't have to set the dirty bit in MLC for this to take effect, it has nothing to do with MLC.

If it doesn't work then GPH must have changed one of the other timing parameters, but I'm skeptical. You should print out what the current DPC_HTOTAL is though.
 
Only for reference the firmware 1.1.0 timing configuration is the next one:
- If i don't let the gp2xmenu to start: DPCHTOTAL=330 DPCHAEND=304 DPCVTOTAL=347 DPCVASTART=19 DPCVAEND=339 DPCCTRL0=37888 DPCCTRL1=8767
- After the gp2xmenu execution: DPCHTOTAL=327 DPCHAEND=277 DPCVTOTAL=341 DPCVASTART=17 DPCVAEND=337 DPCCTRL0=37888 DPCCTRL1=8767

It should be interesting to see such configuration in firmware 1.0.0 and 1.0.1...
 
Wonderful, they're changing the number of scanlines... probably best to go back to the 1.0.0 ones if someone has them.
 
firmware 1.0.0: DPCHTOTAL=330 DPCHAEND=304 DPCVTOTAL=335 DPCVASTART=7 DPCVAEND=327 DPCCTRL0=37888 DPCCTRL1=8767
firmware 1.0.1: DPCHTOTAL=327 DPCHAEND=277 DPCVTOTAL=341 DPCVASTART=17 DPCVAEND=337 DPCCTRL0=37888 DPCCTRL1=8767
firmware 1.1.0: DPCHTOTAL=330 DPCHAEND=304 DPCVTOTAL=347 DPCVASTART=19 DPCVAEND=339 DPCCTRL0=37888 DPCCTRL1=8767

Anyway the problem is not in these settings, it has to be other thing, because i have tested all these settings with DPCHTOTAL=243 in firmware 1.1.0 and it is not 120 Hz (it is 67 Hz aproximately) and some black pixels appear in the upper right part of the screen.
 
Anyway the problem is not in these settings, it has to be other thing
I think I've found that, it's the pixel clock divider (bits [9:4] of DPCCLKGEN0=31c4 register, program value-1). They are now using divider value 23, it was 15. Fw 1.1 settings + divider of 10 + DPCHTOTAL of 357 gives something pretty close to 120Hz. Curiously I was able to push OLED to something like ~180Hz, after that it started misbehaving.

What's annoying is that portrait mode ioctl reverts all settings back, you have to reprogram everything again..
 
Last edited by a moderator:
Anyway the problem is not in these settings, it has to be other thing
I think I've found that, it's the pixel clock divider (bits [9:4] of DPCCLKGEN0=31c4 register, program value-1"]. They are now using divider value 23, it was 15. Fw 1.1 settings + divider of 10 + DPCHTOTAL of 357 gives something pretty close to 120Hz. Curiously I was able to push OLED to something like ~180Hz, after that it started misbehaving.

What's annoying is that portrait mode ioctl reverts all settings back, you have to reprogram everything again..[/quote]It runs perfectly, and also the diagonal line is less noticeable. Thanks, Notaz, you are the man :lol: .
 
Last edited by a moderator:
Does increasing the frame-rate have any other effect on system performance?
ie. Because the video RAM is shared with the CPU, is there any extra bus contention?

Couldn't notice any difference at least for gpSP.

I've written a small tool for setting the timings, which can also be compiled into some program. It accepts timing parameters in a string, which it parses and writes to registers. The idea is to keep timing values outside of code (use config file, env variable, etc. instead), so that they can be changed without recompiling (in case GPH changes something or if it doesn't work for someone). I'm going to ship all my stuff with this, if anyone else wants to use it too it's here:
http://notaz.gp2x.de/misc/dev/pollux_dpc_set_r1.zip
 
Last edited by a moderator:
notaz said:
Couldn't notice any difference at least for gpSP.

I've written a small tool for setting the timings, which can also be compiled into some program. It accepts timing parameters in a string, which it parses and writes to registers. The idea is to keep timing values outside of code (use config file, env variable, etc. instead), so that they can be changed without recompiling (in case GPH changes something or if it doesn't work for someone). I'm going to ship all my stuff with this, if anyone else wants to use it too it's here:
<a href="http://notaz.gp2x.de/misc/dev/pollux_dpc_set_r1.zip" target="_blank">http://notaz.gp2x.de/misc/dev/pollux_dpc_set_r1.zip</a>

GPH should at least send you a bouquet or something; people are already reporting how using this totally removes the diagonal line in Quake 2 for example (where it was very noticeable) So thanks to you and whoever else looked into tinkering with the timings :)
 
Last edited by a moderator:
Back
Top