[PD] GEM hardware compatibility information

[Tom Schouten]

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 at iem.at
> to manage your subscription (including un-subscription) see
> http://iem.at/cgi-bin/mailman/listinfo/pd-list
>