| View previous topic :: View next topic |
| Author |
Message |
chp
Joined: 23 Jun 2004
Posts: 313
|
 Posted: Sat Jul 02, 2005 12:59 pm Post subject: PSP Video Memory Bandwidth |
 |
|
Working on an upcoming fullscreen blit-sample for libgu, I did a few tests to see how much you are able to push onto screen. Here are the meat of the results:
All tests where done with a 16-bit 4444 buffer (4 bits per component) both as source texture and destination buffer. The texture is linear, as we haven't found how to swizzle or how to enable swizzling yet. The framebuffer is 480x272 visible, but 512x272 in real buffer size.
| Code: |
memcpy() (*) : 22.65 MB/s, 91.5 fps
single blit, main ram, 480x272: 7.63 MB/s, 30.6 fps
single blit, video ram, 480x272: 51 MB/s, 204.8 fps
|
Looks bad, doesn't it? Well watch this:
| Code: |
striped blit (8 slices 64x272), main ram, 512x272: 54.62 MB/s, 219.75 fps
striped blit (8 slices 64x272), video ram, 512x272: 498 MB/s, ~2000 fps
|
This is because these slices makes full usage of the page-cache that the GE contains (very similar to how it works on the PS2 with the GS). I would seriously recommend anyone doing 2D work on the PSP to atleast do the video-memory blit using sceGu or some other method using the GE to do the dirty work. Also, this blit is asynchronous, so you can continue working while the GE copies the data to memory.
I'm submitting this sample to SVN within an hour.
Oh, and these values are very preliminary, I haven't done extensive tests and it's getting pretty late here, but it looks rather good, don't you say? :)
(* memcpy() was 512x272, values has been recomputed to account for this) |
|
| Back to top |
|
 |
chp
Joined: 23 Jun 2004
Posts: 313
|
| Posted: Sat Jul 02, 2005 1:49 pm Post subject: |
|
|
| Ok, sample added in pspsdk/sdk/samples/gu/blit/ |
|
| Back to top |
|
|
zigzag
Joined: 26 Jan 2005
Posts: 129
|
| Posted: Sat Jul 02, 2005 2:24 pm Post subject: |
|
|
| Lets get those emus using this! :D |
|
| Back to top |
|
|
Neu
Joined: 16 Jun 2005
Posts: 3
|
| Posted: Sun Jul 03, 2005 12:09 am Post subject: |
|
|
| Quote: | | Ok, sample added in pspsdk/sdk/samples/gu/blit/ |
Very nice work, chp!
Do you know if there is any way to add a color to a texture? Like I am drawing a white font, and I just want to be able to change the colors of the letters. Like adding a color to a texture. I tried changing the color in the sprite packet:
vertices[0].color = fontColor;
But it doesnt seem to have any effect. I guess it must be an enable setting somewhere? |
|
| Back to top |
|
|
subbie
Joined: 05 May 2005
Posts: 122
|
| Posted: Sun Jul 03, 2005 1:45 am Post subject: |
|
|
Where is your src data at durring this test?
Might be a good insentive for emus to just write to vram pages directly insted of framebuffers in main ram (which some do). |
|
| Back to top |
|
|
chp
Joined: 23 Jun 2004
Posts: 313
|
| Posted: Sun Jul 03, 2005 2:46 am Post subject: |
|
|
| Neu wrote: | | Quote: | | Ok, sample added in pspsdk/sdk/samples/gu/blit/ |
Very nice work, chp!
Do you know if there is any way to add a color to a texture? Like I am drawing a white font, and I just want to be able to change the colors of the letters. Like adding a color to a texture. I tried changing the color in the sprite packet:
vertices[0].color = fontColor;
But it doesnt seem to have any effect. I guess it must be an enable setting somewhere? |
Yes, you have to set the texture-function to 'modulate'. I'll commit updates to pspgu soon that contains defines for atleast 3 different texture-modes (modulate, replace, add). 'Replace' is what is enabled in the sprite-demo, and means that it does not take the vertex color into account. You could try changing this into modulate(0) and change the vertex-color after that, it should do the trick. |
|
| Back to top |
|
|
chp
Joined: 23 Jun 2004
Posts: 313
|
| Posted: Sun Jul 03, 2005 3:04 am Post subject: |
|
|
| subbie wrote: | Where is your src data at durring this test?
Might be a good insentive for emus to just write to vram pages directly insted of framebuffers in main ram (which some do). |
In the test, where it says 'main ram', it's in main ram, and 'video ram' video ram. Easy as that. :)
Well, you COULD perhaps do that (seems that writing to vram is about as fast as main ram, except you will suffer horribly if you have to do any read-modify-write operations), OR you could start doing the blits through the hardware itself. Some might not want to update their entire screen at once or have two or more layers to merge together (SNES can have up to 4 layers for example). As we progress and explore the different blending modes available, I'm there will be ways of speeding it up.
As a sidenote, if you have something static you want to copy into the framebuffer (blending it ontop or prior to your main blit), you could put it in vram and use the GE to copy it first so you don't have to do that yourself and lose precious cycles. The PSP was not, after all, made for 2D graphics, was it? :) |
|
| Back to top |
|
|
subbie
Joined: 05 May 2005
Posts: 122
|
| Posted: Sun Jul 03, 2005 3:44 am Post subject: |
|
|
I dont think you understood what I ment by src location.
Are your test doing main ram -> main ram & main ram -> vid ram or are you doing main ram -> main ram & vid ram -> vid ram. |
|
| Back to top |
|
|
ector
Joined: 12 May 2005
Posts: 195
|
| Posted: Sun Jul 03, 2005 3:58 am Post subject: |
|
|
Main RAM -> Vid RAM and Vid RAM -> Vid RAM
Can't draw directly to Main RAM with the hardware. |
|
| Back to top |
|
|
Arjan
Joined: 24 Apr 2005
Posts: 12
Location: Netherlands
|
| Posted: Sun Jul 03, 2005 4:37 am Post subject: |
|
|
aren't both tests copying from RAM to VRAM? Unless sceGuTexImage actually creates a new texture in VRAM and copies the source data to the new texture...
Accessing random locations in VRAM seems to be quite slow. I changed some code in fMSX to render to VRAM directly but it wasn't much faster. Max difference in speed I saw was 3 fps, but sometimes there was no difference at all! Considering the emu didn't have to blit a whole image, it's quite clear the buffers should really be in main RAM.
I also tried using sceDmacMemcpy to copy the buffer to VRAM, but since I had to copy things line by line it was way slower. Transferring the whole buffer (272*228*2 bytes) as a whole was faster though. |
|
| Back to top |
|
|
subbie
Joined: 05 May 2005
Posts: 122
|
| Posted: Sun Jul 03, 2005 4:54 am Post subject: |
|
|
| ector wrote: | Main RAM -> Vid RAM and Vid RAM -> Vid RAM
Can't draw directly to Main RAM with the hardware. |
He is talking about benchmarks transfering data around. Its not directly refering to rendering. The only reference to rendering is based on the idea of emus rendering to a framebuffer in mainram first or a framebuffer in vram first (emus all hand render everything). |
|
| Back to top |
|
|
Xvoid6f
Joined: 03 Jul 2005
Posts: 2
|
| Posted: Sun Jul 03, 2005 12:22 pm Post subject: |
|
|
| I have tried this sample. I see that the example is using "pixels" which is presumably in main ram. You have posted benchmarks of blitting from vram -> vram. How do you set this up? Can we specify a relocatable section, and maybe have "pixels" mapped to somewhere in vram? |
|
| Back to top |
|
|
ReJ
Joined: 04 Apr 2004
Posts: 25
Location: Lithuania, Vilnius
|
| Posted: Sun Jul 03, 2005 1:37 pm Post subject: |
|
|
| Xvoid6f wrote: | | ...blitting from vram -> vram. How do you set this up? Can we specify a relocatable section, and maybe have "pixels" mapped to somewhere in vram? |
VRAM->VRAM: You can specify pointer to a VRAM address for sceGuTexImage() function (image source). |
|
| Back to top |
|
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
