i might add to the confusion a bit.. there is something going on with opengl, threads and RT scheduling. i've been chasing the problem for quite a while but i can't find what it is..
the only relyable way i found to work around the problem is to initialize gl (talking about the glut thing in wvvw) in a non-rt thread, which is explicitly started with SCHED_OTHER, and synchronize using condition variables, effectively stopping the rt thread until the initialization is done.
now, this works for gl running non-RT in an otherwize RT program. for gl in RT thread, there seems to be something really wrong.
i haven't tried this, but maybe it would work to disable RT scheduling temporarily, initialize all gl things, and enable RT again.
anyway, this smells.
On Mon, 5 Jul 2004, aym3ric wrote:
Bugs/Issues: everything is fine, have some weird issues in RT though, not GEM related but really annoying (GEM 0.90 + RT = freeze/crash/watchdog, PDP 0.12.3 + RT + GLX window = freeze/crash/watchdog).
I think a similar thing happens on OSX using -rt as well. The GUI locks up when the CPU loads gets high although GEM continues to render to the window. I've always thought it had to do with GEM monopolizing the video hardware and not giving other processes a chance to draw, and do other UI events. The problem seemed to stem from OSX's GUI being an OpenGL process itself, but looks like that might not be the case.
well in my case it just can't render one single frame, as soon as the window is created (either gem or pdp_glx), pd is either gone/watchdoging or in worst cases linux freezes.
so i'm afraid it has to deal with the gl libs and the fglrx driver...
+! aym3ric.
PD-list mailing list PD-list@iem.at to manage your subscription (including un-subscription) see http://iem.at/cgi-bin/mailman/listinfo/pd-list