Ogre 64 bits

Discussion area about developing or extending OGRE, adding plugins for it or building applications on it. No newbie questions please, use the Help forum for that.
Post Reply
User avatar
tenaciusgordon
Gnoblar
Posts: 3
Joined: Tue Sep 26, 2006 10:43 am
Location: Madrid (Spain)

Ogre 64 bits

Post 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
User avatar
tuan kuranes
OGRE Retired Moderator
OGRE Retired Moderator
Posts: 2653
Joined: Wed Sep 24, 2003 8:07 am
Location: Haute Garonne, France
x 4
Contact:

Post 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.
genva
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 1603
Joined: Wed Oct 20, 2004 7:54 am
Location: Beijing, China
x 1

Post 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.
User avatar
tuan kuranes
OGRE Retired Moderator
OGRE Retired Moderator
Posts: 2653
Joined: Wed Sep 24, 2003 8:07 am
Location: Haute Garonne, France
x 4
Contact:

Post 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.
User avatar
tenaciusgordon
Gnoblar
Posts: 3
Joined: Tue Sep 26, 2006 10:43 am
Location: Madrid (Spain)

Post 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.
User avatar
sinbad
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 19269
Joined: Sun Oct 06, 2002 11:19 pm
Location: Guernsey, Channel Islands
x 66
Contact:

Post 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).
User avatar
tenaciusgordon
Gnoblar
Posts: 3
Joined: Tue Sep 26, 2006 10:43 am
Location: Madrid (Spain)

Post 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
User avatar
tuan kuranes
OGRE Retired Moderator
OGRE Retired Moderator
Posts: 2653
Joined: Wed Sep 24, 2003 8:07 am
Location: Haute Garonne, France
x 4
Contact:

Post 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.
Crisis
Gnoblar
Posts: 1
Joined: Sat Mar 28, 2009 12:26 am

Re: Ogre 64 bits

Post by Crisis »

x64 could be cool as part of SDK
plwuxin
Gnoblar
Posts: 2
Joined: Wed Dec 09, 2009 4:34 am

Re: Ogre 64 bits

Post by plwuxin »

i d like to make sure if OGRE perform normal with Windows X64? anyone
程序员是高尚的,博士是伟大的,程序员博士就是苦逼的了。
User avatar
Azgur
Goblin
Posts: 264
Joined: Thu Aug 21, 2008 4:48 pm

Re: Ogre 64 bits

Post 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.
kaolite
Halfling
Posts: 78
Joined: Fri Feb 06, 2009 7:04 pm

Re: Ogre 64 bits

Post by kaolite »

I have recompiled all dependencies in x64 (the most difficult) ... and Ogre compile without trouble in X64... seems to works fine
User avatar
guyver6
Greenskin
Posts: 106
Joined: Mon Dec 23, 2002 10:16 pm
Location: Warsaw, Poland

Re: Ogre 64 bits

Post 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.
Attachments
osx-x86_64.zip
Mac OS X 64-bit patch
(1.28 KiB) Downloaded 129 times
gapgen
Gnoblar
Posts: 10
Joined: Wed Dec 09, 2009 1:05 pm

Re: Ogre 64 bits

Post 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.
User avatar
sinbad
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 19269
Joined: Sun Oct 06, 2002 11:19 pm
Location: Guernsey, Channel Islands
x 66
Contact:

Re: Ogre 64 bits

Post 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.
gapgen
Gnoblar
Posts: 10
Joined: Wed Dec 09, 2009 1:05 pm

Re: Ogre 64 bits

Post 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.
User avatar
guyver6
Greenskin
Posts: 106
Joined: Mon Dec 23, 2002 10:16 pm
Location: Warsaw, Poland

Re: Ogre 64 bits

Post 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...
User avatar
guyver6
Greenskin
Posts: 106
Joined: Mon Dec 23, 2002 10:16 pm
Location: Warsaw, Poland

Re: Ogre 64 bits

Post 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).
gapgen
Gnoblar
Posts: 10
Joined: Wed Dec 09, 2009 1:05 pm

Re: Ogre 64 bits

Post by gapgen »

Thanks! I'll give those dependencies a go.
shredder
Gnoblar
Posts: 11
Joined: Tue Jan 19, 2010 2:09 am

Re: Ogre 64 bits

Post 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
TV4Fun
Gnoblar
Posts: 19
Joined: Tue Mar 16, 2004 8:43 am
Contact:

Re: Ogre 64 bits

Post 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?
User avatar
danfma
Gnoblar
Posts: 2
Joined: Thu Apr 08, 2010 10:45 pm
Location: Goiania - GO / Brazil
Contact:

Re: Ogre 64 bits

Post by danfma »

Guyver6, you are the man!! hehe...

I will try the code as soon as I can...
---
Daniel Ferreira Monteiro Alves
danfma@gmail.com
User avatar
guyver6
Greenskin
Posts: 106
Joined: Mon Dec 23, 2002 10:16 pm
Location: Warsaw, Poland

Re: Ogre 64 bits

Post 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.
Post Reply