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.

Ogre 64 bits

Postby tenaciusgordon » Tue Sep 26, 2006 10:51 am

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
tenaciusgordon
Gnoblar
 
Posts: 3
Kudos: 0
Joined: 26 Sep 2006
Location: Madrid (Spain)

Postby tuan kuranes » Tue Sep 26, 2006 1:44 pm

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.
User avatar
tuan kuranes
OGRE Retired Moderator
OGRE Retired Moderator
 
Posts: 3064
Kudos: 4
Joined: 24 Sep 2003
Location: Haute Garonne, France

Postby genva » Tue Sep 26, 2006 2:33 pm

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.
genva
OGRE Retired Team Member
OGRE Retired Team Member
 
Posts: 1604
Kudos: 0
Joined: 20 Oct 2004
Location: Beijing, China

Postby tuan kuranes » Tue Sep 26, 2006 2:58 pm

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
tuan kuranes
OGRE Retired Moderator
OGRE Retired Moderator
 
Posts: 3064
Kudos: 4
Joined: 24 Sep 2003
Location: Haute Garonne, France

Postby tenaciusgordon » Tue Sep 26, 2006 3:13 pm

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
tenaciusgordon
Gnoblar
 
Posts: 3
Kudos: 0
Joined: 26 Sep 2006
Location: Madrid (Spain)

Postby sinbad » Tue Sep 26, 2006 10:39 pm

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
sinbad
OGRE Founder (Retired)
OGRE Founder (Retired)
 
Posts: 25870
Kudos: 63
Joined: 06 Oct 2002
Location: Guernsey, Channel Islands

Postby tenaciusgordon » Wed Sep 27, 2006 9:28 am

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
tenaciusgordon
Gnoblar
 
Posts: 3
Kudos: 0
Joined: 26 Sep 2006
Location: Madrid (Spain)

Postby tuan kuranes » Wed Sep 27, 2006 2:14 pm

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.
User avatar
tuan kuranes
OGRE Retired Moderator
OGRE Retired Moderator
 
Posts: 3064
Kudos: 4
Joined: 24 Sep 2003
Location: Haute Garonne, France

Re: Ogre 64 bits

Postby Crisis » Sat Mar 28, 2009 12:36 am

x64 could be cool as part of SDK
Crisis
Gnoblar
 
Posts: 1
Kudos: 0
Joined: 28 Mar 2009

Re: Ogre 64 bits

Postby plwuxin » Wed Dec 30, 2009 3:38 am

i d like to make sure if OGRE perform normal with Windows X64? anyone
程序员是高尚的,博士是伟大的,程序员博士就是苦逼的了。
plwuxin
Gnoblar
 
Posts: 2
Kudos: 0
Joined: 09 Dec 2009

Re: Ogre 64 bits

Postby Azgur » Wed Dec 30, 2009 8:46 am

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.
User avatar
Azgur
Goblin
 
Posts: 264
Kudos: 0
Joined: 21 Aug 2008

Re: Ogre 64 bits

Postby kaolite » Wed Dec 30, 2009 4:41 pm

I have recompiled all dependencies in x64 (the most difficult) ... and Ogre compile without trouble in X64... seems to works fine
kaolite
Halfling
 
Posts: 78
Kudos: 0
Joined: 06 Feb 2009

Re: Ogre 64 bits

Postby guyver6 » Thu Jan 07, 2010 11:14 pm

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 95 times
User avatar
guyver6
Greenskin
 
Posts: 143
Kudos: 0
Joined: 23 Dec 2002
Location: Warsaw, Poland

Re: Ogre 64 bits

Postby gapgen » Fri Jan 08, 2010 3:02 pm

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.
gapgen
Gnoblar
 
Posts: 10
Kudos: 0
Joined: 09 Dec 2009

Re: Ogre 64 bits

Postby sinbad » Fri Jan 08, 2010 4:41 pm

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.
User avatar
sinbad
OGRE Founder (Retired)
OGRE Founder (Retired)
 
Posts: 25870
Kudos: 63
Joined: 06 Oct 2002
Location: Guernsey, Channel Islands

Re: Ogre 64 bits

Postby gapgen » Fri Jan 08, 2010 5:03 pm

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.
gapgen
Gnoblar
 
Posts: 10
Kudos: 0
Joined: 09 Dec 2009

Re: Ogre 64 bits

Postby guyver6 » Sat Jan 09, 2010 12:54 am

@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: 143
Kudos: 0
Joined: 23 Dec 2002
Location: Warsaw, Poland

Re: Ogre 64 bits

Postby guyver6 » Sat Jan 09, 2010 1:06 am

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).
User avatar
guyver6
Greenskin
 
Posts: 143
Kudos: 0
Joined: 23 Dec 2002
Location: Warsaw, Poland

Re: Ogre 64 bits

Postby gapgen » Sat Jan 09, 2010 6:00 pm

Thanks! I'll give those dependencies a go.
gapgen
Gnoblar
 
Posts: 10
Kudos: 0
Joined: 09 Dec 2009

Re: Ogre 64 bits

Postby shredder » Tue Jan 19, 2010 2:13 am

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
shredder
Gnoblar
 
Posts: 11
Kudos: 0
Joined: 19 Jan 2010

Re: Ogre 64 bits

Postby TV4Fun » Mon Mar 08, 2010 11:23 pm

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?
TV4Fun
Halfling
 
Posts: 51
Kudos: 0
Joined: 16 Mar 2004

Re: Ogre 64 bits

Postby danfma » Thu Apr 08, 2010 10:49 pm

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
danfma
Gnoblar
 
Posts: 2
Kudos: 0
Joined: 08 Apr 2010
Location: Goiania - GO / Brazil

Re: Ogre 64 bits

Postby guyver6 » Fri Apr 09, 2010 9:12 am

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.
User avatar
guyver6
Greenskin
 
Posts: 143
Kudos: 0
Joined: 23 Dec 2002
Location: Warsaw, Poland


Return to Developer talk

Who is online

Users browsing this forum: No registered users and 2 guests