On Mon, Aug 13, 2018 at 3:53 AM Emil Velikov <emil.l.veli...@gmail.com> wrote: > > 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.
You can't render to the underlying pixmaps, since the drawable ID is internal to the GLX implementation. > > 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? I think that's good clean up at this point, but when I wrote the pbuffer support it was the other way around - we already had pixmaps and it was easy to use those for pbuffers. Kristian > Thanks > Emil > _______________________________________________ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/mesa-dev _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
