On Mon, Mar 11, 2013 at 8:23 AM, Jesper Särnesjö
I used gfxCardStatus to show which card was in use. When I ran test2.c, the system briefly switched to the discrete card. However, when I ran Test2.hs, the system kept using the integrated chip the whole time. Presumably, the Intel chip lacks a hardware implementation of OpenGL 3.2, which causes the system to fall back to a software renderer. I then used gfxCardStatus to force the system to *always* use the discrete card and - boom! - this time Test2.hs received a hardware renderer!
So it seems that the problem is a) Mac OS X-specific, or possibly specific to systems with multiple graphics cards, b) related to triggering the *switch* to the better graphics card. I don't yet understand why the C program triggers a switch, while the Haskell program does not, but I'll keep investigating.
I haven't had much time to look at this, unfortunately, but I did notice one interesting thing: the Haskell program *does* in fact trigger a switch of graphics cards, just... not as quickly. To see this, you can check the system console (using Console.app). Here is what a switch from the integrated card to the discrete one looks like on my machine: 3/13/13 12:02:22.486 AM WindowServer[77]: Received display connect changed for display 0x4272dc0 3/13/13 12:02:22.548 AM WindowServer[77]: Received display connect changed for display 0x3f003d 3/13/13 12:02:22.549 AM WindowServer[77]: CGXMuxAcknowledge: Posting glitchless acknowledge 3/13/13 12:02:22.593 AM WindowServer[77]: Received display connect changed for display 0x4272dc0 When I run the C program, this get logged immediately following the execution of glfwOpenWindow (I stepped through the program using GDB). For the Haskell program, well... If I run the program normally, the above gets logged with roughly a second's delay, and the program receives a software renderer. However, if I step through it using GHCi, it gets logged immediately following the execution of glfwOpenWindow - and the program receives a hardware renderer! Shot in the dark here, but could this be due to lazy I/O? I seem to recall reading something about GHCi forcing stricter I/O. -- Jesper Särnesjö http://jesper.sarnesjo.org/