July 2013 - HOpenGL - Haskell.org

Back again
by Sven Panne 12 Aug '13

12 Aug '13

After a few HOpenGL-free years caused by personal and job-related circumstances, I'd like to work on this again. First of thanks to all the people involved in keeping the binding alive, especially Jason! Having the packages in the Haskell platform is simply great, because it improves the visibility of the binding a lot and will keep new users (and new bug reports ;-) coming. I've browsed through the mailing list archives, so here are a few miscellaneous remarks: * The StateVar/Tensor/ObjectName packages are now in the OpenGL package itself (in a different namespace), and the previous standalone packages are still available, too. Although I don't think it is a perfect solution, it was probably done to get the OpenGL packages into the Haskell platform, right? If this was the motivation, I think the price to pay was well worth it. The OpenAL/ALUT packages use the assimilated packages, too, so I should probably update the former ones to use the latter ones. This will introduce a dependency of OpenAL/ALUT on OpenGL, something I wanted to avoid. But I think there are very few programs using OpenAL without OpenGL, and the latter is now universally available via the Haskell platformm, so this should be the right way to proceed. * What was the exact motivation for using type synonyms instead of the former renamings (newtypes) for the OpenGL types? Were there any *real* problems or only potential/hypothetical ones? I am a bit torn between those alternatives, so I'd like to learn the experience of other people, including their opinions. * The examples have bit-rotted, e.g. SmoothOpenGL3.hs yields an InvalidOperation in triangle's vertexAttribPointer calls, 'catch' should probably be replaced by Control.Exception.{catch,IOException}, etc. Apart from fixing them, having GLUT versions of nehe-tuts in the GLUT package would be great. I really like the idea of GLUT being a one-stop-shop for tons of examples regarding the usage of the OpenGL/OpenGLRaw packages. * Currently the binding doesn't work out-of-the box with ghci on Ubuntu 12.04 if you have NVIDIA drivers installed in addition to the Mesa ones. I have an ugly fix (adding /usr/lib/nvidia/current to OpenGLRaw's library-dirs), but I'd like to solve this more cleanly. More about this in a separate mail. * Finally Khronos has released the OpenGL registry in a less braindead format (http://www.opengl.org/discussion_boards/showthread.php/181927-New-XML-based…) so there is a good chance now that the OpenGLRaw package can be completely autogenerated, something I wanted to do for ages. Judging from the HOpenGL mailing list, Lars is already looking into it, so let's coordinate our efforts here, preferably in a separate mail thread. My main concerns here are: Include the generator (plus pre-generated bindings) in the OpenGLRaw package, it really belongs there. Don't put anything clever into OpenGLRaw, it should really, really be a plain, straightforward 1:1 mapping of the registry. No name mangling, structural modifications etc. apart from things automatically derivable from the XML registry. A big question remains: Can we generate the (un-)marshaling functions already in OpenGLRaw? The XML registry has <groups>/<group> tags, but I fear that they are still too incomplete/incorrect to be of any use for the Haskell binding. On the positive side, I think that it should be possible to upstream changes to the registry to make it more useful in general. I had contact with Jon Leech in the past, and he has always been very open and helpful. * Given the fact that OpenGL 4.3 is quite different from OpenGL in the "old days", there are quite a few design decisions in the OpenGL (convenience) package that I would do differently nowadays. But I think with the feedback from the community we can gradually tweak this layer to something more useful and up-to-date. Perhaps we can somehow re-arrange things to be more in line with OpenGL versions/profiles, but whatever we do, we should not drop support for "old skool" OpenGL, there are *tons* of tutorials, books and courses relying on it, and even NVIDIA has effectively promised to support this forever. Cheers, S.

6 8

Ancient glut32.dll bundled with the Haskell platform
by Sven Panne 26 Jul '13

26 Jul '13

If I see things correctly, https://github.com/23Skidoo/haskell-platform-windows/tree/master/etc contains the glut32.dll which is installed via the Haskell platform installer when no other GLUT DLL can be found. The problem is that this DLL seems to contain an ancient GLUT version from 2001, which misses a lot of new features: glutBitmapHeight glutBitmapString glutCloseFunc glutExit glutFullScreenToggle glutGetMenuData glutGetModeValues glutGetProcAddress glutGetWindowData glutInitContextFlags glutInitContextProfile glutInitContextVersion glutInitErrorFunc glutInitWarningFunc glutLeaveFullScreen glutLeaveMainLoop glutMainLoopEvent glutMenuDestroyFunc glutMouseWheelFunc glutMultiButtonFunc glutMultiEntryFunc glutMultiMotionFunc glutMultiPassiveFunc glutSetMenuData glutSetOption glutSetWindowData glutSolidCylinder glutSolidRhombicDodecahedron glutSolidSierpinskiSponge glutStrokeHeight glutStrokeString glutWMCloseFunc glutWireCylinder glutWireRhombicDodecahedron glutWireSierpinskiSponge As one can see, a few really crucial features are missing, like the ability to cleanly exit the GLUT main loop, and much more importantly: The ability to create specific OpenGL contexts via glutInitContext*. The latter is extensively used in e.g. the current Red Book. A better DLL is e.g. in the MSVC package in http://www.transmissionzero.co.uk/software/freeglut-devel/ (linked from the freeglut SF page). So my question is: How/where should a bug report be submitted? As it is, the bundled glut32.dll is almost useless for modern OpenGL. :-( Cheers, S.

1 0

Problems with GHCi and NVIDIA drivers on Ubuntu 12.04
by Sven Panne 23 Jul '13

23 Jul '13

When I try to run OpenGL examples on Ubuntu 12.04 with the latest Haskell platform (2013.2.0.0, incl. GHC 7.6.3), the following happens: ---------------------------------------------------------------------------------- svenpanne@svenpanne:~/haskell-platform-2013.2.0.0/packages/GLUT-2.4.0.0/examples/RedBook$ runhaskell Smooth.hs freeglut (Smooth.hs): ERROR: Internal error <FBConfig with necessary capabilities not found> in function fgOpenWindow X Error of failed request: BadWindow (invalid Window parameter) Major opcode of failed request: 4 (X_DestroyWindow) Resource id in failed request: 0x0 Serial number of failed request: 37 Current serial number in output stream: 40 ---------------------------------------------------------------------------------- I am using an x86_64 Ubuntu 12.04 distro (with some minor corporate modifications, but they probably don't matter here) with NVIDIA drivers. This means that the dynamic linker will load NVIDIA's libGL.so, as can be seen e.g. here: ---------------------------------------------------------------------------------- svenpanne@svenpanne:~$ ldd /usr/lib/x86_64-linux-gnu/libglut.so | grep libGL libGL.so.1 => /usr/lib/nvidia-current/libGL.so.1 (0x00007f1ddc76e000) svenpanne@svenpanne:~$ dpkg -S /usr/lib/nvidia-current/libGL.* nvidia-current: /usr/lib/nvidia-current/libGL.so nvidia-current: /usr/lib/nvidia-current/libGL.so.1 nvidia-current: /usr/lib/nvidia-current/libGL.so.310.51 ---------------------------------------------------------------------------------- This is OK, and this is the libGL.so which will be found by 'ld' when one simply specifies '-lglut' for compilation via gcc. This can be seen e.g. when tracing things during the linking stage of the "Hello, world!" example from the Red Book: ---------------------------------------------------------------------------------- svenpanne@svenpanne:~/redbook$ strace -f gcc hello.o -lglut 2>&1 | grep 'libglut\|libGL' | grep -v ENOENT [pid 7782] stat("/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../x86_64-linux-gnu/libglut.so", {st_mode=S_IFREG|0644, st_size=287720, ...}) = 0 [pid 7782] open("/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../x86_64-linux-gnu/libglut.so", O_RDONLY) = 8 [pid 7782] open("/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../x86_64-linux-gnu/libglut.so", O_RDONLY) = 13 [pid 7782] stat("/usr/lib/nvidia-current/libGL.so.1", {st_mode=S_IFREG|0644, st_size=1099504, ...}) = 0 [pid 7782] open("/usr/lib/nvidia-current/libGL.so.1", O_RDONLY) = 14 [pid 7782] open("/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../x86_64-linux-gnu/libglut.so", O_RDONLY) = 5 [pid 7782] open("/usr/lib/nvidia-current/libGL.so.1", O_RDONLY) = 12 [pid 7782] open("/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../x86_64-linux-gnu/libglut.so", O_RDONLY) = 8 ... ---------------------------------------------------------------------------------- But things get weird when one explicitly specifies '-lGLU and -lGL' in addition to '-lglut' (something GHC's package system is actually doing behind the scenes, too): ---------------------------------------------------------------------------------- svenpanne@svenpanne:~/redbook$ strace -f gcc hello.o -lglut -lGLU -lGL 2>&1 | grep 'libglut\|libGL' | grep -v ENOENT [pid 7943] stat("/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../x86_64-linux-gnu/libglut.so", {st_mode=S_IFREG|0644, st_size=287720, ...}) = 0 [pid 7943] open("/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../x86_64-linux-gnu/libglut.so", O_RDONLY) = 8 [pid 7943] stat("/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../x86_64-linux-gnu/libGLU.so", {st_mode=S_IFREG|0644, st_size=449168, ...}) = 0 [pid 7943] open("/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../x86_64-linux-gnu/libGLU.so", O_RDONLY) = 9 [pid 7943] stat("/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../x86_64-linux-gnu/libGL.so", {st_mode=S_IFREG|0644, st_size=390352, ...}) = 0 [pid 7943] open("/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../x86_64-linux-gnu/libGL.so", O_RDONLY) = 10 [pid 7943] open("/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../x86_64-linux-gnu/libglut.so", O_RDONLY) = 4 [pid 7943] open("/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../x86_64-linux-gnu/libGL.so", O_RDONLY) = 5 ... ---------------------------------------------------------------------------------- This happens because of there is a symbolic link in the standard library search path for gcc, which is part of a Mesa package: ---------------------------------------------------------------------------------- svenpanne@svenpanne:~$ ll /usr/lib/x86_64-linux-gnu/libGL.so lrwxrwxrwx 1 root root 13 Jun 18 22:54 /usr/lib/x86_64-linux-gnu/libGL.so -> mesa/libGL.so svenpanne@svenpanne:~$ dpkg -S /usr/lib/x86_64-linux-gnu/libGL.so libgl1-mesa-dev: /usr/lib/x86_64-linux-gnu/libGL.so ---------------------------------------------------------------------------------- Funnily enough, when you run the application later, it will use NVIDIA's libGL.so, because the dynamic linker consults /etc/ld.so.{cache,conf} and of course does *not* look into gcc's library search path: ---------------------------------------------------------------------------------- svenpanne@svenpanne:~/redbook$ ldd a.out | grep libGL libGL.so.1 => /usr/lib/nvidia-current/libGL.so.1 (0x00007f7841b34000) ---------------------------------------------------------------------------------- So in a nutshell: If you are explicit about your library dependencies, things are inconsistent on Ubuntu. Because of this, GHCi loads Mesa's libGL.so (found via 'gcc --print-names), which does not work with NVIDIA drivers. The question is: What to do about this? Adding /usr/lib/nvidia-current to OpenGLRaw's library-dirs is wrong, because this will fail when you e.g. temporarily switch to Mesa for OpenGL. I have the very strong feeling that this is a Ubuntu bug: The link '/usr/lib/x86_64-linux-gnu/libGL.so => mesa/libGL.so' is simply wrong in the presence of NVIDIA drivers, and one should fix this by making it point to /usr/lib/nvidia-current/libGL.so. A quick Google search found that other people have similar problems: https://answers.launchpad.net/ubuntu/+source/nvidia-graphics-drivers/+quest… http://techtidings.blogspot.de/2012/01/problem-with-libglso-on-64-bit-ubunt… http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=630527 Any opinions/insights? Cheers, S.

2 1