On 11-05-13 03:15 PM, DRC wrote:
However, a failure in MatchConfig() and MatchVisual() needs to remain fatal.
...
(2) We're not a GL driver.  There are certain things in VirtualGL that
are non-recoverable that would probably be recoverable in a regular GLX
implementation.  Visual matching is one of them.  If MatchConfig() or
MatchVisual() are failing, it usually means that there is a deeper
interaction issue with the app, and if the function fails silently and
only causes the app to render incorrectly, it's really hard to track
down what's going on.

If its in the trace log then I can't see it being any harder to know it happened, or where it happened. But...

Fatal errors will get reported, whereas non-fatal
errors will just lead to the user saying "well, this solution is flaky"
and never reporting the issue.

...this convinces me. :) However, it suggests that the ideal approach would be to pop up a "fatal error" X dialog. It makes absolutely sure the user knows the problem. In my experience most users launch apps from a GUI and will never see the log. For me, at least, having an app suddenly disappear (with no chance to save) sets off my this-solution-is flaky-o'meter even more than getting wrong drawing does.

I take a very reactive approach to developing VirtualGL, as you may have
noticed.  Everything that is done to that code is done in response to
the needs of a specific app.  I don't fix that which isn't broken yet,
as a general rule, because it's been my experience that doing that often
breaks something else.

Duly noted. The only reason I sent this at all is that it is very hard to imagine how it could *break* an existing app; if the app hits the error now it dies. But the issue of encouraging error reporting is definitely important.

Attached patch doesn't touch the _Match* calls. Ah, and now I see I was too slow and you already modified it...

-Nathan
>From b2688a480a99832f7f51a9376a8fdea849c9857a Mon Sep 17 00:00:00 2001
From: Nathan Kidd <nk...@opentext.com>
Date: Fri, 13 May 2011 16:02:19 -0400
Subject: [PATCH] Make glXGetConfig/glXGetFBConfigAttrib return appropriate errors codes

It really is unkind to kill a process when it isn't absolutely necessary,
and when there exists a valid way to inform it of an error.

The glXGetFBConfigAttrib return values are fudging a bit. For a bad
config Mesa will return GLXBadFBConfig (9) but that requires glxproto.h.
NVIDIA simply segvs.  We return GLX_BAD_VALUE.
---
 rr/faker-glx.cpp |    5 +++--
 1 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/rr/faker-glx.cpp b/rr/faker-glx.cpp
index 0d681d8..64dab03 100644
--- a/rr/faker-glx.cpp
+++ b/rr/faker-glx.cpp
@@ -268,7 +268,7 @@ int glXGetConfig(Display *dpy, XVisualInfo *vis, int attrib, int *value)
 		int dummy;
 		stoptrace();  if(value) {prargi(*value);}  closetrace();
 		if(!_XQueryExtension(dpy, "GLX", &dummy, &dummy, &dummy))
-			retval=0;
+			retval=GLX_NO_EXTENSION;
 		else retval=_glXGetConfig(dpy, vis, attrib, value);
 		return retval;
 	}
@@ -384,6 +384,8 @@ GLXDrawable glXGetCurrentReadDrawableSGI(void)
 int glXGetFBConfigAttrib(Display *dpy, GLXFBConfig config, int attribute, int *value)
 {
 	VisualID vid=0;  int retval=0;
+	if(!dpy || !config || !value) return GLX_BAD_VALUE;
+
 	TRY();
 
 	// Prevent recursion && handle overlay configs
@@ -391,7 +393,6 @@ int glXGetFBConfigAttrib(Display *dpy, GLXFBConfig config, int attribute, int *v
 		return _glXGetFBConfigAttrib(dpy, config, attribute, value);
 	////////////////////
 
-	if(!dpy || !value) throw rrerror("glXGetFBConfigAttrib", "Invalid argument");
 	int screen=DefaultScreen(dpy);
 
 		opentrace(glXGetFBConfigAttrib);  prargd(dpy);  prargc(config);
-- 
1.6.3.3

------------------------------------------------------------------------------
Achieve unprecedented app performance and reliability
What every C/C++ and Fortran developer should know.
Learn how Intel has extended the reach of its next-generation tools
to help boost performance applications - inlcuding clusters.
http://p.sf.net/sfu/intel-dev2devmay
_______________________________________________
VirtualGL-Devel mailing list
VirtualGL-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/virtualgl-devel

Reply via email to