Jason BARSTOW schrieb:
>
>
>
> Hi,
Hi, finally I found the time for a longer mail *sigh*
> I have been working on a proprietry DFB gfx driver. (note this is for.
> DFBv0.9.24)
Interesting, will this driver and hardware be publicly available?
> I have a situation where rendering my application with single-buffering is
> much faster than if double-buffering even if I don't pass WAIT on the flip.
> Looking at the sources, it seems when singlebuffering, the gfx engine is
> never synced (with the host), but if double or tripple buffering the engine
> is synced to the last write to the new frontbuffer.
That's right. Before a buffer is send to the display, the write
operations to it must be finished.
> I have implemented the EngineSync( ) function, and I see there is also
> WaitSerial( ) that I might implement, but it's not obvious to me that this
> will be any better, since the common application case of:
>
> MyApplication
> {
> loop forever
> {
> draw to backbuffer
> flip front,back.
> }
> }
>
>
> will always cause a complete flush of the engine - even with WaitSerial( ).
In this case WaitSerial() would only be useful if other threads/apps are
using the engine as well.
> I notice the DSFLIP_PIPELINE option - but this doesn't appear to mean
> 'pipeline the flips' - I only see its use in the windows interface.
Yes, pipelined flips were introduced for window updates only, where
the buffers are never swapped but blitted to the display. It was easy
to add pipelined flipping there. Years ago I had a game running on AWT
(on MIPS) using a DirectFB window with looping updates of one region of
the UI, i.e. post another update event in the handler for the update
event.
The pipelined Flip()s with WaitSerial() gave another 5-10% FPS increase.
It ran at 55 FPS, in a 600x328 portion of the 16 bit window. Of course,
with the command buffer no longer being empty for 0-n milliseconds,
there was much less impact by other running processes. Not that I had
any garbage objects to be collected in the whole "post & handle update -
render objects - handle input & objects" loop. I eliminated those ;)
In the non-windowed case we need to pipeline the render buffers as well.
Currently, the last buffer rendered to will be made visible. If we put
one buffer in between we only need to wait for the drawing commands made
to the last but one rendered frame. So there are still commands for a
complete frame including the Flip() in the command buffer.
> So, to summarise - is it fair to say that, currently, flips are not (and
> can not be) pipelined?
It's only for windowing at the moment, but adding pipelined buffer swaps
as well would be nice. I think in 1.1 there could be finally a new
surface and buffer core without changing the public API, but extending
it. My last rework of the code got stuck and I need to partially start
from scratch or try to integrate the changes made to the old version.
--
Best regards,
Denis Oliver Kropp
.------------------------------------------.
| DirectFB - Hardware accelerated graphics |
| http://www.directfb.org/ |
"------------------------------------------"
_______________________________________________
directfb-dev mailing list
[email protected]
http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev
