Question about pvr_wait_ready()

[Stef]

I know this function is used to wait task completion from PVR before performing others tasks as DMA etc...
but, this function also wait for V Blank !
So i was just wondering, is there any ways to just wait for tasks completion (DMA, scene rendering etc...) but ignore the V Blank wait.. for instance, if i want to bench my rendering speed, i'm always limited to 60 FPS because of the pvr_wait_ready() call.

I'm also wondering what is the normal/optimal way of using PVR rendering ?
Right now, here's how i'm doing it :

- pvr_txr_load_dma(...);
- pvr_wait_ready();

- pvr_scene_begin();
- pvr_list_begin(...);

- ....

- pvr_list_finish(...);
- pvr_scene_finish();


If i remove pvr_wait_ready, DMA doesn't seems to work correctly :-/

Is pvr_scene_finish() asynchone ? i mean does it wait for scene rendernig completion ?
can i do DMA just after scene_finish ? Are they then asynchrone (can i do some task with CPU during scene rendering and DMA) ?

[BlackAura]

The rendering is asynchronous, and also buffered. At any given time, there are three scenes in the video hardware. One being displayed, one being rendered, and one being generated. pvr_scene_finish simply finishes the scene being generated, and (when the rendering of the previous scene finishes, if it hasn't already) rendering begins on that scene. While a scene is being rendered, you can do whatever you like on the SH-4 (including send another scene).

pvr_wait_ready has to wait for a vblank, because the PVRs rendering buffers are flipped during a vblank. During a vblank, KOS handles buffer flipping, and sending the next frame out. If you don't use pvr_wait_ready, you're going to be trying to send a fourth scene to the hardware, and it can't deal with that.

I'm not 100% sure if it's a limitation of the hardware, or a limitation of KOS. I suspect that the PVR could render as fast as it's able to if you programmed it correctly, but that would involve removing the vblank wait for a page flip as well.

[Stef]

The rendering is asynchronous, and also buffered. At any given time, there are three scenes in the video hardware. One being displayed, one being rendered, and one being generated. pvr_scene_finish simply finishes the scene being generated, and (when the rendering of the previous scene finishes, if it hasn't already) rendering begins on that scene. While a scene is being rendered, you can do whatever you like on the SH-4 (including send another scene).

pvr_wait_ready has to wait for a vblank, because the PVRs rendering buffers are flipped during a vblank. During a vblank, KOS handles buffer flipping, and sending the next frame out. If you don't use pvr_wait_ready, you're going to be trying to send a fourth scene to the hardware, and it can't deal with that.

I'm not 100% sure if it's a limitation of the hardware, or a limitation of KOS. I suspect that the PVR could render as fast as it's able to if you programmed it correctly, but that would involve removing the vblank wait for a page flip as well.

Thanks BA for clarify all that :)
Ok, so pageflip is done with pvr_wait_ready, i didn't know that, i though it was done with pvr_scene_finish() !
Is there any function to only do the page_flip without wating for VBlank ? i think i can find my reply by having a look on KOS sources :)

[DanPotter]

Check kernel/arch/dreamcast/hardware/pvr/. With the rewritten PVR driver (circa 2 years ago, for FoF) all the page flipping and such is much more decoupled. It's all based on interrupts now. You could probably hack something in there to make it not wait for vblanks. There's no reason it has to do so except that the results will be exceedingly ugly ;)

[Stef]

Check kernel/arch/dreamcast/hardware/pvr/. With the rewritten PVR driver (circa 2 years ago, for FoF) all the page flipping and such is much more decoupled. It's all based on interrupts now. You could probably hack something in there to make it not wait for vblanks. There's no reason it has to do so except that the results will be exceedingly ugly ;)


thanks for your reply :)
I know that will actually looks ugly, but that's only for benching purpose :)