Introduction and updates from NVIDIA

[Daniel Stone]

Hi Miguel,

On 2 April 2016 at 11:12, Miguel Angel Vico <mvicomoya at nvidia.com> wrote:
> On Fri, 1 Apr 2016 17:28:17 -0700
> Andy Ritger <aritger at nvidia.com> wrote:
>> > (As an aside, I wonder if it's properly done in FIFO mode as well;
>> > the compositor may very validly choose not to dequeue a buffer if a
>> > surface is completely occluded. How does Streams then know that it
>> > can submit another frame? Generally we use wl_surface::frame to
>> > deal with this - the equivalent of eglSwapInterval(1) - but it
>> > sounds like Streams relies more on strictly-paired internal
>> > queue/dequeue pairing in FIFO mode. Maybe this isn't true.)
>>
>> Right: in the case that the compositor wants to drop a frame, it would
>> need to dequeue it from the FIFO if it wants the client to be able to
>> produce a new frame.  Otherwise, as I understand it, the client would
>> block in its next call to eglSwapBuffers().
>
> That's correct: in FIFO mode the EGL producer will block in
> eglSwapBuffers() if the FIFO is full.
>
> IIUC, it's wayland client's responsibility to request wl_surface::frame
> notifications. Our implementation doesn't forbid the client to make use
> of wl_surface::frame so it could skip eglSwapBuffers() calls. Therefore,
> it would avoid blocking in eglSwapBuffers().

Yes-ish; depends if you define client at the process boundary, or the
DSO boundary. ;)

Taking the definition at the DSO boundary (i.e. 'Wayland client' as
something separate to the EGL Wayland implementation), then Wayland
clients _may_ call wl_surface_frame themselves to ensure they don't
block in SwapBuffers. However, the EGL implementation must also - when
in SwapInterval(1) mode - call wl_surface_frame itself, so that the
classic dumb rendering loop of while (true) { glDraw*();
eglSwapBuffers(); } is throttled to the compositor's repaint loop.

> FWIW, in my next round of weston patches I'm planing to better align
> our eglstreams implementation with the non-eglstreams when it comes to
> updating a client texture content. If I'm reading weston code correctly,
> it happens at buffer attach time, and weston calls into renderer attach
> regardless the client surface being completely occluded or not.

Right, reading through it now, it seems like always dequeuing in
renderer->attach() will solve this (non-)issue.

> The only behavior mismatch I see between the eglstream and
> non-eglstream implementations is whenever a compositor doesn't update
> the client texture content if it's occluded, and the client application
> doesn't make use of wl_surface::frame. In that case, the eglstream
> implementation would block if in FIFO mode, while the non-eglstream
> wouldn't.

Both Weston and Mutter can support this (i.e. dequeue at
attach+commit, regardless of repaint), so in practical terms you'll be
fine if you just need to support those two.

Cheers,
Daniel