forums.ps2dev.org

[mountainstorm]

First when writing code to run on the PS2 using PS2SDK, whats it running on? Are we running straight on the hardware or is there a basic kernel running?

Now for my real question.... is it possible to get hardware accelerated rendering to an offscreen buffer?

Rich

[blackdroid]

there is no kernel catering context switches if thats your concern.

you can render wherever you want in vram. and point display to wherever you want in vram.
_________________
Kung VU

[ooPo]

Its kinda hard to do double-buffering if you can't.

[mountainstorm]

I want to produce renderings in 'windows' (clipped viewports) on the screen with acceleration. So I was wondering what the performance hit would be to get each rendering done to vram and then have a lib which renders them onscreen (composes them) as required by the window ordering.

My other idea was to make this lib pre-pend commands to the display list generated for a 'windows' rendering... this would add the relavent clipping commands and transform to move the output to the desired location.

thoughts?

Rich

[Guest]

Something might be missing here.

If you render to a part of VRAM that is not displayed, it is done
with the same amount of accerlation that is done when rendering
to a part of VRAM that is displayed.

Furthermore, once rendered to anywhere in VRAM that is not displayed,
you can then display by telling the video controller to immediately "switch"
to using the non-displayed portion of memory to be the new "displayed"
framebuffer. There is no need to copy anything anywhere, its already
there. Instead of copying to the framebuffer, you are bringing the framebuffer
to the previously off-screen rendered scene.

This is normally referred to as double-buffering, as mentioned very
briefly by Oopo earlier. I am merely saving him from having to explain
what he meant in more detail, as Canadians can get mighty surly when
having to take the beer bottle out of their mouths a second time to repeat
themselves.

I am no expert in graphics, as others here can attest, so if I get something
wrong or more detail is needed, you will need to rely on someone else. :)

Gorim

[Drakonite]

[mountainstorm]

Thats exactly what I mean, the reason I asked about accelerated rendering to memory is that I wondered it the PS2 had specific video memory for double buffering, and you had to write to that and only that location.

As for swapping to that 'offscreen' buffer thats fine, but If the image there is only a small part of the overall screen output I assume I must do as suggested and use it as a texture rendered on a quad into the actual screen buffer. This is what I meant by a copy.

If Im not wrong, if I tried just telling the PS2 that 'this offscreen memory' is your screen buffer then it would have to be the whole screen and not just a small portion of the overall output.

So I take it the render to texture is a better way of doing this than prepending display list commands?

Cheers

Rich

[ooPo]

You can set the memory location in vram to render to, the size of the offscreen buffer (x,y,z), and using the clip registers you can set where on that framebuffer to render to. You may have to specify an offset to re-center on this clipped part but the whole process isn't that difficult.

[mountainstorm]

That sounds very cool, which tutorial should I look at for examples of this?

So what format does the PS2 support for textures, I take it it does RGB and RGBA but does it do YUV? If not can we use the IUP to do accelerated YUV to RGB conversion, any ideas how?

I wonder what Im trying to do? :)

Rich

[ooPo]

Tutorials? Not really.

YUV? Well, I'd say either you're either playing video of some sort, or a gamecube emulator. I think the IPU can do the conversion for you, but its not a complex thing to do if not.

[J.F.]

The IPU has a special color space conversion command. You DMA YUV420 data for a 16x16 pixel block into the IPU, then DMA a 16x16 block of RGB data out of the IPU. The command will convert the YUV into 32 or 16 bit RGB (with optional dithering for 16bit), or will vector quantize the data into a 4bit paletted mode. This 16x16 pixel block can then be used as a texture - when you DMA it from the IPU, send it to the video memory where it's now a 16x16 texture.