[PATCH 01/11] glx: Fix mishandling of shared contexts
From: Ian Romanick ian.d.roman...@intel.com
Signed-off-by: Ian Romanick ian.d.roman...@intel.com
Reviewed-by: Eric Anholt e...@anholt.net
---
glx/glxcmds.c | 22 +++---
1 files changed, 11 insertions(+), 11 deletions(-)
diff --git a/glx/glxcmds.c b/glx/glxcmds.c
index 24fed8f..6fa10fe 100644
--- a/glx/glxcmds.c
+++ b/glx/glxcmds.c
@@ -251,20 +251,20 @@ DoCreateContext(__GLXclientState * cl, GLXContextID gcId,
shareglxc, err))
return err;
-if (shareglxc-isDirect) {
-/*
- ** NOTE: no support for sharing display lists between direct
- ** contexts, even if they are in the same address space.
- */
-#if 0
-/* Disabling this code seems to allow shared display lists
- * and texture objects to work. We'll leave it disabled for now.
- */
+/* Page 26 (page 32 of the PDF) of the GLX 1.4 spec says:
+ *
+ * The server context state for all sharing contexts must exist
+ * in a single address space or a BadMatch error is generated.
+ *
+ * If the share context is indirect, force the new context to also be
+ * indirect. If the shard context is direct but the new context
+ * cannot be direct, generate BadMatch.
+ */
+if (shareglxc-isDirect !isDirect) {
client-errorValue = shareList;
return BadMatch;
-#endif
}
-else {
+else if (!shareglxc-isDirect) {
/*
** Create an indirect context regardless of what the client asked
** for; this way we can share display list space with shareList.
--
1.7.6.5
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH 01/11] glx: Fix mishandling of shared contexts
On 12/24/2011 03:35 PM, Eric Anholt wrote: On Fri, 23 Dec 2011 15:18:19 -0800, Ian Romanicki...@freedesktop.org wrote: From: Ian Romanickian.d.roman...@intel.com Signed-off-by: Ian Romanickian.d.roman...@intel.com --- glx/glxcmds.c | 22 +++--- 1 files changed, 11 insertions(+), 11 deletions(-) diff --git a/glx/glxcmds.c b/glx/glxcmds.c index d5b764f..c5de60d 100644 + /* Page 26 (page 32 of the PDF) of the GLX 1.4 spec says: +* +* The server context state for all sharing contexts must exist +* in a single address space or a BadMatch error is generated. +* +* If the share context is indirect, force the new context to also be +* indirect. If the shard context is direct but the new context shared. Other than that, I'm assuming that checking for address space matches between two direct contexts is handled by the client side (I think I recall code to that effect, and seems like the only possible place), Indirectly. Assuming an application is using libGL (and not rolling its own GLX protocol), the only way to get a context from another process is via glXImportContextEXT. This function is supposed to fail for direct rendering contexts (with GLXBadContext), and our implementation does. We have some other bugs in this general area on the client, but I should have patches for those in the new year. which would make this: Reviewed-by: Eric Anholte...@anholt.net ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH 01/11] glx: Fix mishandling of shared contexts
On Fri, 23 Dec 2011 15:18:19 -0800, Ian Romanick i...@freedesktop.org wrote: From: Ian Romanick ian.d.roman...@intel.com Signed-off-by: Ian Romanick ian.d.roman...@intel.com --- glx/glxcmds.c | 22 +++--- 1 files changed, 11 insertions(+), 11 deletions(-) diff --git a/glx/glxcmds.c b/glx/glxcmds.c index d5b764f..c5de60d 100644 + /* Page 26 (page 32 of the PDF) of the GLX 1.4 spec says: + * + * The server context state for all sharing contexts must exist + * in a single address space or a BadMatch error is generated. + * + * If the share context is indirect, force the new context to also be + * indirect. If the shard context is direct but the new context shared. Other than that, I'm assuming that checking for address space matches between two direct contexts is handled by the client side (I think I recall code to that effect, and seems like the only possible place), which would make this: Reviewed-by: Eric Anholt e...@anholt.net pgp5HGNcSrGHG.pgp Description: PGP signature ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH 01/11] glx: Fix mishandling of shared contexts
From: Ian Romanick ian.d.roman...@intel.com
Signed-off-by: Ian Romanick ian.d.roman...@intel.com
---
glx/glxcmds.c | 22 +++---
1 files changed, 11 insertions(+), 11 deletions(-)
diff --git a/glx/glxcmds.c b/glx/glxcmds.c
index d5b764f..c5de60d 100644
--- a/glx/glxcmds.c
+++ b/glx/glxcmds.c
@@ -248,19 +248,19 @@ DoCreateContext(__GLXclientState *cl, GLXContextID gcId,
shareglxc, err))
return err;
- if (shareglxc-isDirect) {
- /*
- ** NOTE: no support for sharing display lists between direct
- ** contexts, even if they are in the same address space.
- */
-#if 0
-/* Disabling this code seems to allow shared display lists
- * and texture objects to work. We'll leave it disabled for now.
- */
+ /* Page 26 (page 32 of the PDF) of the GLX 1.4 spec says:
+*
+* The server context state for all sharing contexts must exist
+* in a single address space or a BadMatch error is generated.
+*
+* If the share context is indirect, force the new context to also be
+* indirect. If the shard context is direct but the new context
+* cannot be direct, generate BadMatch.
+*/
+ if (shareglxc-isDirect !isDirect) {
client-errorValue = shareList;
return BadMatch;
-#endif
- } else {
+ } else if (!shareglxc-isDirect) {
/*
** Create an indirect context regardless of what the client asked
** for; this way we can share display list space with shareList.
--
1.7.6.4
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
