Hi GEM developers,
I've recently (finally!) worked to make the CVS version of GEM actually build and run under Windows. There's lots of exciting new stuff in there which is good to see. The real-time graph updating is certainly an improvement.
Tweaking GEM to build was not a particularly difficult experience but there are a few little issues that may bite (mainly caused by deficiencies in Windows and VC++ I might add). For the time being, I'll keep fiddling with others' source changes in such a way to make them build under Windows without breaking them on other platforms. Apologies in advance if I do, however, wreak havoc. Here are a couple of the issues if you want to try to avoid them...
1) Problem: 'for' scoping for VC++ 6.0 isn't compatible with the "new ISO" style scoping that GCC seems to support/default to.
E.g. for (int i=0; i < i_max; i++) func(i); for (int I=0; i < i_MAX; i++) // causes VC++ redefinition error func2(i);
Short-term Solution: I just removed any variable redefinitions that caused compiler errors under VC++. This may now result in warnings on other platforms. This is undesirable and I don't want to suggest that the code should conform to VC++ non-conformance...
Long-term Solution: We probably should code to avoid both the VC++ error and the GCC warning.
2) Problem: Windows needs to have <windows.h> explicitly included before many of the "platform independent" GL headers (e.g. gl.h, glu.h etc).
Short-term Solution: I added the #ifdef _WINDOWS etc. inclusion of windows.h wherever it's need... including the "I hate windows, I shouldn't have to do this". Whose immortal words are those, anyway?!
Long-term Solution: I'll see if it's easy to add windows.h as a default include somehow so we can avoid pollution of the GEM source. OTOH, this causes a bit of obfuscation and "make" builds would be complicated....
That's enough for now, Daniel
Hi GEM developers,
I've recently (finally!) worked to make the CVS version of GEM actually build and run under Windows. There's lots of exciting new stuff in there which is good to see. The real-time graph updating is certainly an improvement.
great. can you post a windows build somewhere? i'd like to check it out.
Tweaking GEM to build was not a particularly difficult experience but there are a few little issues that may bite (mainly caused by deficiencies in Windows and VC++ I might add). For the time being, I'll keep fiddling with others' source changes in such a way to make them build under Windows without breaking them on other platforms. Apologies in advance if I do, however, wreak havoc. Here are a couple of the issues if you want to try to avoid them...
i compiled with all of the changes so far and it works ok on OSX.
- Problem: 'for' scoping for VC++ 6.0 isn't compatible with the "new ISO"
style scoping that GCC seems to support/default to.
E.g. for (int i=0; i < i_max; i++) func(i); for (int I=0; i < i_MAX; i++) // causes VC++ redefinition error func2(i);
couldn't find any of these changes to the CVS. can you point one out to me?
Short-term Solution: I just removed any variable redefinitions that caused compiler errors under VC++. This may now result in warnings on other platforms. This is undesirable and I don't want to suggest that the code should conform to VC++ non-conformance...
Long-term Solution: We probably should code to avoid both the VC++ error and the GCC warning.
which gcc warning?
- Problem: Windows needs to have <windows.h> explicitly included before
many of the "platform independent" GL headers (e.g. gl.h, glu.h etc).
Short-term Solution: I added the #ifdef _WINDOWS etc. inclusion of windows.h wherever it's need... including the "I hate windows, I shouldn't have to do this". Whose immortal words are those, anyway?!
seems ok, since there are already a few of those #ifdefs littered throughout GEM. i have no idea who wrote the 'i hate windows' bit, Mark Danks??
cgc
Long-term Solution: I'll see if it's easy to add windows.h as a default include somehow so we can avoid pollution of the GEM source. OTOH, this causes a bit of obfuscation and "make" builds would be complicated....
That's enough for now, Daniel
PD-dev mailing list PD-dev@iem.kug.ac.at http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-dev
On Fri, 28 Feb 2003, Daniel Heckenberg wrote:
- Problem: 'for' scoping for VC++ 6.0 isn't compatible with the "new ISO"
style scoping that GCC seems to support/default to.
E.g. for (int i=0; i < i_max; i++) func(i); for (int I=0; i < i_MAX; i++) // causes VC++ redefinition error func2(i);
Short-term Solution: I just removed any variable redefinitions that caused compiler errors under VC++. This may now result in warnings on other platforms. This is undesirable and I don't want to suggest that the code should conform to VC++ non-conformance...
This is not non-conformance, if you find constructs like the ones you mentioned, you have to change them, this is true for all platforms.
int i; for (i=0;...) ...
Long-term Solution: We probably should code to avoid both the VC++ error and the GCC warning.
Definitely.
- Problem: Windows needs to have <windows.h> explicitly included before
many of the "platform independent" GL headers (e.g. gl.h, glu.h etc).
Short-term Solution: I added the #ifdef _WINDOWS etc. inclusion of windows.h wherever it's need... including the "I hate windows, I shouldn't have to do this". Whose immortal words are those, anyway?!
:) this was Mark, probably when he ported from SGI to windows.
Long-term Solution: I'll see if it's easy to add windows.h as a default include somehow so we can avoid pollution of the GEM source. OTOH, this causes a bit of obfuscation and "make" builds would be complicated....
Yes, I think in the long termit is better to make the OS specific #ifdefs only in few places. The best solution would be to have these just in one file.
Guenter
On Fri, 28 Feb 2003, guenter geiger wrote:
On Fri, 28 Feb 2003, Daniel Heckenberg wrote:
- Problem: 'for' scoping for VC++ 6.0 isn't compatible with the "new ISO"
style scoping that GCC seems to support/default to.
E.g. for (int i=0; i < i_max; i++) func(i); for (int I=0; i < i_MAX; i++) // causes VC++ redefinition error func2(i);
Short-term Solution: I just removed any variable redefinitions that caused compiler errors under VC++. This may now result in warnings on other platforms. This is undesirable and I don't want to suggest that the code should conform to VC++ non-conformance...
This is not non-conformance, if you find constructs like the ones you mentioned, you have to change them, this is true for all platforms.
int i; for (i=0;...) ...
Trying to compile GEM on linux yields problems now:
for (int i=0;i<10;i++) a[i] = b[i]; for (i=0;i<10;i++) a[i] = b[i];
does not work.
should be
int i; for (i=0;i<10;i++) a[i] = b[i]; for (i=0;i<10;i++) a[i] = b[i];
... changed and checked in for Geos/newWave.cpp Pixes/pix_convolve.cpp
Guenter
Hallo, guenter geiger hat gesagt: // guenter geiger wrote:
Trying to compile GEM on linux yields problems now:
for (int i=0;i<10;i++) a[i] = b[i]; for (i=0;i<10;i++) a[i] = b[i];
The first line in C++ declares and defines i as a variable local to the loop and its body ("a[i] = b[i];"). i is gone after the loop ends.
In the second line, i is thus not known at all, so this must lead to an error.
_From Daniel's error, it seems, VC++ doesn't define i fully local to the loop. This is wrong, but there's not much we can do about it.
ciao
hi
i had a look at pix_convolve over the past two days, and i just committed my changes:
- yuv support added - massive speed improvement by using integer processing (at least 2x but 5x in some cases) - removed the range divide (only added insult to the injury) - yuv function has option to discard chroma for accurate edge-detection - added an #ifdef so RGB works properly on OSX
i'm going to write a 3x3 specific function this weekend and see what sort of optimizations can be done with using greater number of registers, unrolled loops, etc. i'll give altivec a shot too. maybe at that point it will be useful to write abstractions based on pix_convolve. now, at least it's somewhat usable on machines available today.
cgc
I thought I had written a specific 3x3 function and changed pix_convolve to integer. Had thought this got into to CVS :(
Anyhow, you will definitely gain a lot with these optimizations.
Greetings, Guenter
On Sat, 1 Mar 2003, chris clepper wrote:
hi
i had a look at pix_convolve over the past two days, and i just committed my changes:
- yuv support added
- massive speed improvement by using integer processing (at least 2x
but 5x in some cases)
- removed the range divide (only added insult to the injury)
- yuv function has option to discard chroma for accurate edge-detection
- added an #ifdef so RGB works properly on OSX
i'm going to write a 3x3 specific function this weekend and see what sort of optimizations can be done with using greater number of registers, unrolled loops, etc. i'll give altivec a shot too. maybe at that point it will be useful to write abstractions based on pix_convolve. now, at least it's somewhat usable on machines available today.
cgc
PD-dev mailing list PD-dev@iem.kug.ac.at http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-dev
I thought I had written a specific 3x3 function and changed pix_convolve to integer. Had thought this got into to CVS :(
You did!! but it's part of the #ifdef MMX so i didn't want to mess with it and risk breaking something. is there actually any MMX code in pix_convolve? the MMULT() used is defined immediately before processImage() as (a*b>>8), which doesn't look like MMX. should the MMX ifdef be removed? have you checked out the way i've done the altivec code for some of the other pix_? maybe implement MMX in the same way...
Anyhow, you will definitely gain a lot with these optimizations.
yep, night and day. i'm going to write a yuv version of your 3x3 and hopefully get that and the rgb one altivec'd this weekend.
cgc
Greetings, Guenter
On Sat, 1 Mar 2003, chris clepper wrote:
hi
i had a look at pix_convolve over the past two days, and i just committed my changes:
- yuv support added
- massive speed improvement by using integer processing (at least 2x
but 5x in some cases)
- removed the range divide (only added insult to the injury)
- yuv function has option to discard chroma for accurate edge-detection
- added an #ifdef so RGB works properly on OSX
i'm going to write a 3x3 specific function this weekend and see what sort of optimizations can be done with using greater number of registers, unrolled loops, etc. i'll give altivec a shot too. maybe at that point it will be useful to write abstractions based on pix_convolve. now, at least it's somewhat usable on machines available today.
cgc
PD-dev mailing list PD-dev@iem.kug.ac.at http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-dev
On Sat, 1 Mar 2003, chris clepper wrote:
I thought I had written a specific 3x3 function and changed pix_convolve to integer. Had thought this got into to CVS :(
You did!! but it's part of the #ifdef MMX so i didn't want to mess with it and risk breaking something. is there actually any MMX code in pix_convolve? the MMULT() used is defined immediately before processImage() as (a*b>>8), which doesn't look like MMX. should the MMX ifdef be removed? have you checked out the way i've done the altivec code for some of the other pix_? maybe implement MMX in the same way...
Anyhow, you will definitely gain a lot with these optimizations.
yep, night and day. i'm going to write a yuv version of your 3x3 and hopefully get that and the rgb one altivec'd this weekend.
Ok, I think the MMX is disabled ATM, because the gain was not substantial, I take a look why the optimizations are in #ifdef MMX, should not be the case.
Guenter
On Fri, 28 Feb 2003, Frank Barknecht wrote:
Hallo, guenter geiger hat gesagt: // guenter geiger wrote:
Trying to compile GEM on linux yields problems now:
for (int i=0;i<10;i++) a[i] = b[i]; for (i=0;i<10;i++) a[i] = b[i];
The first line in C++ declares and defines i as a variable local to the loop and its body ("a[i] = b[i];"). i is gone after the loop ends.
In the second line, i is thus not known at all, so this must lead to an error.
_From Daniel's error, it seems, VC++ doesn't define i fully local to the loop. This is wrong, but there's not much we can do about it.
I think the constructs should just not be used this way. Then there will be no problems. It doesn't compile on gcc-2.95 anyhow (with or without the second loop), so we have to declare the variable before the loop and all is fine.
Guenter
-
chris clepper -
Daniel Heckenberg -
Frank Barknecht -
guenter geiger