PSP Video Memory Bandwidth

[chp]

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: Select all

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: Select all

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)

[chp]

Ok, sample added in pspsdk/sdk/samples/gu/blit/

[zigzag]

Lets get those emus using this! :D

[Neu]

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?

[subbie]

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).

[chp]

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.

[chp]

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? :)

[subbie]

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.

[ector]

Main RAM -> Vid RAM and Vid RAM -> Vid RAM
Can't draw directly to Main RAM with the hardware.

[Arjan]

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.

[subbie]

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).

[Xvoid6f]

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?

[ReJ]

...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).