I seem to have GEM built with GLEW on Windows however the pix_texture object was crashing. It took a little time to trace the crash, but I finally figured out that it died on GL_APPLE_texture_range. Now, let's look at that again in slow-motion: Windows box, Apple specific extension, crash. GLEW apparently says 'YES!' to every extension under the sun, which means we need to clean up some code based on platform assumptions in order to make it work.
cgc
chris clepper wrote:
I seem to have GEM built with GLEW on Windows however the pix_texture object was crashing. It took a little time to trace the crash, but I finally figured out that it died on GL_APPLE_texture_range. Now, let's look at that again in slow-motion: Windows box, Apple specific extension, crash. GLEW apparently says 'YES!' to every extension under the sun, which means we need to clean up some code based on platform assumptions in order to make it work.
hmm, on my system (w2k, geforceFX5600, don't know which drivers), GLEW (or rather glewinfo) reports: GL_APPLE_texture_range MISSING
which seems pretty much ok to me. and then: w32-drivers for my gfx-card might well support apple-specific extensions (although it is unlikely; i am just saying it is possible)
if glew says "YES" to every extension under the sun, then it is broken and a bug-report should be made (although i doubt that a bit - are you sure you initialized glew correctly (i stumbled across this very problem myself))
looking forward to see some glewified gem...
mfg.asdr IOhannes
On 1/24/06, IOhannes m zmoelnig zmoelnig@iem.at wrote:
hmm, on my system (w2k, geforceFX5600, don't know which drivers), GLEW (or rather glewinfo) reports: GL_APPLE_texture_range MISSING
which seems pretty much ok to me. and then: w32-drivers for my gfx-card might well support apple-specific extensions (although it is unlikely; i am just saying it is possible)
if glew says "YES" to every extension under the sun, then it is broken and a bug-report should be made (although i doubt that a bit - are you sure you initialized glew correctly (i stumbled across this very problem myself))
According to the docs there is one call to init GLEW which I seem to have done correctly. The problem could be that the code is just asking if the extension is defined, and not if it is supported. I think that needs to use a GLEW call to check for that.
looking forward to see some glewified gem...
I've got the ARB_ shaders going now, but keep hitting the damned 2D vs RECT problem when using the shaders I wrote for the Mac! I think the rectangle extension might work on windows using GLEW though.
I still need to figure out if YUV textures are a reality on the PC or not...
cgc
On 1/24/06, chris clepper cgc@humboldtblvd.com wrote:
I've got the ARB_ shaders going now, but keep hitting the damned 2D vs RECT problem when using the shaders I wrote for the Mac! I think the rectangle extension might work on windows using GLEW though.
Rectangle textures are working on Windows now. Performance is still horrible though. Currently 40% of a 3.4Ghz P4 to get a 640x480 photo-jpeg to screen at 30fps. About 25% or so is the decompression, which is bad but the rest might be an indication of a non-optimal pixel format or something?
I still need to figure out if YUV textures are a reality on the PC or not...
The FireGL 3100 card I have here is missing all of the YUV extensions. Not good.
Can you give me the info on the support for rectangle and YUV textures on a NV card?
cgc
chris clepper wrote:
On 1/24/06, chris clepper cgc@humboldtblvd.com wrote:
I've got the ARB_ shaders going now, but keep hitting the damned 2D vs RECT problem when using the shaders I wrote for the Mac! I think the rectangle extension might work on windows using GLEW though.
Rectangle textures are working on Windows now. Performance is still horrible though. Currently 40% of a 3.4Ghz P4 to get a 640x480 photo-jpeg to screen at 30fps. About 25% or so is the decompression, which is bad but the rest might be an indication of a non-optimal pixel format or something?
I still need to figure out if YUV textures are a reality on the PC or not...
The FireGL 3100 card I have here is missing all of the YUV extensions. Not good.
Can you give me the info on the support for rectangle and YUV textures on a NV card?
rectangle textures work (but i have no numbers in my head); i have experimented with YUV but never got it to work.
attached are the glewinfo-output for the same machine in w32 and linux.
mf.asdr. IOhannes
On 1/24/06, IOhannes m zmoelnig zmoelnig@iem.at wrote:
rectangle textures work (but i have no numbers in my head); i have experimented with YUV but never got it to work.
attached are the glewinfo-output for the same machine in w32 and linux.
Thanks. From that report is looks like no YUV/YCbCr texture support on either OS. The change to rectangle textures made surprisingly little difference in performance, so I was hoping YUV would be possible.
chris clepper wrote:
On 1/24/06, IOhannes m zmoelnig zmoelnig@iem.at wrote:
According to the docs there is one call to init GLEW which I seem to have done correctly. The problem could be that the code is just asking if the extension is defined, and not if it is supported. I think that needs to use a GLEW call to check for that.
well, glew will "define" every possible extension (e.g. "GL_APPLE_texture_range" will be defined), since this is a preprocessor thing and would just be an annoyance for a runtime checker.
the clause <snip> #ifdef GL_APPLE_texture_range #endif </snip> has to be replaced by <snap> if (GLEW_APPLE_texture_range){ } </snap>
if this is what you meant by having "to clean up some code based on platform assumptions in order to make it work", then i'd answer "YES".
btw, welcome to the joys of compiling things on platforms where the headers do not exactly match the installed libraries....
mfg.asdr IOhannes
On 1/25/06, IOhannes m zmoelnig zmoelnig@iem.at wrote:
well, glew will "define" every possible extension (e.g. "GL_APPLE_texture_range" will be defined), since this is a preprocessor thing and would just be an annoyance for a runtime checker.
the clause
<snip> #ifdef GL_APPLE_texture_range #endif </snip> has to be replaced by <snap> if (GLEW_APPLE_texture_range){ } </snap>
if this is what you meant by having "to clean up some code based on platform assumptions in order to make it work", then i'd answer "YES".
The other option is to add in those platform and vendor specific defines by adding a __APPLE__ to the preprocessor check.
Either way is about the same amount of work, but moving to GLEW also introduces a dependency on another lib for GEM. Hopefully, they keep it up to date on all three platforms.
The other assumptions are any places where __APPLE__ really means PowerPC and so on.
btw, welcome to the joys of compiling things on platforms where the headers do not exactly match the installed libraries....
It's really a piece of work that Windows OS.
chris clepper wrote:
On 1/25/06, IOhannes m zmoelnig zmoelnig@iem.at wrote:
if this is what you meant by having "to clean up some code based on platform assumptions in order to make it work", then i'd answer "YES".
The other option is to add in those platform and vendor specific defines by adding a __APPLE__ to the preprocessor check.
i don't like this: it would make another bunch of work whenever GL_APPLE_texture_range is available on non-apple platforms. (who says that this will never be?) on my linux-PC "GL_SUN_slice_accum" is as supported (i just randomly picked one).
Either way is about the same amount of work, but moving to GLEW also introduces a dependency on another lib for GEM. Hopefully, they keep it up to date on all three platforms.
i was thinking of including glew in Gem, as it is really just 2 files (glew.c and glew.h) and regenerate from time to time.
note on "regenerate": most of the code in glew is generated from the openGL-specifications. they provide a generation-script which queries http://www.openGL.org for all available extensions and whatever. so people can keep it uptodate themself.
The other assumptions are any places where __APPLE__ really means PowerPC and so on.
well imo __APPLE__ should mean PowerPC and MacIntel....and nothing else!
mfg.asdr. IOhannes
On 1/25/06, IOhannes m zmoelnig zmoelnig@iem.at wrote:
i was thinking of including glew in Gem, as it is really just 2 files (glew.c and glew.h) and regenerate from time to time.
It also does runtime checking, which is the real reason to use it on the two more sane platforms. GLEW would probably make the code easier to read, and I'm definitely for that!
well imo __APPLE__ should mean PowerPC and MacIntel....and nothing else!
That is my point: right now we use __APPLE__ to mean code that should be big endian and that's not the proper use of that define.
chris clepper wrote:
On 1/25/06, IOhannes m zmoelnig zmoelnig@iem.at wrote:
i was thinking of including glew in Gem, as it is really just 2 files (glew.c and glew.h) and regenerate from time to time.
It also does runtime checking, which is the real reason to use it on the two more sane platforms. GLEW would probably make the code easier to read, and I'm definitely for that!
yes, i think we all agree here. (i was just saying that i would like to not link against a precompiled glew-version but rather provide glew with gem (like the particle- and fiducialtracking-library))
and once we are there, we might be able to make the code for [pix_texture] readable, although it might still be a complicated (right now it is way beyond catastrophic).
well imo __APPLE__ should mean PowerPC and MacIntel....and nothing else!
That is my point: right now we use __APPLE__ to mean code that should be big endian and that's not the proper use of that define.
isn't it great to think alike :-)
mfga.sdr. IOhannes
On 1/25/06, IOhannes m zmoelnig zmoelnig@iem.at wrote:
yes, i think we all agree here. (i was just saying that i would like to not link against a precompiled glew-version but rather provide glew with gem (like the particle- and fiducialtracking-library))
Right now I am using the binaries for GLEW, but that was just to get things working. I say go ahead and commit the current .c and .h files and we can start testing on Linux and OSX as well. I don't think we have too many places that need glewifying (texturing and shaders are the big ones) - do we need a branch for this or not?
and once we are there, we might be able to make the code for [pix_texture] readable, although it might still be a complicated (right now it is way beyond catastrophic).
pix_texture is overdue for a reworking.
-
chris clepper -
IOhannes m zmoelnig