Hey Jesper: hrm... have you tried other compilation / ffi choices that can influence the function call? eg: using the "safe" rather than "unsafe" modifier? http://www.haskell.org/haskellwiki/GHC/Using_the_FFI#Introduction (the safe modifier doesn't seem like it matters here, but its a simple experiment to check) likewise, another experiment would be write your own c code wrapper around that opengl call, and call that wrapper from haskell. OH, and your code snippet isn't specifying *where* the glfw code is linked from! might it be linking to the *wrong* variant of the library since you're not specifying where the code is? You might want to set up a little cabal configured project that specifies all of that stuff. additionally, have you tried your code on ghc 7.6.2 ? (do this last i suppose) I don't know if any of these ideas are actually helpful, but if they are, please share what you've learned. cheers -Carter On Sat, Mar 16, 2013 at 9:53 PM, Jesper Särnesjö wrote:

On Thu, Mar 14, 2013 at 12:51 AM, Jesper Särnesjö wrote:

...

In short, I have two programs, one written in Haskell [1] and one written in C [2], that consist of calls to the same functions, in the same order, to the same C library, but which do not exhibit the same behavior. Further, the Haskell program behaves differently when compiled using GHC, and when run in GHCi. I would like to know why this is, and how to fix it.

To be clear, I think this isn't really an OpenGL problem, but rather one related to FFI or event handling. If anyone could explain to me, in general, how and why a call to a foreign function returning IO () might cause different behavior in Haskell than in C, that might help me track down the problem.

I've updated my test programs to use glGetString [3] to check which renderer is active. On my machine, it should return "NVIDIA GeForce GT 330M OpenGL Engine" if rendering happens on the discrete GPU, and "Intel HD Graphics OpenGL Engine" or "Apple Software Renderer" otherwise. These are the results of running the C and Haskell programs in various ways:

$ gcc -lglfw -framework OpenGL glfw_test.c && ./a.out NVIDIA GeForce GT 330M OpenGL Engine

$ ghc -lglfw -framework OpenGL -fforce-recomp glfw_test.hs && ./glfw_test [...] Apple Software Renderer

$ runhaskell -lglfw glfw_test.hs NVIDIA GeForce GT 330M OpenGL Engine

$ ghci -lglfw glfw_test.hs [...] Prelude Main> main NVIDIA GeForce GT 330M OpenGL Engine

The C program behaves as expected, as does the Haskell one when run using runhaskell or GHCi. Only the Haskell program compiled using GHC behaves incorrectly. Again, the OS event that signifies that a GPU switch has occurred fires either way, but for the compiled Haskell program, it fires with roughly a second's delay. Why would that be?

-- Jesper Särnesjö http://jesper.sarnesjo.org/

[1] https://gist.github.com/sarnesjo/5151894#file-glfw_test-hs [2] https://gist.github.com/sarnesjo/5151894#file-glfw_test-c [3] http://www.opengl.org/sdk/docs/man3/xhtml/glGetString.xml

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

On Sun, Mar 17, 2013 at 7:58 PM, Jason Dagit wrote:

On Sat, Mar 16, 2013 at 6:53 PM, Jesper Särnesjö wrote:

...

To be clear, I think this isn't really an OpenGL problem, but rather one related to FFI or event handling. If anyone could explain to me,The release notes for 7.0.1 said this about that flag:

There is a new -fno-ghci-sandbox flag, which stops GHCi running computations in a separate thread. In particular, this is useful for GLUT on OS X, which only works if being run on the main thread.

Worth noting is that Jesper said it *works* in ghci, and fails when compiled.... -- brandon s allbery kf8nh sine nomine associates allbery.b@gmail.com ballbery@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net

Hey Jesper, thanks for the headsup! please continue to share you findings on this matter, It sounds like it'll be really useful for folks! -Carter On Mon, Mar 18, 2013 at 9:19 AM, Jesper Särnesjö wrote:

On Mon, Mar 18, 2013 at 11:27 AM, Brandon Allbery wrote:

...

On Sun, Mar 17, 2013 at 7:58 PM, Jason Dagit wrote:

...

On Sat, Mar 16, 2013 at 6:53 PM, Jesper Särnesjö

...

To be clear, I think this isn't really an OpenGL problem, but rather one related to FFI or event handling. If anyone could explain to me,The release notes for 7.0.1 said this about that flag:

There is a new -fno-ghci-sandbox flag, which stops GHCi running computations in a separate thread. In particular, this is useful for GLUT on OS X, which only works if being run on the main thread.

Worth noting is that Jesper said it *works* in ghci, and fails when compiled....

Interestingly, running the program in GHCi with the -fno-ghci-sandbox flag, causes it to misbehave in the same way as when compiled:

$ ghci -fno-ghci-sandbox -lglfw glfw_test.hs [...] *Main> main Apple Software Renderer

This is starting to smell like a concurrency-related issue, then. I should note that the GLFW library does use multiple OS threads, and I know from previous experience that Mac OS X is fussy about GUI actions being run on the main thread. The curious thing here, of course, is that the behavior I am seeing is the exact opposite of that mentioned in the release notes.

I've found some interesting reading material on how GHC handles the interaction of concurrency and FFI, in particular the paper "Extending the Haskell Foreign Function Interface with Concurrency" by Simon Marlow and Simon Peyton-Jones [1], which even brings up OpenGL as an example of why a programmer must be able to "specify that a related group of foreign calls are all made by the same OS thread". I haven't yet had the time to dig too deep into this, but I have tried a few things:

* I've compiled the program with -threaded (as suggested by John Lato), with the foreign functions marked as safe and unsafe (as suggested by Carter Schonwald). * I've checked that the main thread of my Haskell program is bound to an OS thread [2], which it is when using the threaded runtime. I've also tried explicitly running the block of foreign calls in a bound thread [3]. * I've made sure that there is only one GLFW library on my machine for -lglfw to link with, and that it is the very same library my C program links with.

None of the above helped. However, I will keep investigating and see what I find.

As I final note, I did learn that the GHC runtime generates SIGVTALRM signals to cause the scheduler to switch contexts [4][5]. Perhaps this prevents GLFW from running properly? Looks like I'll need to brush up on my dtrace.

-- Jesper Särnesjö http://jesper.sarnesjo.org/

[1] http://community.haskell.org/~simonmar/papers/conc-ffi.pdf [2] http://hackage.haskell.org/packages/archive/base/latest/doc/html/Control-Con... [3] http://hackage.haskell.org/packages/archive/base/latest/doc/html/Control-Con... [4] http://joeyh.name/blog/entry/ghc_threaded_runtime_gotchas/ [5] http://hackage.haskell.org/trac/ghc/wiki/Commentary/Rts/Signals#RTSAlarmSign...

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

On Tue, Mar 19, 2013 at 8:18 AM, Albert Y. C. Lai wrote:

On 13-03-18 09:19 AM, Jesper Särnesjö wrote:

...

Interestingly, running the program in GHCi with the -fno-ghci-sandbox flag, causes it to misbehave in the same way as when compiled:

Then perhaps to mimic default ghci in hope of getting good results:

- compile with -threaded (more candidly, link with -threaded, it does not change code generation)

- in the program, deliberately move the work to a forkIO-thread

I did this [1], and sure enough - it did result in a GHC-compiled program behaving like one run in GHCi: $ ghc -threaded -lglfw -framework OpenGL -fforce-recomp glfw_test_threaded.hs && ./glfw_test_threaded [...] NVIDIA GeForce GT 330M OpenGL Engine I should mention that I tried both forkIO and forkOS, as well as marking the foreign imports as safe and unsafe, and, for my simple test program, the result was the same every way. This is certainly not the case in general, though, as the forkOS documentation explains [2]. I haven't yet worked out why simply moving all the work from the main thread to another (OS) thread fixes this problem. Based on what I've learned so far, that should, if anything, *prevent* things from working correctly. On that note, I did try to apply the same solution to a larger program [3], and while it did allow the GPU switch to happen properly, it also caused the program's window to become unresponsive. Like I mentioned in my earlier email, Mac OS X (or rather Cocoa) is fussy about GUI actions being run on the main thread. So, in summary, using GLFW to initialize an OpenGL context fails to trigger a GPU switch if done on the main thread, but works as expected if done on a different thread, in a Haskell program. I need to figure out *why* that is, so that I can find a way to simultaneously appease Haskell and Cocoa. Thanks for all your suggestions! -- Jesper Särnesjö http://jesper.sarnesjo.org/ [1] https://gist.github.com/sarnesjo/5151894#file-glfw_test_threaded-hs [2] http://hackage.haskell.org/packages/archive/base/latest/doc/html/Control-Con... [3] https://gist.github.com/sarnesjo/5116084#file-test-hs

On Wed, Mar 20, 2013 at 9:02 AM, Jesper Särnesjö wrote:

This solution seems to work perfectly for me. Since the foreign code is allowed to run uninterrupted, the GPU switch happens, and since the GUI actions stay on the main thread, the program's window responds to keyboard and mouse input correctly.

If that's correct, then I think you have found a bug in the GHC runtime: my understanding is that the timers should be disabled while foreign code is running, specifically to avoid confusing code that has no clue that there is another runtime involved. -- brandon s allbery kf8nh sine nomine associates allbery.b@gmail.com ballbery@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net