n-buffering and client behaviour

[Daniel van Vugt]

"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.



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?
>
>