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 

What graphics operations work on system memory?

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



Joined: 22 Feb 2004
Posts: 2906

PostPosted: Wed Nov 07, 2007 7:43 pm    Post subject: What graphics operations work on system memory? Reply with quote

I was looking at the fact that 720x480 uses too much memory to fit in EDRAM, so I was playing around with trying to do GU operations to system memory. While Copy Image works, GU Draw doesn't. It looks like the target of rendering operations HAS to be in EDRAM. Is this really the case? What operations are allowed with system memory as the destination?

Currently, my rendering is stuck with one 768x448 buffer with a Z buffer. That BARELY fits into EDRAM, and then I can blit the EDRAM buffer to the frame buffer in system memory. Assuming you HAVE to keep the destination in EDRAM I was thinking of going to a 768x240 buffer. That would leave me with EDRAM left for caching textures. It would also make it easier to support interlaced displays. Non-interlaced: do two blits with line width twice as wide as it really is to space the lines out. Interlaced: do two blits, one to each half of the frame as they're already separate. So each case is easily handled by two blits. You get half the vertical resolution, but at least it's full-screen.

EDIT: One caution about doing the "twice the line width" blits - the maximum x and y values are 1024. While the line width for source and dest can be bigger, the moment the x hits 1024, the blit transfers the data wrong. So don't offset the odd field by an x of 768 with a width of 1536. That doesn't work. You have to offset the source pointer by 768*4 and use an x of 0 and width of 1536. That works fine.
Back to top
View user's profile Send private message AIM Address
cooleyes



Joined: 18 May 2006
Posts: 125

PostPosted: Wed Nov 07, 2007 11:20 pm    Post subject: Re: What graphics operations work on system memory? Reply with quote

J.F. wrote:
I was looking at the fact that 720x480 uses too much memory to fit in EDRAM, so I was playing around with trying to do GU operations to system memory. While Copy Image works, GU Draw doesn't. It looks like the target of rendering operations HAS to be in EDRAM. Is this really the case? What operations are allowed with system memory as the destination?

Currently, my rendering is stuck with one 768x448 buffer with a Z buffer. That BARELY fits into EDRAM, and then I can blit the EDRAM buffer to the frame buffer in system memory. Assuming you HAVE to keep the destination in EDRAM I was thinking of going to a 768x240 buffer. That would leave me with EDRAM left for caching textures. It would also make it easier to support interlaced displays. Non-interlaced: do two blits with line width twice as wide as it really is to space the lines out. Interlaced: do two blits, one to each half of the frame as they're already separate. So each case is easily handled by two blits. You get half the vertical resolution, but at least it's full-screen.

EDIT: One caution about doing the "twice the line width" blits - the maximum x and y values are 1024. While the line width for source and dest can be bigger, the moment the x hits 1024, the blit transfers the data wrong. So don't offset the odd field by an x of 768 with a width of 1536. That doesn't work. You have to offset the source pointer by 768*4 and use an x of 0 and width of 1536. That works fine.


you can see the lastest ppa source.
maybe it can help you
Back to top
View user's profile Send private message
J.F.



Joined: 22 Feb 2004
Posts: 2906

PostPosted: Thu Nov 08, 2007 7:12 am    Post subject: Reply with quote

O'tay! :)

EDIT: Well, that tells me I was right - you do the work in EDRAM and then blit it to the framebuffer in system memory. I do like how you separated the TV into its own set of routine. Very nice work there. However, I noticed that for interlaced mode, you blit it a line at a time in a loop. You might try something like this (how I do it at the moment):

Code:
   guStart();
   if (laced)
   {
      sceGuCopyImage(GU_PSM_8888, sx, sy, width, height>>1, PSP_LINE_SIZE<<1, (void *)(vram+PSP_LINE_SIZE*4), dx, dy>>1, PSP_LINE_SIZE, dest);
      sceGuCopyImage(GU_PSM_8888, sx, sy, width, height>>1, PSP_LINE_SIZE<<1, (void *)vram, dx, dy>>1, PSP_LINE_SIZE, (void *)((unsigned int)dest + PSP_LINE_SIZE*262*4));
   }
   else
      sceGuCopyImage(GU_PSM_8888, sx, sy, width, height, PSP_LINE_SIZE, (void *)vram, dx, dy, PSP_LINE_SIZE, dest);
   sceGuFinish();
   sceGuSync(0,0);


Also, what's with the sceGuTexSync() calls? The old graphics.c file doesn't have a single one.
Back to top
View user's profile Send private message AIM Address
chp



Joined: 23 Jun 2004
Posts: 313

PostPosted: Fri Nov 09, 2007 5:42 am    Post subject: Reply with quote

sceGuTexSync() synchronizes the sceGuCopyImage() since it runs in parallel with any GE operation that you do. You call it before you use the copied data on the GE, so that you could wait for a memory buffer in GE memory to become available for re-use (if you blit from one and draw into another).
_________________
GE Dominator
Back to top
View user's profile Send private message
J.F.



Joined: 22 Feb 2004
Posts: 2906

PostPosted: Fri Nov 09, 2007 6:10 am    Post subject: Reply with quote

I guess in this case it's being used to say when the blit is done because the transfer is FROM GE memory, not TO it.
Back to top
View user's profile Send private message AIM Address
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