A ReadMe.txt file in the root directory of the expanded package has some details.

These are 64-bit builds with the default GL2 OpenGL level and these dependencies: curl, freetype, giflib, glut, jpeg, lpng, minizip, tiff, zlib. We can add other plugins (GDAL, Collada, ...) based on community interest.

There is a vanilla VC++ build and also builds optimized for AVX2 (Haswell and later) CPUs. We are going to do some performance comparisons to see if the AVX2 and/or Intel C++ are beneficial for our application: we also welcome feedback on performance from the community.

The Intel C++ build should be binary compatible with VC++ 2015 so you don't need Intel C++ to use it. Note that it was built with /fp:fast=2 to enable auto-vectorization of floating point loops: this could cause small precision loss that might matter with larger/geo distance scales. If vectorization isn't significant/beneficial this option may be dropped: input on this is welcomed.

We hope to do some OSG profiling and experiment with tuning on the Windows side with VTune: if we find anything interesting we'll post it on our OSG page and submit code back to the developers.

We don't have a need for 32-bit builds or older compilers but feel free to ask .

Since we need these ourselves we plan to post binaries for future OSG and compiler releases as a way to give back to the OSG community.

First of all: Thank you for giving something back to the community.
Can you elaborate on the specific versions used for the 3rd-party
libraries? Especially if you compiled against Qt and possibly which version.

A ReadMe.txt file in the root directory of the expanded package has some details.

These are 64-bit builds with the default GL2 OpenGL level and these dependencies: curl, freetype, giflib, glut, jpeg, lpng, minizip, tiff, zlib. We can add other plugins (GDAL, Collada, ...) based on community interest.

There is a vanilla VC++ build and also builds optimized for AVX2 (Haswell and later) CPUs. We are going to do some performance comparisons to see if the AVX2 and/or Intel C++ are beneficial for our application: we also welcome feedback on performance from the community.

The Intel C++ build should be binary compatible with VC++ 2015 so you don't need Intel C++ to use it. Note that it was built with /fp:fast=2 to enable auto-vectorization of floating point loops: this could cause small precision loss that might matter with larger/geo distance scales. If vectorization isn't significant/beneficial this option may be dropped: input on this is welcomed.

Interesting, can you point to some sources why the /fp:fast is needed
for auto-vectorization? I'm pretty sure I've seen at least SSE2
vectorization on some meta-programming matrix code of mine. Precision
is a real issue for me, so forgive my skepticism.

Quote:

We hope to do some OSG profiling and experiment with tuning on the Windows side with VTune: if we find anything interesting we'll post it on our OSG page and submit code back to the developers.

We don't have a need for 32-bit builds or older compilers but feel free to ask .

Since we need these ourselves we plan to post binaries for future OSG and compiler releases as a way to give back to the OSG community.

Interesting, can you point to some sources why the /fp:fast is needed
for auto-vectorization? I'm pretty sure I've seen at least SSE2
vectorization on some meta-programming matrix code of mine. Precision
is a real issue for me, so forgive my skepticism.

It is probably most accurate to say that some vectorization is possible without the "fast" options but avoiding associativity limits vectorization. I'm not sure if /fp:fast=1 gives the full auto-vectorization with less precision loss. It would be good to have an option that allows reordering for loop vectorization but still uses the full precision math library calls, but I don't think that exists. I get the sensitivity to precision, which is why I'm trying to indicate that this first Intel C++ build is sort of experimental. Once we give it a workout and see the positive and negative effects of various options we'll know better what build variations are worth providing.

Interesting, can you point to some sources why the /fp:fast is needed
for auto-vectorization? I'm pretty sure I've seen at least SSE2
vectorization on some meta-programming matrix code of mine. Precision
is a real issue for me, so forgive my skepticism.

It is probably most accurate to say that some vectorization is possible without the "fast" options but avoiding associativity limits vectorization. I'm not sure if /fp:fast=1 gives the full auto-vectorization with less precision loss. It would be good to have an option that allows reordering for loop vectorization but still uses the full precision math library calls, but I don't think that exists. I get the sensitivity to precision, which is why I'm trying to indicate that this first Intel C++ build is sort of experimental. Once we give it a workout and see the positive and negative effects of various options we'll know better what build variations are worth providing.

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot vote in polls in this forumYou cannot attach files in this forumYou cannot download files in this forum