Strange graphic problem

[sakya]

Hi! :)

I'm experiencing a strange (at least for me) graphic problem.
I'm using OSLib MOD and I have some corrupted graphics.

Here's a screenshot:


The second and sixth line of stars are corrupted.
The really strange thing is that I use the same function to draw each line, and I load the image only once at the beginning of the program and never reload it.
Also: if i press down and select the second line the stars are drawn correctly.

How can the image be messed in a line and not in the next?
Can anyone help me find this bug, or point me in the right direction?
OSLib uses GU, has anyone ever had a problem like this?

Many thanks in advance.
Ciaooo
Sakya

[Torch]

Something like that happened to mine and I couldn't figure it out.
I finally deleted and rewrote most of the program to fix it. Then it happened again and I couldn't identify what I had done to screw it up.

I gave up and just used LUA's graphics.h because I was only going to render static images in 2D anyway.

[J.F.]

I'd suspect a cache problem - you might not be flushing the cache at the proper times.

[sakya]

Hi! :)

I'd suspect a cache problem - you might not be flushing the cache at the proper times.

Many thanks for the hint. :)

Since I'm not a GU expert (or expert in graphics in general), can you help me a little more? :)

Is sceKernelDcacheWritebackAll the functions that flush the cache (I think it is, from the comments in the header file)?
I searched the original OSLib source and this function is never called, while in intraFont is (and I included IntraFont in OSLib).
Is the cache flushed when I do GuFinish?

Code: Select all

sceGuFinish();
sceGuSync(0,0);

When I'm supposed to flush the cache?
And also (sorry for all these questions) how is this cache used? What does it cache and do I have some "control" over it?

Many thanks for your help

EDIT: In OSLib there are some cache functions like sceKernelDcacheWritebackInvalidateAll, sceKernelDcacheWritebackInvalidateRange...

Ciaooo
Sakya

[Insert_witty_name]

The Dcache (data cache) is a memory area (of high speed) located between main memory and the CPU that buffers data.

It basically buffers data to try and reduce the amount of slower reads and write to main memory.

If your problem is indeed cache related (and it would appear so) it is because the GE is reading an address that is cached and in a dirty state. ie. the data in the cache and the data in memory are different because the GE cannot access the dcache.

There is generally no need to writeback or invalidate the cache in your program loop, unless you are manipulating data the GE will access.

It would help to see any code that manipulates that texture in some way - whether it be the loading, swizzling or anything else.

The functions in OSLib that you list are correct, assuming they are implemented correctly.

[J.F.]

Adding to what witty said, you want to flush a range when it's small as that is faster and leaves things in the cache that should be there for speed. When I first started on Doom on the PPC, the difference between flushing the entire cache and flushing just what needed to be flushed was more than twice as fast. Generally, people flush the entire cache while they're still working on the program, and switch to flushing a range when they're ready to optimize.

I've seen a number of threads here on when to flush to keep your drawing intact. You might want to search on the flush command and read some of them.

[psPea]

Also you can do uncached writes(or 0x40000000 to your pointer) which eliminates the need to write back from cache.

[hlide]

Also you can do uncached writes(or 0x40000000 to your pointer) which eliminates the need to write back from cache.

which will be slower and unsure if cache still contains some references to the same memory place.

[J.F.]

Also you can do uncached writes(or 0x40000000 to your pointer) which eliminates the need to write back from cache.

which will be slower and unsure if cache still contains some references to the same memory place.

Remember to flush/invalidate the cache before writing to uncached space. If the memory is already cached, reading/writing that memory through uncached space will STILL use the cache until it's invalidated.

Also, use uncached accesses to large data arrays to avoid flooding the cache. This is especially helpful on programs that use the CPU for things like drawing. For example, Doom draws the screen with the CPU, and allowing it to draw to memory that is cached will flood the caches, causing Doom to run slower. Drawing to uncached memory leaves all the program data in the cache, allowing the program to run faster (the difference between 5 FPS and 150 FPS depending on the display being rendered).

[hlide]

Also you can do uncached writes(or 0x40000000 to your pointer) which eliminates the need to write back from cache.

which will be slower and unsure if cache still contains some references to the same memory place.

Remember to flush/invalidate the cache before writing to uncached space. If the memory is already cached, reading/writing that memory through uncached space will STILL use the cache until it's invalidated.

Also, use uncached accesses to large data arrays to avoid flooding the cache. This is especially helpful on programs that use the CPU for things like drawing. For example, Doom draws the screen with the CPU, and allowing it to draw to memory that is cached will flood the caches, causing Doom to run slower. Drawing to uncached memory leaves all the program data in the cache, allowing the program to run faster (the difference between 5 FPS and 150 FPS depending on the display being rendered).

humm, since PSP apparently uses a write-buffer internally when storing words in memory, i guess it would aggregate up to 16 words into the internal write-buffer then flush it at once in the uncached memory without polluting the data cache. As its write-buffer is the same size as the data cache-line, their write access time should be equivalent locally except that write-buffer doesn't invalidate data cache with a disastrous effect globally.

[sakya]

Hi! :)

Many thanks to all, I'll try to solve the problem. ;)

Ciaooo
Sakya

[Insert_witty_name]

Let us know how you get on sakya.

The cache issue and drawing comes up quite regularly and this would be a good reference thread if the problem is actually solved ;)

[fiorello]

I have the same problem but it's semms like the program reads image, and also images that are close to the right image and display them also