On 11/25/2014 11:37 PM, Robert Morell wrote:
On Tue, Nov 25, 2014 at 11:20:58PM -0800, Alan Coopersmith wrote:
On 11/25/14 10:36 PM, Robert Morell wrote:
On Tue, Nov 25, 2014 at 07:26:14PM -0800, Alan Coopersmith wrote:
Covers the current state after commits 99f0365b1fbdfd9238b9f,
d0da0e9c3bb8fe0cd4879, & e3aa13b8d63ea2fba6eb4 were all applied.

Signed-off-by: Alan Coopersmith <[email protected]>
---
   man/Xserver.man |   10 ++++++++++
   1 file changed, 10 insertions(+)

diff --git a/man/Xserver.man b/man/Xserver.man
index c03830c..69ff626 100644
--- a/man/Xserver.man
+++ b/man/Xserver.man
@@ -181,6 +181,16 @@ prints a usage message.
   .B \-I
   causes all remaining command line arguments to be ignored.
   .TP 8
+.B \-iglx
+Prohibit creating indirect GLX contexts.  Indirect GLX is of limited use,
+since it only supports up to OpenGL 1.4; it's slower than direct contexts;

Technically, there exists protocol for much if not all of OpenGL 2.1,
and some extensions beyond that.  But not all server and client
implementations support it...

Sorry, I copied that from the comments in the commit that actually created the
options, and took Eric's word for it:

http://cgit.freedesktop.org/xorg/xserver/commit/?id=99f0365b1fbdfd9238b9f5cc28491e4e6c7324f1

Would "only fully supports up to OpenGL 1.4, with partial support for
OpenGL 2.1 and some later extensions" be more accurate?  Or is there
a better wording someone can think of?

I'm not really sure myself what the extent of official
Khronos-sanctioned protocol support is -- it's spread out over a bunch
of extensions, and if there is any overall unifying documentation I'm
not aware of it.

Maybe a more future-proof statement appropriate for the man page would
be something like "lacks support for many modern OpenGL features and
extensions"?

If you want to be specific, there is enough GLX protocol approved to implement OpenGL 2.0. Some of the stuff in 2.1 (PBO, mostly) is indefinitely awaiting a reviewer at Khronos. If any Khronos members are interested in reviewing that, let me know.

However, I agree a slightly vaguer comment is probably the way to go for the man page.

Thanks,
-James

+and it opens a large attack surface for protocol parsing errors.
+This is the default unless +iglx is specified, though it may not be honored
+by GLX implementations other than the one provided with the X server.

For what it's worth, in case anyone finds this thread in the archives,
I'll point out that NVIDIA's implementation does honor this option in
newer drivers, which contain the following entry in the changelog:

      * Implemented support for disabling indirect GLX context creation using
        the -iglx option available on X.Org server release 1.16 and newer.  Note
        that future X.Org server releases may make the -iglx option the default.
        To re-enable support for indirect GLX on such servers, use the +iglx
        option.

That's good - perhaps we can drop that qualification if both NVIDIA & AMD
will be supporting the check in their Xorg 1.17 ABI compatible versions.

I was thinking of older driver versions when I'd written it, but obviously,
due to ABI changes, there shouldn't be many (any?) GLX implementations that
can both be loaded by Xorg 1.17 and do not support this flag, so I don't
know why I was thinking of that.

Yeah, good point.


- Robert

But your text above is still accurate, so other than perhaps softening
the OpenGL 1.4 limitation,

Reviewed-by: Robert Morell <[email protected]>

+.TP 8
+.B +iglx
+Allow creating indirect GLX contexts.
+.TP 8
   .B \-maxbigreqsize \fIsize\fP
   sets the maximum big request to
   .I size
--
1.7.9.2


--
        -Alan Coopersmith-              [email protected]
         Oracle Solaris Engineering - http://blogs.oracle.com/alanc

_______________________________________________
[email protected]: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

_______________________________________________
[email protected]: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Reply via email to