so i since today Gem depends on glew, the "openGL Extension Wrangler", a runtime openGL extension checker.
this basically means, that Gem now does runtime checks, whether your graphics card supports a certain feature (e.g. GLSL shaders) instead of making decisions at compiletime.
this should magically solve all the problems people kept having with certain openGL-functions not being found when trying to load Gem.
it should also make the "--disable-ARB", "--disable-NV" and "--with-glversion=" flags to configure obsolete.
Gem has the sourcecode of glew included (so you don't need to install it separately) and links statically to it.
for now, all (or most?) objects that had compile-time openGL checks should now have runtime checks (probably i have forgotten some, who knows)
i have successfully compiled it on linux/debian and osx-10.4. i have successfully tested it on debian(lenny/sid) with nvidia (GeForce 7800 GTX; proprietary drivers v169) and on debian(etch) with ati (Rage Mobility P/M; old "ati" xorg drivers; mesa-6.5.1)
please test! (especially specialized functions, like texture, glsl and othe shaders, framebuffer)
mfga.ds IOhannes
PS: i have for know purged pix_texture support for outdated openGL-versions (like openGL<1.1)
Has anyone had a chance to test this new code on non-Gem supported drivers? (like DRI?) I'll give it a try when I next have time. Maybe Gem will magically now work on my ubuntu powerbook.
That would be nice...
.b.
IOhannes m zmoelnig wrote:
so i since today Gem depends on glew, the "openGL Extension Wrangler", a runtime openGL extension checker.
this basically means, that Gem now does runtime checks, whether your graphics card supports a certain feature (e.g. GLSL shaders) instead of making decisions at compiletime.
this should magically solve all the problems people kept having with certain openGL-functions not being found when trying to load Gem.
it should also make the "--disable-ARB", "--disable-NV" and "--with-glversion=" flags to configure obsolete.
Gem has the sourcecode of glew included (so you don't need to install it separately) and links statically to it.
for now, all (or most?) objects that had compile-time openGL checks should now have runtime checks (probably i have forgotten some, who knows)
i have successfully compiled it on linux/debian and osx-10.4. i have successfully tested it on debian(lenny/sid) with nvidia (GeForce 7800 GTX; proprietary drivers v169) and on debian(etch) with ati (Rage Mobility P/M; old "ati" xorg drivers; mesa-6.5.1)
please test! (especially specialized functions, like texture, glsl and othe shaders, framebuffer)
mfga.ds IOhannes
PS: i have for know purged pix_texture support for outdated openGL-versions (like openGL<1.1)
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
Quoting "B. Bogart" ben@ekran.org:
Has anyone had a chance to test this new code on non-Gem supported drivers? (like DRI?) I'll give it a try when I next have time. Maybe Gem will magically now work on my ubuntu powerbook.
at least it works fine with an Mobility Radeon X2300 on my girlfriends kubuntu laptop. it uses DRI (and the proprietary radeon drivers), but i don't know whether this is "non-Gem supported".
mfga.sdr IOhannes
---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.
Hopefully I will have some time to fully test this on OSX soon. 10.4 is still my main platform although I am slowly undoing the damage done by 10.5too.
On Tue, Mar 4, 2008 at 12:03 PM, IOhannes m zmoelnig zmoelnig@iem.at wrote:
so i since today Gem depends on glew, the "openGL Extension Wrangler", a runtime openGL extension checker.
If possible it would be good to keep the ability to do a compile time switch to disable shaders even if your hardware supports it as chromium does not support shaders [which make sense as it is distributed over several computers] and it would be nice to retain chromium support.
-Alex
On 0, IOhannes m zmoelnig zmoelnig@iem.at wrote:
so i since today Gem depends on glew, the "openGL Extension Wrangler", a runtime openGL extension checker.
this basically means, that Gem now does runtime checks, whether your graphics card supports a certain feature (e.g. GLSL shaders) instead of making decisions at compiletime.
this should magically solve all the problems people kept having with certain openGL-functions not being found when trying to load Gem.
it should also make the "--disable-ARB", "--disable-NV" and "--with-glversion=" flags to configure obsolete.
Gem has the sourcecode of glew included (so you don't need to install it separately) and links statically to it.
for now, all (or most?) objects that had compile-time openGL checks should now have runtime checks (probably i have forgotten some, who knows)
i have successfully compiled it on linux/debian and osx-10.4. i have successfully tested it on debian(lenny/sid) with nvidia (GeForce 7800 GTX; proprietary drivers v169) and on debian(etch) with ati (Rage Mobility P/M; old "ati" xorg drivers; mesa-6.5.1)
please test! (especially specialized functions, like texture, glsl and othe shaders, framebuffer)
mfga.ds IOhannes
PS: i have for know purged pix_texture support for outdated openGL-versions (like openGL<1.1)
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
Alex Norman wrote:
If possible it would be good to keep the ability to do a compile time switch to disable shaders even if your hardware supports it as chromium does not support shaders [which make sense as it is distributed over several computers] and it would be nice to retain chromium support.
right, i definitely want to keep chromium support.
however, glew checks the underlying openGL implementation (most of the times this will be your hardware driver; but in the case of chromium, it should be chromium that is asked...) for existing extensions. if chromium does not support shaders, i guess shaders would be reported as unsupported.
however, i have not tried yet. did you?
fgamsdrö IOhannes
IOhannes m zmoelnig wrote:
however, i have not tried yet. did you?
now that i have tried, it indeed fails on glewInit(). i committed a wee change that just ignores this failure and continues, which appears to work (no shaders of course, but texturing works)
could you try and see whether there are any real problems?
fmgas.dr IOhannes
I don't have access to the hardware that I used to and as a result, don't have a chromium setup any more so, I cannot do any bug testing for that.. sorry.
btw, a while ago I submitted a patch to allow for an 'active stereo' [shutter glasses] stereo mode, I wonder if that ever got merged.. I guess I should just get the CVS version again..
-Alex
On 0, IOhannes m zmoelnig zmoelnig@iem.at wrote:
IOhannes m zmoelnig wrote:
however, i have not tried yet. did you?
now that i have tried, it indeed fails on glewInit(). i committed a wee change that just ignores this failure and continues, which appears to work (no shaders of course, but texturing works)
could you try and see whether there are any real problems?
fmgas.dr IOhannes
Alex Norman wrote:
I don't have access to the hardware that I used to and as a result, don't have a chromium setup any more so, I cannot do any bug testing for that.. sorry.
to bad, it would be interesting to see a real-world application...
btw, a while ago I submitted a patch to allow for an 'active stereo' [shutter glasses] stereo mode, I wonder if that ever got merged.. I guess I should just get the CVS version again..
hark, i forgot about this one. i have added it now.
fgmasdr IOhannes
IOhannes m zmoelnig wrote:
IOhannes m zmoelnig wrote:
however, i have not tried yet. did you?
now that i have tried, it indeed fails on glewInit(). i committed a wee change that just ignores this failure and continues, which appears to work (no shaders of course, but texturing works)
i tested a bit more, and glewInit() fails when it tries to initialize glxew (the glewification of glx), which is currently not used in Gem anyhow. so it seems like this can be ignored safely (i have added some checks in the Gem code as to where exactly it fails and react accordingly)
fgmadsr. IOhannes