Menu
▾
▴
mesa3d-dev
|
From: Klaus N. <kl...@ma...> - 2000-10-05 10:02:53
|
bash$ LD_PRELOAD=~/Mesa/src/.libs/libGL.so.1.2.030500 ./walktest funky -video=opengl Using alternative 3D driver: crystalspace.graphics3d.opengl Crystal Space version 0.17 r001 [Linux-Intel-GCC] (Wed, 1-Sep-2000). Created by Jorrit Tyberghein and others... Video driver GL/X version (direct renderer) Visual ID: 20, 16bit TrueColor Frame buffer: 16bit R5:G6:B5:A0, level 0, double buffered, Depth buffer: 8bit <<<------ OpenGL renderer: Mesa X11 version 1.2 Mesa 3.5 beta Using windowed mode at resolution 640x480. Loading world '/lev/funky'... It's 8bit, while with Mesa-3.2 it is 16bit. Klaus |
|
From: Brian P. <br...@va...> - 2000-10-05 14:17:04
|
Klaus Niederkrueger wrote:
>
> bash$ LD_PRELOAD=~/Mesa/src/.libs/libGL.so.1.2.030500 ./walktest funky -video=opengl
> Using alternative 3D driver: crystalspace.graphics3d.opengl
> Crystal Space version 0.17 r001 [Linux-Intel-GCC] (Wed, 1-Sep-2000).
> Created by Jorrit Tyberghein and others...
>
> Video driver GL/X version (direct renderer)
> Visual ID: 20, 16bit TrueColor
> Frame buffer: 16bit R5:G6:B5:A0, level 0, double buffered,
> Depth buffer: 8bit <<<------
> OpenGL renderer: Mesa X11 version 1.2 Mesa 3.5 beta
> Using windowed mode at resolution 640x480.
> Loading world '/lev/funky'...
>
> It's 8bit, while with Mesa-3.2 it is 16bit.
I grabbed the Crystal Space sources and grep'd for glXChooseVisual.
In plugins/video/canvas/openglx/glx2d.cpp in the csGraphics2DGLX::Open()
function I see this:
int desired_attributes[] =
{
GLX_RGBA,
GLX_DEPTH_SIZE, 8,
GLX_RED_SIZE, 4,
GLX_BLUE_SIZE, 4,
GLX_GREEN_SIZE, 4,
None,
None
};
The GLX spec says that this should choose a visual with the deepest depth
buffer of at least 8 bits. While this is perfectly legal, Mesa has a
problem with this. Mesa's GLX, as we all know, is not real a GLX but an
emulation and it can't do everything right.
When Mesa sees GLX_DEPTH_SIZE=0, it doesn't allocate a depth buffer.
If GLX_DEPTH_SIZE=1, it allocates a 16-bit depth buffer (the default
depth buffer size).
Otherwise, if GLX_DEPTH_SIZE=N and N>1, then Mesa allocates an N-bit
depth buffer. This allows one to get a deeper depth buffer (such as
24-bits) if needed. I didn't think anyone would ever request a depth
of 1 to 15 bits so the code is kind of dumb when that happens.
There's two possible solutions:
1. Modify Crystal Space to specify GLX_DEPTH_SIZE=1 or GLX_DEPTH_SIZE=16.
2. Modify Mesa so that a 16-bit (the default) depth buffer is chosen if
GLX_DEPTH_SIZE is between 1 and 16.
Any comments?
Is anyone on this list also involved in the Crystal Space project?
-Brian
|
|
From: Allen A. <ak...@va...> - 2000-10-05 17:02:47
|
On Thu, Oct 05, 2000 at 08:16:30AM -0600, Brian Paul wrote: | | There's two possible solutions: | | 1. Modify Crystal Space to specify GLX_DEPTH_SIZE=1 or GLX_DEPTH_SIZE=16. | | 2. Modify Mesa so that a 16-bit (the default) depth buffer is chosen if | GLX_DEPTH_SIZE is between 1 and 16. | | Any comments? I'd go for the second one. I've never been a great fan of the glXChooseVisual semantics, but I think that option is a reasonable way to patch them up. Allen |
|
From: Brian P. <br...@va...> - 2000-10-05 17:43:39
|
Allen Akin wrote: > > On Thu, Oct 05, 2000 at 08:16:30AM -0600, Brian Paul wrote: > | > | There's two possible solutions: > | > | 1. Modify Crystal Space to specify GLX_DEPTH_SIZE=1 or GLX_DEPTH_SIZE=16. > | > | 2. Modify Mesa so that a 16-bit (the default) depth buffer is chosen if > | GLX_DEPTH_SIZE is between 1 and 16. > | > | Any comments? > > I'd go for the second one. I've never been a great fan of the > glXChooseVisual semantics, but I think that option is a reasonable way > to patch them up. Done. glXChooseVisual() really is poorly designed. Serious apps should avoid it and use a better visual selection method. -Brian |
|
From: Michael V. <bri...@lo...> - 2000-10-05 21:36:35
|
On Thu, Oct 05, 2000 at 11:43:10AM -0600, Brian Paul wrote: > glXChooseVisual() really is poorly designed. Serious apps should > avoid it and use a better visual selection method. Such as? m. -- Programmer "Ha ha." "Ha ha." "What are you laughing at?" Loki Software "Just the horror of being alive." http://lokigames.com/~briareos/ - Tony Millionaire |
|
From: Brian P. <br...@va...> - 2000-10-05 22:17:33
|
Michael Vance wrote: > > On Thu, Oct 05, 2000 at 11:43:10AM -0600, Brian Paul wrote: > > > glXChooseVisual() really is poorly designed. Serious apps should > > avoid it and use a better visual selection method. > > Such as? For each visual on the display, interogate the GLX attributes with glXGetConfig(). Then rank the visuals according to your app's needs and use the top one. This probably isn't a big deal on PC systems since all the visuals typically have the same color depth, Z size, accum buffer size, etc. But when I was developing for SGI systems I learned that visual selection can be tricky when there's an assortment of color depths, Z sizes, accum sizes, etc. For example, on an Indigo2 with High IMPACT graphics, there's an R-4, G-4, B-4, A-4, double-buffered visual and an R-5, G-5, B-5, A-1, double-buffered visual. If your GLX choose visual attribute list has GLX_RED/GREEN/BLUE/ALPHA_SIZE=1 then it's not clear which of those two visuals you'll get, and it might be really important to the app to get the right one. This was especially complicated on Infinite Reality systems because it offered more than 120 visuals with all kinds of trade-offs between the depths of the color and ancillary buffers. -Brian |
|
From: Allen A. <ak...@po...> - 2000-10-05 22:41:43
|
On Thu, Oct 05, 2000 at 02:36:30PM -0700, Michael Vance wrote: | On Thu, Oct 05, 2000 at 11:43:10AM -0600, Brian Paul wrote: | | > glXChooseVisual() really is poorly designed. Serious apps should | > avoid it and use a better visual selection method. | | Such as? Since 1994 I've been using the visinfo package that I wrote while at SGI. Among other things, it's used in isfast and glean, and it had some influence on Mark Kilgard's design for the display initialization string in GLUT. With visinfo, you write short Boolean expressions involving attribute variables and C operators that say exactly what visual attributes you want, plus sort keys that determine which visual is returned first if more than one meets the selection criteria. That way you don't run into the ambiguities that cause problems for glXChooseVisual(). Examples: "max rgb, max z" Deepest color buffer, deepest depth buffer -- roughly what glXChooseVisual is supposed to return if you specify nonzero color and depth attributes. "max rgb, z == 16, db" Deepest color buffer; depth buffer must be exactly 16 bits; double-buffered. "max rgb, min z" Deepest color buffer; shallowest available nonzero depth buffer. "max rgba, fast, conformant, accumrgba >= 2*rgba" Deepest RGBA that's hardware accelerated, passes the OpenGL conformance tests, and has an accumulation buffer at least twice as deep as the color buffer. "r%2 || g%2 || b%2, !s" Color buffer in which at least one channel has an odd number of bits; no stencil planes. And so on. This has enough expressive power that I've never felt the need for anything else, and it's been ported to most systems running OpenGL so it has relatively good availability. However, you can always roll your own using glXGetConfig() or other window-system-dependent query function.. Allen |
|
From: Daryll S. <da...@va...> - 2000-10-05 23:37:21
|
On Thu, Oct 05, 2000 at 03:41:42PM -0700, Allen Akin wrote: > Since 1994 I've been using the visinfo package that I wrote while at > SGI. Among other things, it's used in isfast and glean, and it had > some influence on Mark Kilgard's design for the display initialization > string in GLUT. Maybe this is something we should package up and include in GLU or something. It sounds like it would be generally useful and might discourage the use of glXChooseVisual. - |Daryll |
|
From: Allen A. <ak...@po...> - 2000-10-06 00:35:55
|
On Thu, Oct 05, 2000 at 04:36:50PM -0700, Daryll Strauss wrote: | | Maybe this is something we should package up and include in GLU or | something. It sounds like it would be generally useful and might | discourage the use of glXChooseVisual. The ARB gets to decide what goes into the official GLU, so we couldn't just put it in unilaterally. However, it could be treated as a Mesa (or EXT) extension. Allen |
|
From: Stephen J B. <sj...@li...> - 2000-10-06 13:42:27
|
On Thu, 5 Oct 2000, Daryll Strauss wrote: > On Thu, Oct 05, 2000 at 03:41:42PM -0700, Allen Akin wrote: > > Since 1994 I've been using the visinfo package that I wrote while at > > SGI. Among other things, it's used in isfast and glean, and it had > > some influence on Mark Kilgard's design for the display initialization > > string in GLUT. > > Maybe this is something we should package up and include in GLU or > something. It sounds like it would be generally useful and might > discourage the use of glXChooseVisual. I don't think GLU is the right place for it because GLU is generally independent of the windowing system - just as GL is...and rightly so. That leaves GLUT (which already has it - essentially) or building a new command into GLX where everyone can get at it. I vote for a GLX extension. ---- Steve Baker (817)619-2657 (Vox/Vox-Mail) L3Com/Link Simulation & Training (817)619-2466 (Fax) Work: sj...@li... http://www.link.com Home: sjb...@ai... http://web2.airmail.net/sjbaker1 |
|
From: Brian P. <br...@va...> - 2000-10-06 14:43:33
|
Stephen J Baker wrote: > > On Thu, 5 Oct 2000, Daryll Strauss wrote: > > > On Thu, Oct 05, 2000 at 03:41:42PM -0700, Allen Akin wrote: > > > Since 1994 I've been using the visinfo package that I wrote while at > > > SGI. Among other things, it's used in isfast and glean, and it had > > > some influence on Mark Kilgard's design for the display initialization > > > string in GLUT. > > > > Maybe this is something we should package up and include in GLU or > > something. It sounds like it would be generally useful and might > > discourage the use of glXChooseVisual. > > I don't think GLU is the right place for it because GLU is generally > independent of the windowing system - just as GL is...and rightly so. Right. > That leaves GLUT (which already has it - essentially) or building > a new command into GLX where everyone can get at it. > > I vote for a GLX extension. In this case I don't feel an extension is necessary. Allen's visual selection utility is completely layered on top of the GLX API; it needs no hooks inside GLX. I think people who need the code could simply add the .c and .h files to their project and compile it in. That way, there's no hassles with versioning or compile-time or run- time extension testing, etc. And we all know how bad that can be! -Brian |
|
From: Daryll S. <da...@va...> - 2000-10-06 15:43:04
|
Stephen J Baker wrote: > I don't think GLU is the right place for it because GLU is generally > independent of the windowing system - just as GL is...and rightly so. I actually meant GLX. Oops. On Fri, Oct 06, 2000 at 08:42:24AM -0600, Brian Paul wrote: > In this case I don't feel an extension is necessary. Allen's visual > selection utility is completely layered on top of the GLX API; it needs > no hooks inside GLX. I think people who need the code could simply add > the .c and .h files to their project and compile it in. > > That way, there's no hassles with versioning or compile-time or run- > time extension testing, etc. And we all know how bad that can be! I agree technically that works, but that doesn't get it widely distributed and if people don't know it exists they won't use it. I'm trying to get it included in some standard library (maybe as extension) so that people have it and use it instead of inverting their own. If you really dislike attaching it to GLX maybe we need a our own libMesaU (or equivalent) that can include stuff like this. - |Daryll |
|
From: Brian P. <br...@va...> - 2000-10-06 16:13:10
|
Daryll Strauss wrote: > > Stephen J Baker wrote: > > I don't think GLU is the right place for it because GLU is generally > > independent of the windowing system - just as GL is...and rightly so. > > I actually meant GLX. Oops. > > On Fri, Oct 06, 2000 at 08:42:24AM -0600, Brian Paul wrote: > > In this case I don't feel an extension is necessary. Allen's visual > > selection utility is completely layered on top of the GLX API; it needs > > no hooks inside GLX. I think people who need the code could simply add > > the .c and .h files to their project and compile it in. > > > > That way, there's no hassles with versioning or compile-time or run- > > time extension testing, etc. And we all know how bad that can be! > > I agree technically that works, but that doesn't get it widely > distributed and if people don't know it exists they won't use it. That's a good point. > I'm > trying to get it included in some standard library (maybe as extension) > so that people have it and use it instead of inverting their own. If you > really dislike attaching it to GLX maybe we need a our own libMesaU (or > equivalent) that can include stuff like this. In the Mesa distro I have a util/ directory with some useful odds and ends and on my personal systems I have years worth of OpenGL tests, demos and hacks. It's occured to me that having an online repository for all this stuff might be nice. Open-source, of course. I wonder if there'd be much interest in setting up new SourceForge project, perhaps "OpenGL Toolbox", to collect all these odds and ends? Would that be redundant with www.opengl.org's content? Another point: the Mesa distro has a separate package of demo programs. They're mostly portable but the build environment is geared toward Mesa only. It might be nice to convert those demos into a more flexible package that anyone (i.e. non-Mesa users) can easily use. That might also relieve me of some maintence work. Unfortunately, I don't have time to setup anything like this. But there's probably someone out there who could do so, if people think it's worthwhile. -Brian |
|
From: Stephen J B. <sj...@li...> - 2000-10-06 17:37:54
|
On Fri, 6 Oct 2000, Daryll Strauss wrote: > > That way, there's no hassles with versioning or compile-time or run- > > time extension testing, etc. And we all know how bad that can be! > > I agree technically that works, but that doesn't get it widely > distributed and if people don't know it exists they won't use it. I'm > trying to get it included in some standard library (maybe as extension) > so that people have it and use it instead of inverting their own. If you > really dislike attaching it to GLX maybe we need a our own libMesaU (or > equivalent) that can include stuff like this. With the widespread use of nVidia's OpenGL for Linux, there is no point in putting it into a libMesaU - that would just make matters worse. ---- Steve Baker (817)619-2657 (Vox/Vox-Mail) L3Com/Link Simulation & Training (817)619-2466 (Fax) Work: sj...@li... http://www.link.com Home: sjb...@ai... http://web2.airmail.net/sjbaker1 |
|
From: Dave S. <shr...@sg...> - 2000-10-06 18:29:36
|
Daryll Strauss writes: > > In this case I don't feel an extension is necessary. Allen's visual > > selection utility is completely layered on top of the GLX API; it needs > > no hooks inside GLX. I think people who need the code could simply add > > the .c and .h files to their project and compile it in. > > > > That way, there's no hassles with versioning or compile-time or run- > > time extension testing, etc. And we all know how bad that can be! > > I agree technically that works, but that doesn't get it widely > distributed and if people don't know it exists they won't use it. However, its not as if people have been unsuccessful using glXChooseVisual(). I tend to believe that very few applications go to the trouble of very specific visual selection above glXChooseVisual(). The most notable execpetions are things like sensor simulation, and that's mostly because they exporting digital data, and not a visual image. > I'm trying to get it included in some standard library (maybe as > extension) so that people have it and use it instead of inverting > their own. If you really dislike attaching it to GLX maybe we need a > our own libMesaU (or equivalent) that can include stuff like this. Personally, I would vote for something in the spirit of "isfast". On the pro side of attaching it to GLX, as GLX evolves, then perhaps so will it. On the (larger, IMO) con side, generic use of an alternative visual selection algorithm (which probably isn't needed in many cases anyhow), means that as new features become "default" (like multisampling) for visuals, these changes should be transparently folded into something like glXChooseVisual() without requiring modification of the developer's code. I don't think glXChooseVisual() sucks so bad that an alternative needs to be standardized. Not to slight the work that Allan's done, but a faster, and easier, solution would be some better documentation of how to choose visual. Thanks. -- Thanx, Dave --------------------------------------------------------------------- Dave Shreiner <shr...@sg...> Silicon Graphics, Inc. (650) 933-4899 |
|
From: Allen A. <ak...@po...> - 2000-10-06 20:36:09
|
Hi, Dave! On Fri, Oct 06, 2000 at 11:29:30AM -0700, Dave Shreiner wrote: | | However, its not as if people have been unsuccessful using | glXChooseVisual(). ... It seems clear to me that people aren't making a lot of use of the alternatives, e.g. visinfo has been around since 1994 and most OpenGL people I know have never heard of it. But screwups with glXChooseVisual() are really common. My experience is that most people just experiment until they find some combination of input parameters that works, and then stick with that until the app is run on some other OpenGL implementation and breaks there. | Personally, I would vote for something in the spirit of "isfast". That's the way visinfo was distributed originally, but apparently it never caught on. | On the (larger, IMO) con side, generic use of an alternative visual | selection algorithm (which probably isn't needed in many cases anyhow), | means that as new features become "default" (like multisampling) for | visuals, these changes should be transparently folded into something | like glXChooseVisual() without requiring modification of the developer's | code. The same thing can be done with visinfo as long as it's in a dynamic library. (BTW, visinfo already has multisampling support, provided in an upward-compatible way like glXChooseVisual().) | I don't think glXChooseVisual() sucks so bad that an alternative | needs to be standardized. Not to slight the work that Allan's done, but | a faster, and easier, solution would be some better documentation of how | to choose visual. Could be. I haven't pushed the issue in years because it was just too low on the priority list. But in the long run, I feel pretty confident that people who give up on glXChooseVisual() and switch to calling glXGetConfig() to do their own visual selection will eventually just duplicate the effort that went into visinfo. Might as well save them some work... Allen |
|
From: Stephen J B. <sj...@li...> - 2000-10-06 17:31:46
|
On Fri, 6 Oct 2000, Brian Paul wrote: > > That leaves GLUT (which already has it - essentially) or building > > a new command into GLX where everyone can get at it. > > > > I vote for a GLX extension. > > In this case I don't feel an extension is necessary. Allen's visual > selection utility is completely layered on top of the GLX API; it needs > no hooks inside GLX. I think people who need the code could simply add > the .c and .h files to their project and compile it in. Hmmm - agreed. So what we *really* need is a new 'GLXU' library that contains utility functions that apply to GLX. GLXU is to GLX as GLU is to GL ...but then you descend a slippery slope that leads you back to GLUT. > That way, there's no hassles with versioning or compile-time or run- > time extension testing, etc. And we all know how bad that can be! Please - don't remind me. ---- Steve Baker (817)619-2657 (Vox/Vox-Mail) L3Com/Link Simulation & Training (817)619-2466 (Fax) Work: sj...@li... http://www.link.com Home: sjb...@ai... http://web2.airmail.net/sjbaker1 |
|
From: Allen A. <ak...@po...> - 2000-10-06 20:25:07
|
On Fri, Oct 06, 2000 at 12:31:38PM -0500, Stephen J Baker wrote: | On Fri, 6 Oct 2000, Brian Paul wrote: | > | > In this case I don't feel an extension is necessary. Allen's visual | > selection utility is completely layered on top of the GLX API; it needs | > no hooks inside GLX. | ... | So what we *really* need is a new 'GLXU' library that contains | utility functions that apply to GLX. I don't have any fundamental disagreement with that idea, but I wanted to point out that the visual-selection API doesn't have to be GLX-specific (the version in glean isn't, for example), so it doesn't really belong in a GLXU library. Allen |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X