forums.ps2dev.org

[Bluddy]

I'm dealing with what has to be one of the most annoying, stubborn bugs I've ever had. Every time I think I got it, it goes away and then comes back later. I'm going over everything with a fine-tooth comb and I just can't get to the root of the problem.

The problem is that I get BAD flicker, but only sometimes. In fact, I can get to a situation where I'll link, get no flicker, then I'll add a couple of C++ instructions, compile, link, and get flicker.

Here's the relevant code. I'm posting everything related to graphics since I'm really getting desperate with this bug.

[Bluddy]

OK I see there are no takers. Sorry for now putting the code in a proper box.

Let me add a couple of things I've figured out through my investigations: the code can run either in 320x200 mode (which is usually adjusted to be fullscreen on the PSP) or 640x480 mode (which is shrunk to fit using the GE). In 320x200 mode, I get flickering black horizontal stripes on the screen -- sometimes all the time, sometimes every few seconds, sometimes at the bottom of the screen and sometimes at other locations, though almost never at the top.

In 640x480 mode something more interesting happens: notice that we have to render twice with 512x512 pixel textures. I also get flickering here, but also, the second render (that's shifted right 512 pixels) gets the main picture but also a faint leftover of the first texture rendered! It's as if it didn't manage to write fully, perhaps because of a cache problem?

I know that the updates to the _offscreen texture (done in copyRectToScreen) are fine -- very few of them happen relatively.

Another thing I noticed is that I can make the problem go away by creating a global array. An array of char[30] will often shift *something* enough to 'fix' the problem. This is obviously very strange.

My guess is that it's some kind of cache problem, which is why moving some data helps -- we're moving to a different line in the cache. However, I went over the code several times and I can't find any specific cache problem. Adding a cache invalidate before writing the display list also didn't help.

Another guess is that it may be related to refresh issues. Perhaps for some reason I'm not really synchronized with vsync (even though I do wait for it)?

I've also tried moving the frame buffers in vram so they're not next to each other, and so they're in different locations, just in case something was creating a cache coherency problem on those specific addresses. It also doesn't help.

I'd really appreciate people's input.

[J.F.]

Well, you could edit the post and put it in code tags. :)

Try flipping these two lines around

[Bluddy]

Tried swapping the lines. It didn't work, but thanks for the idea.

[cory1492]

Have you tried different alignment size for your __attribute__ declarations? I see you are aligning to 64 in memalign, but only 16 in __attribute__. Not that it will actually fix the problem, though perhaps one of those is copied from in (for example) u32 but instead assembles to/winds up copying in two u16 chunks making it seem somewhat random from build to build.

[Bluddy]

Cory, it used to be aligned to 16 -- I just raised it to 64 thinking it might fix the problem.

Here's some more info, courtesy of ld's mapfiles and ld scripts among others:

First of all, I can rule out the vsync idea. I tested to see what a forced vsync-less refresh looks like, and it looks nothing like the symptoms I'm experiencing and more like screen tearing.

Now, modifying the program and checking the value of the _end symbol, I find the following pattern:
08b44694 - ok
08b44914 - bad
08b44c94 - good
08b44cd4 - good
08b44d04 - good
08b44e14 - bad
08b44e54 - good
08b44e94 - good

Notice that only a value of _end with a 14 in the end seems to cause a problem. All other values are fine. In case you were wondering, the default loader script forces a 4 byte alignment on the _end symbol.

Playing around some more, I find that moving the following symbols causes the trouble:

[Jim]

Your problem description sounds like a cache problem. Don't you need to flush the dcache between setting the vertices and passing them to the sce functions?

Jim
_________________
http://www.dbfinteractive.com

[Bluddy]