- HOpenGL - Haskell.org

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

Aprovados rela��o publicada Anadia
by Edson 29 May '13

29 May '13

Aprovados relação publicada Anadia: Pontal do Araguaia: ALESSANDRA DE SIQUEIRA ALVES, KELVIA MAYARA CISNE DOS SANTOS, FELIPE CUNHA FALCAO, NAJELA MARIA GOMES DE MATTOS COELHO ALENCAR, JOÃO CARLOS MOREIRA DE CARVALHO, CICERO ROBERT BEZERRA ANASTACIO, MARCOS BARROS REIS, IRENE COSTA OLIVEIRA BEZERRA. ROSIMERI CORDEIRO DOS SANTOS, EDVANIA DE JESUS GOMES, MARTHEUS CARLOS DE FREITAS, JOSE MACIANO ALEXANDRINO SILVA, VANESSA GADELHA DOS SANTOS. Igarapé Grande. Anadia, ANA LÚCIA MENDES DOS SANTOS, LUANA FELIX BIE, FRANCISCO PAULO DE OLIVEIRA MESQUITA, POLLIANA BRASILIANA DE SIQUEIRA, JOÃO CARLOS MOREIRA DE CARVALHO, DANIELE SILVA OLIVEIRA, MARIA JOSÉ BATISTA LEITE, JÉSSICA MAYARA P. PAULINO. SOLANGE FERREIRA ANDRADE, BRENA RODRIGUES MACIEL, LUIS FABRICIO DE FREITAS SOUZA, HÉLIO BARROS FERREIRA, RENATO CEZAR FARIAS TORRES. Buenópolis. Muniz Ferreira e ANAHISA PEDROSA VITALINO, LUCAS BEZERRA DE MESQUITA, GABRIELLE DE MOURA FERREIRA, RACHEL CABRAL MOTA, JOÃO CARLOS MOREIRA DE CARVALHO, DEBORA BEZERRA DE BRITO, MARIA KRYSLANE CARDOSO LEMOS, JOAO PEDRO ALEXANDRE SILVA MOTA. TALYTA MARTINS NEVES, CAIO BRITO BARREIRA, MADSON SANTOS MONTEIRO, IAGO FILLIPI PATROCINIO MACEDO, RITA DE CASSIA GADELHA DA SILVA. Ipiranga de Goiás.

1 0

OpenGL ES 2.0
by Peter Jones 23 Apr '13

23 Apr '13

I'm new to both Haskell and OpenGL so please forgive my ignorance and feel free to correct any mistakes. GHC cross-compiling to ARM (at least for iOS and maybe Android) is currently being merged into mainline, making Haskell an attractive language for desktop *and* mobile development. This is still pretty bleeding edge but, at least to me, very exciting. I'm in the planning stages for a couple of applications that will have a graphical game-like component to them. I'd like to use Haskell and I've also decided that since I need to support mobile devices the most platform agnostic graphics library I can probably get away with is OpenGL ES 2.0. Since OpenGL ES 2.0 is based on OpenGL 2.0 with some modifications and a proper subset of OpenGL 4.1 with the GL_ARB_ES2_compatibility extension, I'm wondering if the current OpenGL package will work if I restrict myself to the ES defined functions. My research suggests that it won't work because there are subtle differences between some of the function names and other small incompatibilities. One major difference being the fact that OpenGL doesn't manage the window where drawing happens in ES. If the existing packages won't work for this then I suppose I'll need to write a new raw package for ES and provide some sort of shim layer to OpenGL proper so that desktop applications can use the ES API. My initial thoughts for a raw package involve code generation, so I was pretty happy when I stumbled upon the OpenGLRawgen repository. At this point I'm looking to get some feedback on my approach and see if anyone wants to work on this with me. -- Peter Jones --- Love to Develop Devalot: http://www.devalot.com

2 2

Important Update: Fold StateVar, ObjectName, and Tensor back into OpenGL
by Jason Dagit 17 Mar '13

17 Mar '13

I realize this change may be frustrating for some users. I'm sorry about the inconveniences that it may cause. The positive side is that the Haskell Platform will be able to upgrade to the latest OpenGL bindings. I think that makes this disruption worth it. Then new versions are not yet on hackage, but I'll probably upload them today. How this will affect you: I moved StateVar, ObjectName, and Tensor back into the OpenGL package (and renamed their modules from Data.* to Graphics.Rendering.OpenGL.GL.*). This also required a change in the GLUT package. I bumped the version number of OpenGL to 2.8.* and GLUT to 2.4.*. The StateVar, Tensor, and ObjectName packages are still on hackage exactly as they were. So if you're using those they will continue to work except that GHC will see them as incompatible with the ones exported from Graphics.Rendering.OpenGL. If this is a problem then I can upload versions of those packages that are re-exports from OpenGL. The reason I haven't don that is because then those packages will depend on the OpenGL package and that seemed like a hassle (correct me if I'm wrong). On the topic of GLUT, none of the examples explicitly import modules from StateVar, Tensor, or ObjectName so I didn't bother testing the examples. Properly testing the examples would be easiest if we had a cabal files for the examples. Then we could at least test that they build on travis-ci. Jason

1 0

Fwd: Vector operations on datatypes in Tensor library...
by Michal J Gajda 03 Mar '13

03 Mar '13

Dear All, I see that Tensor library is used in OpenGL, OpenVG and few other libraries. Is there any plan to make vector operations available? [E.g. dot and cross product, vector projection and rejection.] Would you accept a patch, or would you recommend making another library? (Say Tensor-Operations:Data.Tensor.Operations.) For now they are included in AC-Vector package that uses a different type, which leads to impedance mismatch and unnecessary copying. I already contacted the maintainer of AC-Vector package, but got no answer to this problem so far. -- Best regards Michal -- Pozdrawiam Michał

3 3

GLSL interface
by Daniel Bergey 21 Feb '13

21 Feb '13

What is the recommended way to create and use a Shader object? Graphics.Rendering.OpenGL.GL.Shaders.Shaders has a function createShader which looks good, but is not exported. Similar not-exported functions seem to exist for the Program type. If there's still work do be done on this part of the library, I can to test out some code and submit a pull request. Thanks, bergey

2 2

Why OpenGL 3.2 bindings
by Thiago Negri 16 Jan '13

16 Jan '13

Hello. I'm quite new to OpenGL, so I don't know all features available. The description of the OpenGLRaw package says it's a binding for OpenGL 3.2. On the official site, the 3.2 specification version is from 2009. [1] Why the Haskell binding uses version 3.2? What OpenGL features I'm missing by using Haskell instead of C? Thanks. [1] http://www.opengl.org/registry/

3 3

ANN: OpenGL packages update
by Jason Dagit 04 Nov '12

04 Nov '12

The updates include: * All of the newtypes in OpenGLRaw have been changed to type aliases (credit to Trevor Elliott and Mike Ledger) * OpenGLRaw's TypesInternal module has gone away * NVidia path rendering extensions have been added by "ozelis" on github This release changes OpenGLRaw to use type aliases instead of newtype wrappers for the GLfoo types, such as GLenum/GLfloat/GLdouble. Using newtypes had the following downsides: * The CPP macros to make these definitions are borrowed verbatim from GHC sources and required updates with new GHC releases in order to stay compatible. Although, it hasn't been a problem yet, it's conceivable this will conflict with supporting different versions of GHC at some point. * Optimization rules have to be written against these newtypes and forgetting them can lead to significant performance degradation or extra verbosity for people using the bindings. * You have to reach pretty deep into GHC to make it possible for the newtypes to work in the unboxed vectors provided by the vector package. This is again, another missed opportunity for high performance code. You can find the source and bug trackers for these packages here: https://github.com/haskell-opengl/ Feedback, pull requests, and bug reports are always welcome! Thanks! Jason

1 0

Important changes to OpenGLRaw
by Jason Dagit 26 Oct '12

26 Oct '12

Hello, At some point in the past, OpenGLRaw was converted to use newtype wrappers for the GLfoo types, such as GLenum. I think this makes a certain amount of sense. It's certainly makes type safety easier. There have also been significant downsides to this: * The CPP macros to make these definitions are borrowed verbatim from GHC sources and required updates with new GHC releases in order to stay compatible. Although, it hasn't been a problem yet, it's conceivable this will conflict with supporting different versions of GHC at some point. * Optimization rules have to be written against these newtypes and forgetting them can lead to significant performance degradation or extra verbosity for people using the bindings. * You have to reach pretty deep into GHC to make it possible for the newtypes to work in the unboxed vectors provided by the vector package. This is again, another missed opportunity for high performance code. If you look at the current HEAD of the master branch for the OpenGLRaw code on github: https://github.com/haskell-opengl/OpenGLRaw You will see some changes including: * All of the newtypes mentioned above have been changed to type aliases * Version bumped to 1.3.x * TypesInternal module has gone away Thanks for these changes goes to Trevor Elliott. If you think this move to type aliases is an error, please let me know (on list or personal email is fine). I'd like to do a push to Hackage sometime soon, but I want to give people a chance to comment first. By this time next week, I would like to post a new release, unless someone has an objection. There is another wonderful set of changes you will find in HEAD. I received patches from "ozelis" to add support for the NVidia path rendering extension. Very cool! Thanks! Jason

2 2

Adding infix declaration to StateVar operators
by Paul Visschers 26 Sep '12

26 Sep '12

Hey, I would like to suggest adding an infixr 2 for the ($~), ($=!) and ($~!) operators in the StateVar package. Paul

3 3