[...] according to my reading of the OpenGL spec, it seems part of the update to 1.2 (it's hidden in some table as GL_TEXTURE_BINDING_xD, where x should presumably include 3 now).
Hmmm, the OpenGL spec is a bit strange here: GL_TEXTURE_BINDING_xD is not mentioned in the index, but is used in the tables describing the state queries. But it's quite clear that GL_TEXTURE_BINDING_3D should be there if texture objects and 3D textures are supported (both OpenGL 1.2 features). SUN's header claims to implement 1.2, but fails to #define the above token.
I guess it's a bug. It's easy enough not to see this in the spec, but I don't understand that the conformance tests (if any) didn't pick it up and that noone has complained before.. If I get around to it, I might let them know..
Simple solution: Either comment it out if you don't need it or have a look at your favourite correct header and substitute the numeric value, perhaps the query is implemented nevertheless.
Forgot to answer this, because I ran into an unrelated problem, but I should at least reassure other Sun HOpenGL users a bit;-). Uncommenting seems to work, but I noticed some other installation issues, related to us not having GLUT in the standard place. I guess they are bugs in HOpenGL's configure script? I append a log of what I had to do below. This doesn't help me because our Sun's are used as servers, accessed mostly from PCs, via Exceed, and that doesn't seem to support GLX by default. I've seen Exceed 3d mentioned on their product page http://www.hummingbird.com/products/nc/exceed/ which looks like the solution to this problem - does anyone here have experience with that?-) Btw, Ronald Legere (who first confirmed the Sun header problem off list) vaguely recalled two other problems, default shell and black windows, which I might be able to shed some light on: - default make on Suns tends not to be gnu make, so you explicitly have to call gmake, unless you've got a portable makefile.
which make /usr/ccs/bin/make
- black windows can easily be caused by a sub-optimal color-allocation scheme in some Sun graphics implementations: if one application "steals" all colors in the map (netscape was a favorite for that), new applications may come up empty-handed. I seem to recall that there was a way to make programs behave better, but otherwise moving the mousepointer into the new black window might be sufficient to cause another disconcerting effect - now the new app gets its colors alright but all the surroundings look very strange.
This is just another example why the next release of HOpenGL won't depend on those #defines, but will use numeric values directly...
? bypassing the specified API in favour of values taken from sample
implementations doesn't strike me as a particularly good idea?
Cheers,
Claus
-------------- installation log
# GLUT isn't in the standard place here..
# configure recommends to set environment variables in such cases,
# but in this case, this is going to cause problems below
setenv LDFLAGS "-L/usr/local/packages/glut/lib/glut/"
setenv CPPFLAGS "-I/usr/local/packages/glut/include/"
# Sun doesn't seem to have read the OpenGL1.2 spec:
# GL_TEXTURE_BINDING_3D is missing in GL/gl.h..
# remove GL_TEXTURE_BINDING_3D from lib/GL_EnumQueries3.gc
# ghc and green card were not in standard places, no problem
./configure \
--with-hc=/home/cur/cr20/public/haskell/ghc-5.02.2/bin/ghc \
--with-green-card=/home/cur/cr3/software/gc-2.03/src/green-card
# Sun's default make is *not* gnu make!
gmake depend
# unfortunately, HOpenGL's configure hasn't recorded the settings
# for LDFLAGS and CPPFLAGS to pass them on to ghc..
#
# also, configure has added all kind of strange flags, but *not*
# the ones that are needed, namely: -lGLU -lGL
#
# so we need to modify in config.mk by hand:
# 1. add -lGLU -lGL to GL_LIBS
# 2. add LDFLAGS to GL_LIBS
# 3. add CPPFLAGS to HC_OPTS
---snip
GL_LIBS += -lSM -lICE -L/usr/openwin/lib -R/usr/openwin/lib -L/usr/local/packages/glut/lib/glut/ -lglut -lGLU -lGL -lX11 -lXext -lXmu -lXt -lXi -lsocket -lnsl -lm
HC_OPTS += -fglasgow-exts -I/usr/openwin/include -I/usr/local/packages/glut/include/ "-\#include
C.Reinke wrote:
[..] This doesn't help me because our Sun's are used as servers, accessed mostly from PCs, via Exceed,
I have the same setup at work.
and that doesn't seem to support GLX by default. I've seen Exceed 3d mentioned on their product page
http://www.hummingbird.com/products/nc/exceed/
which looks like the solution to this problem - does anyone here have experience with that?-)
Alas, I don't. But if you use Mesa (http://mesa3d.org/) instead of SUN's OpenGL, it should work, although slowly. Fast 3D graphics over a network is a bit ambitious, even more without GLX. :-}
[...]
This is just another example why the next release of HOpenGL won't depend on those #defines, but will use numeric values directly...
? bypassing the specified API in favour of values taken from sample implementations doesn't strike me as a particularly good idea?
It's just the other way round: The API is exactly specified, *including* all token values, see the central registry for all extensions (http://oss.sgi.com/projects/ogl-sample/registry/). This is the only way OpenGL's extension mechanism can work, and it's the only way a non-proprietary API can work, too: Forcing users to recompile just because some vendor has decided to change some values randomly is not an option in real life. The situation is very similar for X11. Cheers, S.
Alas, I don't. But if you use Mesa (http://mesa3d.org/) instead of SUN's OpenGL, it should work, although slowly. Fast 3D graphics over a network is a bit ambitious, even more without GLX. :-}
hmm, I'm not at all sure I understand the connections properly. IIRC, I got an error about missing GLX, but the Suns do have GLX (somewhere). If you're using exceed without any GL support, does mesa translate from GLX to X on the client-side, or am I missing yet another thing in my installation because of non-standard paths? The mesa faq (outdated) seems to suggest that mesa would do the translation even for dumb X-terminals, but I wonder whether it will be worth using a software-emulated OpenGL implementation - the idea was to make it easier for other local users to have a try and play with whatever I'm trying to come up with, so anything that won't look good, well, won't look good, if you know what I mean.. And isn't it the role of GLX to translate between GL and X protocol? If it could do so client-side, the X server should not need any GL support. But I think the "missing GLX" message was display-specific, thus referring to the exceed X server, not to the client Sun machine. So is GLX really an extension of the X protocol, needing both client- and server-side implementations? I'm confused..
It's just the other way round: The API is exactly specified, *including* all token values, see the central registry for all extensions (http://oss.sgi.com/projects/ogl-sample/registry/).
That is just the *extensions* registry - the API itself is now in the hands of the ARB, and the specs there do not seem to define any values, only their names? The backlink to the API docs on the extensions registry page is broken - should be to: http://www.opengl.org/developers/documentation/ Interestingly, the extension out of which the now standard 3d textures parts developed doesn't seem to mention the missing name - seems there were some renamings involved when moving that extension into the standard? Although the extension registry includes allocation policies for enumerants, I remain unconvinced that the standard API includes the values of bindings. It would be nice for all implementations to agree on the values, but is there any place in the spec saying that the values should be those of the original extension (and what about renamings in the promotion process?) or those of some reference include file (is gl.h mentioned anywhere)?
This is the only way OpenGL's extension mechanism can work, and it's the only way a non-proprietary API can work, too: Forcing users to recompile just because some vendor has decided to change some values randomly is not an option in real life. The situation is very similar for X11.
Real life software isn't always sensible.. I thought the very reason for the ABI (application binary interface) http://oss.sgi.com/projects/ogl-sample/ABI/ was that the OpenGL API does not address this (and the ABI is X/linux-specific)? But if the situation is better than I was hoping, that raises another interesting question: How portable are HOpenGL/GHC-generated executables? Obviously, not between platforms;-) but what do they depend on? GHC has otherwise become quite independent, but HOpenGL seems to depend on cygwin? And are the executables dynamically linked to OpenGL, so that they have a chance to work with someone else's graphics-card? In brief, could I "ship" a windows-executable to non-Haskellers and hope for this to work (and not ruin their hardware?-)? Claus
C. Reinke wrote:
[...] I'm not at all sure I understand the connections properly.
Scenario 1: The client library and the X server both "speak" GLX. In this case, the actual drawing is done in the server (which must have OpenGL support) and relatively little data has to be transferred between the client and the server. This is how your client application linked with SUN's OpenGL tries to communicate with your Exceed. But this fails obviously if the Exceed server is not GLX-aware. Scenario 2: The client doesn't use GLX, but does all rendering for itself and transfers all image data through the "normal" X protocol to a "dumb" X server. This will work with all servers, but more slowly due to the high volume of data which has to be transferred. Mesa can fake the GLX protocol in this way. (Well, there's another scenario, see http://dri.sourceforge.net/, but this doesn't matter for our discussion.)
[...] That is just the *extensions* registry - the API itself is now in the hands of the ARB, and the specs there do not seem to define any values, only their names?
Even if this was the case, this is a rather hypothetical discussion. Let's take e.g. the M$ platform: In ancient times there were two OpenGLs on M$, one based on the sample implementation and one for plugging in vendor-specific DLLs. They are binary compatible, as is Mesa on M$, the same Mesa which is available on Linux, SUN, etc. All are binary compatible without any platform-specific redefinitions for OpenGL tokens. This is a must, because OpenGL is rarely statically linked into an application. And another reason: "Normal" OpenGL functions are handled not much different from extensions, you can get their address via the standard mechanism etc. This is how our favourite 3D shooters handle switching drivers at runtime.
[...] GHC has otherwise become quite independent, but HOpenGL seems to depend on cygwin?
No, it's just the build process that depends on the standard Unix tools.
And are the executables dynamically linked to OpenGL, so that they have a chance to work with someone else's graphics-card?
Yes.
In brief, could I "ship" a windows-executable to non-Haskellers and hope for this to work (and not ruin their hardware?-)?
Again, yes. Currently the cygwin DLL is needed, too, but tweaking HOpenGL to be cygwin-free should be possible. Cheers, S.
participants (3)
-
C.Reinke -
Sven Panne -
Sven Panne