<div dir="ltr"><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Apr 30, 2019 at 5:59 AM Mathias Fröhlich <<a href="mailto:Mathias.Froehlich@gmx.net">Mathias.Froehlich@gmx.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
Adam, Marek,<br>
<br>
On Monday, 29 April 2019 18:28:21 CEST Adam Jackson wrote:<br>
> On Fri, 2019-04-26 at 23:31 -0400, Marek Olšák wrote:<br>
> <br>
> I don't claim to know what this series is trying to fix, but:<br>
> <br>
> > +    * 2) Pbuffers are back buffers from the application point of view,<br>
> > +    *    but they are front buffers from the Mesa point of view,<br>
> > +    *    because they are always single buffered.<br>
> > +    */<br>
> <br>
> The EGL spec (back to 1.0!) says:<br>
> <br>
> "The resulting pbuffer will contain color buffers and ancillary buffers<br>
> as specified by config."<br>
> <br>
> This appears to be copied from GLX, which has something more elaborate:<br>
> <br>
> "The resulting pbuffer will contain color buffers and ancillary buffers<br>
> as specified by config. It is possible to create a pbuffer with back<br>
> buffers and to swap the front and back buffers by calling<br>
> glXSwapBuffers. Note that pbuffers use framebuffer resources so<br>
> applications should consider deallocating them when they are not in<br>
> use."<br>
> <br>
> So I'm not convinced that pbuffers are "always single-buffered". The<br>
> back buffer is definitely a color buffer, and at least under GLX it<br>
> seems like it should be possible to draw red to back, swap, draw blue<br>
> to back, glReadBuffer(GL_FRONT), and expect glReadPixels to return red.<br>
<br>
Hmm, probably Marek's escape could be 2.2.2 Rendering Models form the eglspec:<br>
[...]<br>
Pbuffer surfaces have a back buffer but no associated<br>
window, so the back buffer need not be copied.<br>
[...]<br>
<br>
Not sure myself what that means in its total consequence, but can't we read that as<br>
there is only undefined behavior associated with the pbuffer front buffer?<br>
<br>
Why, do I get to that?<br>
IIRC somewhere in EGL there is a note that there is basically no front buffer rendering<br>
in EGL. And the above tells that the implementation may behave as if there is no way<br>
to swap the back buffers content into the front buffer.<br>
<br>
Is there some path left using egl images or egl copy buffers?<br>
Or what else do I miss?<br></blockquote><div><br></div>Well, EGL pbuffers have been broken in Mesa for a decade or so. We are finally getting to the point of making them work. Mesa makes EGL pbuffers always single-buffered just like EGL pixmaps. I like that because we don't waste memory for a front buffer that we might not need.</div><div class="gmail_quote"><br></div><div class="gmail_quote">We also don't support front buffer rendering with egl/x11, which makes the rabbit hole a lot deeper.<br></div><div class="gmail_quote"><br></div><div class="gmail_quote">Marek<br></div></div>