[PD] GEM hardware compatibility information
doelie at zzz.kotnet.org
Mon Jul 5 15:12:26 CEST 2004
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
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 =
>> 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
> 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...
> PD-list mailing list
> PD-list at iem.at
> to manage your subscription (including un-subscription) see
More information about the Pd-list