Page 1 of 1

Ogre 64 bits

Posted: Tue Sep 26, 2006 10:51 am
by tenaciusgordon
Hello, we are a group of people that we are trying to use Ogre for 64 bits with windows x64, Somebody has been able to use it??

As Ogre depends on third part (like envidiacg.dll, devin.dll..... till 12) we are not able to do it.

Thanks in advance

Posted: Tue Sep 26, 2006 1:44 pm
by tuan kuranes
I've successfully compiled once all in win x64.

Devil, cegui and zzip are really easy to build in x64 way, no need of special patches, just change target cpu build target in vc2005. zlib already has a x64 target. CG from nvidia can be downloaded specifically for x64 too.
Same for ogre, it's just a target change.

I didn't continue on that, as I didn't get any speed improvements at all, even if it was supposed to use "sse3 and new registers automatically" if we believe marketing from ms and amd.

Posted: Tue Sep 26, 2006 2:33 pm
by genva
The SSE optimisation in Eihort was truned off for x64 targets, as I haven't have compiler to build it up, as well as I never intsalled Win64/Linux64 at all, even though my hardware is ready for x64 (AMD Athlon x64 here). The gcc compiler I used is come from cygwin, version 3.4.4, it doesn't build with cross compile x64 target too. So, I have no ways to test with x64 for now.

Posted: Tue Sep 26, 2006 2:58 pm
by tuan kuranes
My x64 test was with dagon anyway, with genva eihort sse optimisations, it surely will be faster to use 32bits version, even on x64 cpu.

@genva: just to be sure, I was speaking of compiler automatic sse3 code generation and amd64 register use. That said I never took the time to read x64 code generated by vc2005 to check reality of those marketing announces. In term of Ogre FPS, it was null anyway.

Posted: Tue Sep 26, 2006 3:13 pm
by tenaciusgordon
We are not really focused on the performance of the 3D engine. We have studied different engines Illricht, Blender... and finally have decided to use OGRE, not only because of its nice visual features but because of its good and understandable code.
Our main target is to have a 3D engine for X64 (and x86), not because of its "improved?" speed, but because our application must work on x64.

Our team has 4 * 64 bit machines with win x64. We are going to try hard to make it work on x64 and hopefully have some examples for next week. If you are interested in our help for an x64 version of Ogre, just tell me.

Regards.

Posted: Tue Sep 26, 2006 10:39 pm
by sinbad
We always welcome compatibility patches for all platforms, please see the 'Developers' page on the main site for patch submission procedure should you need to change anything (hopefully most if not all should be ok).

Posted: Wed Sep 27, 2006 9:28 am
by tenaciusgordon
We have no experience compiling third party DLLs,

We have found some problems compiling the Ogre external dependencies, but we are still making ourselves an overall idea on how to compile everything, the way of working you have and so on.....

We are now having trouble compiling DevIL.DLL, ILU.DLL and ZLIB1.DLL, which we have searched through Internet. We assume that it is because we are using different versions, in fact, the projects create DLLs with different names which we have renamed in a hopeless try to make it work (we don't manage to either compile the win32 dynamic version). Where can we find the "good" or official projects of these DLLs that link with Ogre?

Any help will be really welcome and will accelerate the results

Regards

Posted: Wed Sep 27, 2006 2:14 pm
by tuan kuranes
http://www.zlib.net/
http://sourceforge.net/projects/openil

Resulting dll names may not be the same, but that's not a problem if you link against them, but do not rename them.

Thing to make sure is that they compile using "multithreaded dll" in each project settings.

Re: Ogre 64 bits

Posted: Sat Mar 28, 2009 12:36 am
by Crisis
x64 could be cool as part of SDK

Re: Ogre 64 bits

Posted: Wed Dec 30, 2009 3:38 am
by plwuxin
i d like to make sure if OGRE perform normal with Windows X64? anyone

Re: Ogre 64 bits

Posted: Wed Dec 30, 2009 8:46 am
by Azgur
plwuxin wrote:i d like to make sure if OGRE perform normal with Windows X64? anyone
I haven't run into any issues running 32bit software on 64bit Windows.
This includes Ogre.

Running your Ogre application as a 64bit application has some advantages, but most of the time they are neglectable for most common uses.

Re: Ogre 64 bits

Posted: Wed Dec 30, 2009 4:41 pm
by kaolite
I have recompiled all dependencies in x64 (the most difficult) ... and Ogre compile without trouble in X64... seems to works fine

Re: Ogre 64 bits

Posted: Thu Jan 07, 2010 11:14 pm
by guyver6
Hi,

I was trying to get Ogre3D working on Snow Leopard in 64 bits. I got compiled needed dependencies (except OIS of course ;) ), patched Ogre a little (patch against v1_7 branch attached), and... I hit a compiler error. I'm using GCC 4.2, as it is supported for 10.5+ SDKs (and I've tried building against 10.5 and 10.6 and the result is the same - linking error due to bad code generation from GCC 4.2). Anyway, I even filed a bug with Apple's radar about the issue. The exact error is like this:

Code: Select all

ld: codegen problem, can't use rel32 to external symbol std::basic_ostream<char, std::char_traits<char> >& 
std::endl<char, std::char_traits<char> >(std::basic_ostream<char, std::char_traits<char> >&)in Ogre::operator<<(std::basic_ostream<char, std::char_traits<char> >&, Ogre::ConvexBody const&)from /Users/endru/work/ogre3d/builds/cthugha/lib/OGRE.build/Debug/OgreMain.build/Objects-normal/x86_64/OgreConvexBody.o
It happens during linking only, and the problem is std::endl symbol referenced in OgreConvexBody (and in some more files actually; if you generate asm using -S GCC option instead of -c, you're able to fix the mis-compilation of OgreConvexBody and the rest of std::endl users and it links without problems). The workaround is to use GCC 4.0 (and get suboptimal performance on x86_64, since in GCC 4.2 there were a lot of optimizations dedicated to that architecute).

So, this is just an informational post if someone tries and dies trying to do the same. Oh, and the patch might be useful (it turns off Carbon for __LP64__ compilations).

PS. Maybe someone is interested in the bug report, so it's radar number is 7511396, and here it is quoted:
SUMMARY:
Unable to link Ogre3D using GCC 4.2 targetting x86_64 due to badly generated asm code.

STEPS TO REPRODUCE:
Excuse the long list of steps needed to reproduce, but I couldn't get smaller samples to reproduce the same error. Here it goes:
1. Install Ogre3D dependencies (you need to provide 64-bit versions of those, I'll attach these if radar allows me to): Freetype, FreeImage, Cg-2.2 (from NVidia, you'll need to untar to root directory the NVIDIA_Cg.tgz file included in the DMG you download from NVidia, because it fails to install on Snow Leopard) and zziplib. These are enough to reproduce bug.
2. Install CMake
3. Fetch Ogre3D from SVN (Cthugha, revision 9548 - the one tested by me few moments ago, and the one that I patched to remove Carbon related code):
svn co https://svn.ogre3d.org/svnroot/ogre/branches/v1-7@9548 cthugha
4. Apply x86_64 patch (attached to this report):
cd cthugha
patch -p0 <../x86_64.patch
5. Make build directory:
mkdir ../build-cthugha
cd ../build-cthugha
6. Run CMake here:
cmake-gui ../cthugha
7. Click Configure
8. Change following settings from their default:
CMAKE_BUILD_TYPE = Debug
CMAKE_OSX_ARCHITECTURES = x86_64
OGRE_CONFIG_THREADS = 0
OGRE_USE_BOOST = false (uncheck)
9. Click Configure and then click Generate, select Xcode as generator, then next next next etc.
10. Close CMake and run from within build-cthugha:
open OGRE.xcodeproj
11. Build OgreMain target

EXPECTED RESUlTS:
Properly linked Ogre.framework

ACTUAL RESULTS
After compiling all files, linking results in following error:

ld: codegen problem, can't use rel32 to external symbol std::basic_ostream<char, std::char_traits<char> >&
std::endl<char, std::char_traits<char> >(std::basic_ostream<char, std::char_traits<char> >&)in Ogre::operator<<(std::basic_ostream<char, std::char_traits<char> >&, Ogre::ConvexBody const&)from /Users/endru/work/ogre3d/builds/cthugha/lib/OGRE.build/Debug/OgreMain.build/Objects-normal/x86_64/OgreConvexBody.o

REGRESSIONS:
GCC 4.0 properly generates code that is linked without any problems for x86_64 target

NOTES:
I was able to investigate the problem to degree that I know why there is linking error there.
Comparing ASM output from GCC 4.0 and GCC 4.2, both targetting x86_64 arch, there is a difference in a symbol reference to std::endl, namely GCC 4.0 produces:

movq __ZSt4endlIcSt11char_traitsIcEERSt13basic_ostreamIT_T0_ES6_@GOTPCREL(%rip), %rsi

while GCC 4.2 produces:

leaq __ZSt4endlIcSt11char_traitsIcEERSt13basic_ostreamIT_T0_ES6_(%rip), %rsi

The code samples I was throwing at GCC 4.2 using the same setup (CMake generating Xcode project), but for one C++ file generated code similar to GCC 4.0 with @GOTPCREL at the end of a symbol. My best guess is that this is GCC 4.2 codegen bug triggered by huge precompiled header and basicly huge piece of code to compile, unable to reproduce with small samples. Also, the __ZSt4endlIcSt11char_traitsIcEERSt13basic_ostreamIT_T0_ES6_ symbol (std::endl) is the only one there is problem with.

Re: Ogre 64 bits

Posted: Fri Jan 08, 2010 3:02 pm
by gapgen
Thanks, guyver6, that's exactly what I'm currently tearing my hair out over.

Compiled 64-bit OSX10.5/6 dependencies would be really useful to have, if you can put them up - apparently 'configure' under Snow Leopard gets confused by something and by default sets itself to i386, not x86_64. I still haven't quite worked these out, and messing around with the time-consuming make process in Ogre is tiring.

Re: Ogre 64 bits

Posted: Fri Jan 08, 2010 4:41 pm
by sinbad
gapgen wrote:apparently 'configure' under Snow Leopard gets confused by something and by default sets itself to i386, not x86_64.
This is because of this section in CMakeList.txt in the root folder:

Code: Select all

  # 10.6 sets x86_64 as the default architecture.
  # Because Carbon isn't supported on 64-bit and we still need it, force the architectures to ppc and i386
  if(CMAKE_OSX_DEPLOYMENT_TARGET STREQUAL "10.6")
	  set(CMAKE_OSX_ARCHITECTURES "ppc i386")
  endif()
I'm still a total noob on Carbon / Cocoa but does this mean that we're Carbon-free now, if you managed to build x86_64? masterfalcon?

[edit]nm, I see you just commented out the Carbon bits so presumably this was just a build test and not a runtime test. So we'd still need to become pure Cocoa-based to support x86_64 on OS X.

Re: Ogre 64 bits

Posted: Fri Jan 08, 2010 5:03 pm
by gapgen
Yes, commented out the ppc i386 line and made sure there were no references to i386 in the CMake products before running "make". I dodged the infinite cmake loop by following the instructions in the relevant thread on this forum and then altering the CMake products again, although this is probably error-prone in itself.

I'd prefer to use x86_64 as my intended application is memory-intensive and I don't particularly need to use Carbon unless it's integral to the way Ogre works on Mac OS. The same problem with "configure" exists for building the dependencies, as I understand it. Ogre is reporting architecture differences with zzlib, freetype and boost even after recompiling under Snow Leopard. Fiddling with the compile settings hasn't (yet) made the problem go away, although I'm kinda fumbling in the dark as I'm not particularly an expert on Unix or the intricacies of Mac OS.

Re: Ogre 64 bits

Posted: Sat Jan 09, 2010 12:54 am
by guyver6
@gapgen: Here are the dependencies (freetype, freeimage and zziplib) compiled for Snow Leopard-like architectures (i386, x86_64 and ppc). Boost is building just fine for universal binary (I build it with "bjam --layout=system architecture=combined address-model=32_64 stage"), NVIDIA Cg 2.2 requires some manual installation but includes these architectures already (you have to dig into the mounted DMG like this: "cd /Volumes/Cg-2.2.0010/Cg-2.2.0010.app/Contents/Resources/Installer\ Items/", then there is NVIDIA_Cg.tgz file that you have to untar in root to install Cg on Snow Leopard). OIS is still using legacy event management from Carbon and I hadn't time to dig into that hole yet.

Ogre 3D OSX Dependnecies for 3 architectures (i386 ppc and x86_64) (I had to use rapidshare, since it's too large for forum)

For now the workaround for compiler bug is to use GCC 4.0 while targetting 10.5 or 10.6 SDK.

Oh, and forcing the compiler version in CMakeLists puts CMake into infinite loop when using Makefile generator, but you know that already (took me a day to figure out ;) )... oh, I just realized that I haven't tested the GCC 4.2 using Makefiles... hmm, lets see...

Re: Ogre 64 bits

Posted: Sat Jan 09, 2010 1:06 am
by guyver6
sinbad wrote:I'm still a total noob on Carbon / Cocoa but does this mean that we're Carbon-free now, if you managed to build x86_64? masterfalcon?

[edit]nm, I see you just commented out the Carbon bits so presumably this was just a build test and not a runtime test. So we'd still need to become pure Cocoa-based to support x86_64 on OS X.
I'm noob in that land too, so don't mind my quick hack ;) I'm trying to understand the whole idea behind the run loops in OSX and how Carbon requires totally different approach when handling events than Cocoa, maybe if my mind wraps that I'll submit a better patch. That compiler bug put me off for a while, because I've wasted lots of time on it :( (I thought Apple did better with their GCC version, but it seems that Apple's investing more compiler developers time in Clang / LLVM than good old GCC).

Re: Ogre 64 bits

Posted: Sat Jan 09, 2010 6:00 pm
by gapgen
Thanks! I'll give those dependencies a go.

Re: Ogre 64 bits

Posted: Tue Jan 19, 2010 2:13 am
by shredder
Hey guys !

This is the first time I try recompiling librairies for 64 bits OS, anyone would be kind enough to give me an how-to guide ?

(Using Windows 7 x64 with Visual Studios 2008)

Thanks !

-Shredder

Re: Ogre 64 bits

Posted: Mon Mar 08, 2010 11:23 pm
by TV4Fun
guyver6 wrote:Hi,

I was trying to get Ogre3D working on Snow Leopard in 64 bits. I got compiled needed dependencies (except OIS of course ;) ), patched Ogre a little (patch against v1_7 branch attached), and... I hit a compiler error. I'm using GCC 4.2, as it is supported for 10.5+ SDKs (and I've tried building against 10.5 and 10.6 and the result is the same - linking error due to bad code generation from GCC 4.2). Anyway, I even filed a bug with Apple's radar about the issue. The exact error is like this:

Code: Select all

ld: codegen problem, can't use rel32 to external symbol std::basic_ostream<char, std::char_traits<char> >& 
std::endl<char, std::char_traits<char> >(std::basic_ostream<char, std::char_traits<char> >&)in Ogre::operator<<(std::basic_ostream<char, std::char_traits<char> >&, Ogre::ConvexBody const&)from /Users/endru/work/ogre3d/builds/cthugha/lib/OGRE.build/Debug/OgreMain.build/Objects-normal/x86_64/OgreConvexBody.o
It happens during linking only, and the problem is std::endl symbol referenced in OgreConvexBody (and in some more files actually; if you generate asm using -S GCC option instead of -c, you're able to fix the mis-compilation of OgreConvexBody and the rest of std::endl users and it links without problems). The workaround is to use GCC 4.0 (and get suboptimal performance on x86_64, since in GCC 4.2 there were a lot of optimizations dedicated to that architecute).

So, this is just an informational post if someone tries and dies trying to do the same. Oh, and the patch might be useful (it turns off Carbon for __LP64__ compilations).

PS. Maybe someone is interested in the bug report, so it's radar number is 7511396, and here it is quoted:
SUMMARY:
Unable to link Ogre3D using GCC 4.2 targetting x86_64 due to badly generated asm code.

STEPS TO REPRODUCE:
Excuse the long list of steps needed to reproduce, but I couldn't get smaller samples to reproduce the same error. Here it goes:
1. Install Ogre3D dependencies (you need to provide 64-bit versions of those, I'll attach these if radar allows me to): Freetype, FreeImage, Cg-2.2 (from NVidia, you'll need to untar to root directory the NVIDIA_Cg.tgz file included in the DMG you download from NVidia, because it fails to install on Snow Leopard) and zziplib. These are enough to reproduce bug.
2. Install CMake
3. Fetch Ogre3D from SVN (Cthugha, revision 9548 - the one tested by me few moments ago, and the one that I patched to remove Carbon related code):
svn co https://svn.ogre3d.org/svnroot/ogre/branches/v1-7@9548 cthugha
4. Apply x86_64 patch (attached to this report):
cd cthugha
patch -p0 <../x86_64.patch
5. Make build directory:
mkdir ../build-cthugha
cd ../build-cthugha
6. Run CMake here:
cmake-gui ../cthugha
7. Click Configure
8. Change following settings from their default:
CMAKE_BUILD_TYPE = Debug
CMAKE_OSX_ARCHITECTURES = x86_64
OGRE_CONFIG_THREADS = 0
OGRE_USE_BOOST = false (uncheck)
9. Click Configure and then click Generate, select Xcode as generator, then next next next etc.
10. Close CMake and run from within build-cthugha:
open OGRE.xcodeproj
11. Build OgreMain target

EXPECTED RESUlTS:
Properly linked Ogre.framework

ACTUAL RESULTS
After compiling all files, linking results in following error:

ld: codegen problem, can't use rel32 to external symbol std::basic_ostream<char, std::char_traits<char> >&
std::endl<char, std::char_traits<char> >(std::basic_ostream<char, std::char_traits<char> >&)in Ogre::operator<<(std::basic_ostream<char, std::char_traits<char> >&, Ogre::ConvexBody const&)from /Users/endru/work/ogre3d/builds/cthugha/lib/OGRE.build/Debug/OgreMain.build/Objects-normal/x86_64/OgreConvexBody.o

REGRESSIONS:
GCC 4.0 properly generates code that is linked without any problems for x86_64 target

NOTES:
I was able to investigate the problem to degree that I know why there is linking error there.
Comparing ASM output from GCC 4.0 and GCC 4.2, both targetting x86_64 arch, there is a difference in a symbol reference to std::endl, namely GCC 4.0 produces:

movq __ZSt4endlIcSt11char_traitsIcEERSt13basic_ostreamIT_T0_ES6_@GOTPCREL(%rip), %rsi

while GCC 4.2 produces:

leaq __ZSt4endlIcSt11char_traitsIcEERSt13basic_ostreamIT_T0_ES6_(%rip), %rsi

The code samples I was throwing at GCC 4.2 using the same setup (CMake generating Xcode project), but for one C++ file generated code similar to GCC 4.0 with @GOTPCREL at the end of a symbol. My best guess is that this is GCC 4.2 codegen bug triggered by huge precompiled header and basicly huge piece of code to compile, unable to reproduce with small samples. Also, the __ZSt4endlIcSt11char_traitsIcEERSt13basic_ostreamIT_T0_ES6_ symbol (std::endl) is the only one there is problem with.
guyver, where did you submit that bug report, and do you know if there's been any action taken on it?

Re: Ogre 64 bits

Posted: Thu Apr 08, 2010 10:49 pm
by danfma
Guyver6, you are the man!! hehe...

I will try the code as soon as I can...

Re: Ogre 64 bits

Posted: Fri Apr 09, 2010 9:12 am
by guyver6
TV4Fun wrote:guyver, where did you submit that bug report, and do you know if there's been any action taken on it?
Sorry I answer with such a delay, haven't notice the question. I reported it to Apple's radar (http://bugreport.apple.com/), but they haven't tacked it yet (if they ever will). The Radar #7511396.