[Mesa-dev] Why are pbuffers backed by a pixmaps (Was Re: [PATCH] egl: Fix leak of X11 pixmaps backing pbuffers in DRI3.)

[Emil Velikov]

Hi Adam,

Thanks for the extensive write-up.

On 9 August 2018 at 20:30, Adam Jackson <ajax at redhat.com> wrote:
> On Thu, 2018-08-09 at 18:22 +0100, Emil Velikov wrote:
>
>> In the GLX case, it's required due to server-side rendering. One needs
>> a separate primitive for each pbuffer, thus the information can be
>> passed long the wire.
>
> I can't parse this. "Primitive"?
>
> So, backstory time. GLX_SGIX_pbuffer was the genesis of pbuffers.
> Here's what it has to say about how a pbuffer is unlike other GLX
> drawables (some of which is a comment about how things happened to work
> on IRIX):
>
> "GLXPbuffers are equivalent to GLXPixmaps with the following
> exceptions:
>
>     1.  There is no associated X pixmap. Also, since a GLXPbuffer is a GLX
>         resource, it may not be possible to render to it using X or an
>         X extension other than GLX.
>
>     2.  The format of the color buffers and the type and size of any
>         associated ancillary buffers for a GLXPbuffer can only be
>         described with a GLXFBConfig -- an X Visual cannot be used.
>
>     3.  It is possible to create a GLXPbuffer whose contents may be
>         asynchronously lost at any time.
>
>     4.  GLXPbuffers can be rendered to using either direct or indirect
>         rendering contexts.
>
>     5.  The allocation of a GLXPbuffer can fail if there are insufficient
>         resources (i.e., all the pbuffer memory has been allocated and
>         the implementation does not virtualize pbuffer memory.)"
>
> In contrast, a GLXPixmap _must_ be renderable by X11, cannot lose its
> contents, and _may_ not be renderable by direct contexts. All of this
> dates to like 1997, so we didn't have FBOs yet, and any rendering
> surface would have been allocated by "the server" [1]. That extension
> was merged into GLX 1.3 pretty much unchanged, and GLX 1.3 was 1998.
>
> Xorg didn't get GLX 1.3 working until like 2007 [2]. As an
> implementation choice, Xorg _does_ back pbuffers with pixmaps, both in
> that it calls ->CreatePixmap internally to make them and that it tracks
> them as actual pixmaps [3]. We never clobber pbuffers, we have no
> problem rendering to pbuffers from X11, and we have no problem
> rendering to GLXPixmaps from direct contexts. Effectively, other than
> the resource type, the difference between a pbuffer and a glxpixmap is
> that the latter takes two XIDs and two resource creation calls.
>
So if I understood you correctly [and the spec] there is no
requirement (nor ban) on rendering to pbuffers from X11.
It's an implementation decision to allow it.

> EGL dates to 2003, which means it predates even EXT_framebuffer_object,
> so the pbuffer bit of GLX was kept in the new API. The EGL spec says a
> pbuffer has no associated native window or native window type - no
> kidding, it's not a window - but it does not require that a pbuffer
> have no native object backing it at all.
>
I> Now, direct rendering in GLX is underspecified; the implementation is
> free to use whatever subset of GLX, and whatever private protocol, it
> wants. In principle the client could allocate the pbuffer's storage
> from the "server" (the drm, here), and pass that handle and its new XID
> name to the X server to bind them together so indirect contexts can
> name it as well.
>
> An EGL implementation could take even more liberties. Even on an X11
> window system there's no intrinsic reason that an EGL pbuffer need to
> exist as a native winsys object; all that's required is that pbuffers
> work with any API that takes an EGLSurface parameter. You might choose
> to mirror EGL surfaces as GLX objects, or not, whatever your
> implementation finds convenient. In practice, we back pbuffers with
> pixmaps because we also back pixmaps with pixmaps, and there's no
> reason to make those paths diverge more than they have to.
>
I was thinking in the opposite direction - we already have pbuffer
implementation, which is duplicated across egl/android and
egl/surfaceless.
We could trivially make that a helper function and reuse across the board.

No need to special case X11, Android, etc - far less code and
divergence across platforms.
Using the same codepath across all EGL won't be that bad, right?

Thanks
Emil