Hi!
Idea is to not to block client application when it request buffer swap. This
should give small performance gains when swap buffer is synchronised to
vblank.
I can think of 3 different implementations to archive this continues
execution of client.
First one is to just allocate 2 back buffers and flip them for every buffer
swap. 2 back buffers would require large amount of extra memory which could
even reduce performance if there is shortage of memory.
Luckily there is technique to provide on-demand triple buffering with
copy-on-write back buffer. This would give client possibility to prepare
next frame while buffer swap is happening in background. Then in rare cases
(long wait for vblank or glxgears) when back buffer write access is required
we can create new back buffer for client to operate with. When buffer swap
happens xserver or kernel frees old back buffer which is either just
removing copy-on-write from back buffer or freeing the memory. Again this
might cause performance hit when we waste memory for 2nd back buffer.
The last option is similar to copy-on-write but instead of creating new back
buffer we just delay client only when back buffer write access is required.
This should give good performance gains without wasting memory for normal 3D
applications where every frame requires preparing data for next rendering
operation.
There is problem that some applications require synchronisation to buffer
swap for correct behave. To guess which applications don't work with
asynchronous buffer swap is hard in driver side so there should mechanism
for clients to request for this. Can we use some existing opengl extension
for this? I don't know.
Pauli
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
--
_______________________________________________
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
