forums.ps2dev.org Forum Index forums.ps2dev.org
Homebrew PS2, PSP & PS3 Development Discussions
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Strange graphic problem

 
Post new topic   Reply to topic    forums.ps2dev.org Forum Index -> PSP Development
View previous topic :: View next topic  
Author Message
sakya



Joined: 28 Apr 2006
Posts: 190

PostPosted: Wed Jun 04, 2008 11:38 pm    Post subject: Strange graphic problem Reply with quote

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
Back to top
View user's profile Send private message Visit poster's website
Torch



Joined: 28 May 2008
Posts: 842

PostPosted: Fri Jun 06, 2008 2:22 am    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
J.F.



Joined: 22 Feb 2004
Posts: 2906

PostPosted: Fri Jun 06, 2008 3:33 am    Post subject: Reply with quote

I'd suspect a cache problem - you might not be flushing the cache at the proper times.
Back to top
View user's profile Send private message AIM Address
sakya



Joined: 28 Apr 2006
Posts: 190

PostPosted: Fri Jun 06, 2008 3:45 am    Post subject: Reply with quote

Hi! :)

J.F. wrote:
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:
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
Back to top
View user's profile Send private message Visit poster's website
Insert_witty_name



Joined: 10 May 2006
Posts: 376

PostPosted: Fri Jun 06, 2008 4:09 am    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
J.F.



Joined: 22 Feb 2004
Posts: 2906

PostPosted: Fri Jun 06, 2008 5:42 am    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message AIM Address
psPea



Joined: 01 Sep 2007
Posts: 64

PostPosted: Sat Jun 07, 2008 3:03 pm    Post subject: Reply with quote

Also you can do uncached writes(or 0x40000000 to your pointer) which eliminates the need to write back from cache.
Back to top
View user's profile Send private message Yahoo Messenger MSN Messenger
hlide



Joined: 10 Sep 2006
Posts: 750

PostPosted: Sat Jun 07, 2008 7:58 pm    Post subject: Reply with quote

psPea wrote:
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.
Back to top
View user's profile Send private message
J.F.



Joined: 22 Feb 2004
Posts: 2906

PostPosted: Sun Jun 08, 2008 2:39 am    Post subject: Reply with quote

hlide wrote:
psPea wrote:
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).
Back to top
View user's profile Send private message AIM Address
hlide



Joined: 10 Sep 2006
Posts: 750

PostPosted: Sun Jun 08, 2008 3:19 am    Post subject: Reply with quote

J.F. wrote:
hlide wrote:
psPea wrote:
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.
Back to top
View user's profile Send private message
sakya



Joined: 28 Apr 2006
Posts: 190

PostPosted: Mon Jun 09, 2008 7:51 pm    Post subject: Reply with quote

Hi! :)

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

Ciaooo
Sakya
Back to top
View user's profile Send private message Visit poster's website
Insert_witty_name



Joined: 10 May 2006
Posts: 376

PostPosted: Mon Jun 09, 2008 9:39 pm    Post subject: Reply with quote

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 ;)
Back to top
View user's profile Send private message
fiorello



Joined: 21 Jun 2008
Posts: 14

PostPosted: Sun Jun 22, 2008 8:17 am    Post subject: Reply with quote

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
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic    forums.ps2dev.org Forum Index -> PSP Development All times are GMT + 10 Hours
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group