Caanoo / WIZ Demistifying the screen tearing issue


Exophase

Nothing good will ever come of Exophase.
Joined
Sep 21, 2006
Messages
10,307
Age
40
Location
Cleveland OH
I started this topic so we can possibly try to figure out exactly why the screen tearing issue occurs in "landscape mode" and if anything can be done to fix or diminish it.

I don't know yet if I should post the datasheets for the OLED controller and OLED panel itself used in the Wiz (I don't think the latter is relevant). For now I'll just talk about a few things that I've found in it that I think might be causing it.

The OLED controller has a 240x320 framebuffer. You have to write to this every frame. It seems the way it performs rotation is in the addressing of how this framebuffer is filled. You can set the writes to this framebuffer to increment line by line then pixel by pixel instead of pixel by pixel then line by line. Actually, there are 8 ways you can do this, depending on whether or not you want to go left to right or top to bottom in either portrait or landscape mode. It seems like there may also be another way to do rotation, the documents are not clear.

The controller only has one framebuffer. What this means is that you have to race the display so that you only write over areas that have already been read from for that frame. Normally, if the interface to the OLED controller is faster than the OLED's dot clock (it usually is) then you start writing at the beginning of vsync, giving you some lines before the display starts, and by the time the framebuffer is being read from it'll be well behind the areas you modified, and it'll never catch up.

This is fine if you're writing in the same order the screen is reading from. But if you're writing in a different order then you may be writing to areas that have already been displayed for that frame. I think that this is the cause of the tearing problem.

Operating in portrait should fix this, as reported. And yet, EvilDragon claims that there are still tearing issues in some circumstances. In fact, from what he described, it sounds like the "tearing line" may have been rotated. This suggests that the setup may still not be correct, or that the timing is off (not starting at vblank).

There'd be no issues if the vblank period (only back porch, although front porch + back porch would be nicer) was long enough to copy the entire screen. Unfortunately, this doesn't appear to be the case, as vblank can only be 16-20 lines, suggesting that the display is 360 lines tall internally. The Pollux documents suggest that a 40MHz dot clock is used, and 240 * 320 pixel need to be transferred. Maybe if it were capable of maxing out the DDR interface, ie 266MHz, then it could be just about fast enough. I doubt it could go this high though. I don't know if it can go higher than 40, and I don't know yet what the limitations on the controller are.
 
so its sound like the screen and the buffer writes need to be synced somehow. A version of the kernel was made public at one point have you looked at that for clues on how gph/mes are doing it now?
 
Well talked about this serval times with GPH, they SAY it is solvable if the SDL manual etc comes out...
They are aware of the problem, but continue to say it something to solve with a software fix, not in their roms, but an extra feature when compiling a app or game.
 
Their solution is just a workaround, they havnt ever explained the root cause of the tear. Exophase's purpose of this thread is to find the real problem and determine a proper fix for it. Which is the proper way to do things.
If GPH really wants us to use the workaround they need to explain in all the technical details why the workaround is needed, which makes us wonder, do they even know, are they just using anything that works.
 
Unfortunately I can't think of a possible fix. The OLED controller dictates an even lower transfer speed (clock of 85ns, so it needs at least 6.528ms for a frame's worth of data). With the writes rotated you're going to be touching both read and unread data no matter where you start the transfer.

At first it seemed like it'd be possible to tweak the horizontal and stride values in order to get rotation out of the media layer controller on the Pollux. Unfortunately this just produces garbage, as both Orkie and I have confirmed. I'm guessing that MES just failed to document the usage limitations of the strides.

So we're back to square one. AMOLED appears to be driven an entire scanline at a time so I don't think a controller could hide it any other way. I don't think there's going to be a way to do this 100% for free.

I'm willing to accept using OpenGL ES to rotate things, but I don't want to have to use GPH's SDL to do it.
 
I think I speak for a lot of people when I say that it's a damn shame.

I was watching the new wiz videos on youtube and was able to see the tearing several times. Normally I'm not bothered by errors like this, so I don't think it's exactly a deal breaker, but still it's a shame.

Perhaps someone could explain what the problems are with using GPH's SDL? Does it work will all the bindings for other languages (pygame et al)?
 
I've been looking at all the videos I can find of the Wiz so far... Is it just me or does the flash menu also show this diagonal tearing when switching from one directory to another or starting an application etc.?

Regards

André
 
Okay, some things I found out while looking for the tearing:

* It's most visible when the screen fades (whether it fades to black, from black or to another picture doesn't matter).
* It's also visible when using vertical scrolling (try to play Rainbow Islands on MAME).
* It's also visible (but not that much) when using horizontal scrolling.

I also do think the best thing is using OpenGL ES to rotate the screen by hardware. Otherwise the software will be slowed down a lot...
 
So what is GPH's plan? Will the OpenGL rotation be handled on a firmware level for all SDL apps, or will each application need to explicitly call some SDK function that does this?
 
Alex said:
So what is GPH's plan? Will the OpenGL rotation be handled on a firmware level for all SDL apps, or will each application need to explicitly call some SDK function that does this?

I don't think any of us are going to be using an "SDK" provided by GPH. "All SDL apps" is not enough - a lot of apps won't use SDL and if GPH doesn't fix some of the bugs in theirs then a lot that are using SDL won't be using theirs. We should have the option of dealing with this individually, but someone will probably come up with canned code to do the rotation. In my opinion it's overkill to use OpenGL ES for this when there's documentation on how to access the 3D chip directly. Maybe I'll try to come up with code for doing this.

One hidden benefit of this approach is that you no longer need mmuhack since you wouldn't be writing straight to an mmap'd framebuffer. It'll also let you do scaling with bilinear filtering as part of the process, so we're going to need that anyway. It should be reasonable to include this in SDL, so that if you set a screen surface to whatever resolution it scales and rotates it to fill the screen, but I'd prefer if there SDL options for how to handle scaling. That is, if you want to preserve aspect ratio, cut off part, use filtering or not, etc.
 
I am trying to understand what this tearing thing is (and there aren't windows toolchain yet to try out some test, maybe I'll boot up some linux soon and see).

The screen is retraced vertically thing, is it like GP32 (back to the past?) where writting serially to the video ram would result on writting pixels vertical and moving on to the next rows, instead of lines?

So, is the tearing problem a fact that while the screen is retraced vertically, the libs are writting serially horizontally? So, if I got a pointer to the framebuffer and wrote in the same way as the screen retraces would that solve the problem?

Or is it something worse that has to be solved with hardware?
I remember that my sprite/polygon functions on GP32 were written back in time in the way that the serial buffer and retrace were expected to, e.g. vertical scanlines instead of horizontal to fill a polygon, etc. Not good if you are porting stuff from SDL, but is it that simple? Or is it worse?

Maybe I should just try soon..
 
It's not the libraries writing in the perpendicular direction, it's the hardware. Specifically, the LCD controller itself is advancing its write pointer that way.

You can change the LCD write direction through an ioctl to the video driver in Linux (/dev/fb0). Then you have to deal with a 240x320 display like with the GP32. Changing a program to behave this way naturally can be difficult, so people right now are handling it by doing a separate pass afterwards, which probably costs at least 1-2ms per frame. A lot of people have mentioned using the 3D hardware to perform the rotation for you, but doing it in OpenGL ES without a speed hit comparable to (or greater than) software rotation may not be trivial, if possible.

I personally would like to hit the 3D hardware directly, but since my Wiz is bricked right now I can't do much about it >_>
 
I personally would like to hit the 3D hardware directly, but since my Wiz is bricked right now I can't do much about it >_>
Hi Exophase! It's a pity your Wiz is still bricked. :(
Do you take into consideration to ask/send the Wiz to EvilDragon? Perhaps he can repair or exchange the unit.

Regards,
Stephan
 
sbock said:
I personally would like to hit the 3D hardware directly, but since my Wiz is bricked right now I can't do much about it >_>
Hi Exophase! It's a pity your Wiz is still bricked. :(
Do you take into consideration to ask/send the Wiz to EvilDragon? Perhaps he can repair or exchange the unit.

Regards,
Stephan

It can be repaired with the BoB plus software, it's just software that doesn't exist. Or if it exists, is not publicly available.

I think it can be rigged with U-Boot if the MMU is setup to reswap the "shadow" region so that the boot flash is in the correct region. I'm going to try writing up something to do this when I have time, it's just not a perfectly trivial thing to do, unfortunately. It's especially complicated by the fact that the patch code that'd be ran has to be executing in a region that's NOT swapped out, same with U-Boot itself. If the U-Boot code/memory environment overlaps with flash then I'll be especially screwed, although I think I'll be okay because what I saw in that area was the UART bootloader which should be no longer needed at that stage.

This is all assuming that their U-Boot (polluxb) is properly configured to successfully program the boot flash in the first place. I'm going to assume it is since it has the options.

All this would be much easier if they'd make the U-Boot source easily available like they're required to. I haven't checked mainline but I very strongly doubt that their changes are in there, especially their most recent.
 
I see. Good luck! :)

BTW. The Propis demo seem to use OpenGL for screen rotation. I wrote a post about it on gp32x.de...
 
Last edited by a moderator:
sbock said:
I see. Good luck! :)

BTW. The Propis demo seem to use OpenGL for screen rotation. I wrote a post about it on gp32x.de...

I'll check there about it, thanks.
 
Last edited by a moderator:
Have you guys seen PicoDrive? No diagonal tearing at all, fading up/down, not even when the screen is scrolling at great speed.
It does not use SDL for the video stuff. it's using functions from picodrive-src/platform/wiz/gp2x.h

I haven't gotten around to playing with it yet, but it might be what we need to eliminate the tearing (maybe patch sdl?)
 
Back
Top