n-buffering and client behaviour

[Christopher James Halse Rogers]

On Tue, 2013-04-23 at 14:29 +0800, Daniel van Vugt wrote:
> "The latter case allows eglSwapInterval(0) to not hit IPC for each frame,"
> 
> If an app really cares about performance it won't call eglSwalInterval 
> every frame. It should only be called once. But it would be nice to not 
> have any significant performance hit in calling eglSwapInterval(), to 
> cover all bases.
> 

Sorry, I've been imprecise with language. I do indeed expect clients to
call eglSwapInterval() approximately once. Wherever I say
“eglSwapInterval(0)”, assume I mean “eglSwapBuffers() when
eglSwapInterval(0) has been called”.

With that translation, the quote becomes:
“The latter case allows eglSwapBuffers() to not hit IPC every call.”

> 
> 
> On 23/04/13 14:18, Christopher James Halse Rogers wrote:
> > I dislike that <shift>+<enter> is send.
> >
> > On Tue, 2013-04-23 at 15:41 +1000, Christopher James Halse Rogers wrote:
> >> Hey all.
> >>
> >> While I'm shepherding various Mesa patches upstream
> > … I'll use the time in-between review cycles to implement triple
> > buffering in order to implement eglSwapInteral(0) so that our benchmarks
> > are less useless.
> >
> > There are two broad approaches here: the client always has exactly one
> > buffer, or the client library potentially has more than one buffer.
> >
> > In the former the server sends a single buffer on surface creation and
> > in response to each next_buffer() request, but internally keeps
> > n-buffers available and coordinates handing off buffers to the
> > compositor component and the client library. The server is responsible
> > for determining whether next_buffer() should block or not.
> >
> > In the latter case the server hands out two buffers on surface creation
> > and a single buffer in response to next_buffer(). The client library
> > then determines whether next_buffer() blocks.
> >
> > The latter case allows eglSwapInterval(0) to not hit IPC for each frame,
> > which will result in higher benchmark numbers, but for regular clients
> > the IPC overhead should not be anywhere near the same proportion of
> > rendering time, so IPC-per-frame might generate more realistic numbers.
> >
> > I'm therefore leaning towards the former approach - the client always
> > has exactly one buffer, and needs to round-trip to the server each
> > frame, even with eglSwapInterval(0).
> >
> > Thoughts?
> >
> >
>