Hi Adam, Thanks for the extensive write-up.
On 9 August 2018 at 20:30, Adam Jackson <a...@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 _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
