[Haskell-cafe] Compiled program using OpenGL fails to trigger GPU switch on Mac, but works in GHCi

[Carter Schonwald]

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ö <sarnesjo at gmail.com> wrote:

> On Mon, Mar 18, 2013 at 11:27 AM, Brandon Allbery <allbery.b at gmail.com>
> wrote:
> > On Sun, Mar 17, 2013 at 7:58 PM, Jason Dagit <dagitj at gmail.com> wrote:
> >> On Sat, Mar 16, 2013 at 6:53 PM, Jesper Särnesjö <sarnesjo at gmail.comwrote:
> >>>
> >>> 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-Concurrent.html#v:isCurrentThreadBound
> [3]
> http://hackage.haskell.org/packages/archive/base/latest/doc/html/Control-Concurrent.html#v:runInBoundThread
> [4] http://joeyh.name/blog/entry/ghc_threaded_runtime_gotchas/
> [5]
> http://hackage.haskell.org/trac/ghc/wiki/Commentary/Rts/Signals#RTSAlarmSignalsandForeignLibraries
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20130318/8a5ab917/attachment.htm>