x64 support?

#1 Just wait till you get to the DTS loader.. That was where I bled out. I hope you'll have more luck, I'd definitely be interested in it!

I hope this thread will help you in your venture.

#2 Thanks for that link, will hopefully help.

#3 Ouch, that tsShape looks like it'll be a big one. Think I'm just going to drop this as x64 isn't something I _really_ need for the project I'm working on. Maybe re-visit sometime down the line.

#4 Decided to give this another go with Beta 2 of T3D. After a couple of days fiddling with getting the engine to compile, I finally got to the tsShape. Took me a few hours, but it turned out to be a rather easy fix;

In tsShape::assembleShape instead of using the ptr32 to act as a vector with the mesh, I just pushed the mesh directly on the meshes vector.

TSMesh * mesh = TSMesh::assembleMesh(meshType,skip);
#ifndef _WIN64
      if (ptr32)
         ptr32[i] = skip ?  0 : (S32)mesh;
#else
	  if (ptr32 && !skip)
		  meshes.push_back(mesh);
#endif

}
#ifndef _WIN64
   meshes.set(ptr32,numMeshes);
#endif

Screengrab of the FPS Genre Kit Demo running in x64 mode

Everything seem to be working as it should, but I'm sure there's something I haven't thought about or tested yet. I probably should change that _WIN64 preprocessor test as well to something more generic, any ideas?

Got a local SVN server set up with a clean Beta 2 that I've made these changes against, so making a patch or something should be possible for anyone interested.

#5 heres where i show my level of ignorance..

IS there a point where if you have some of it running in 64 bit mode and some in 32 bit where its considered a 64 bit application, and also is there a point where you get a performance boost of some kind even with a partial port to x64?

and what kind of performance boosts are we looking at here? i was under the impression that even at the OS level x64 isnt fully working and optimised, in much the same ways as threading isnt fully used.. sometimes i feel like i'm driving a ferrari in a go kart circuit with a multi core x64 CPU... never get my foot down and speed up so to speak.

#6 First off you need to be running a 64bit version of your OS, but I'm sure you know that (just making sure).

Running it as an x64 application in Windows for example means you don't have to run the application through the SysWOW32 emulator which emulates 32bit behavior and allowing 32bit applications to run. This alone is known to give a 5-10% performance boost in some cases (I haven't done any tests with T3D yet as I just got it running).

Other then that it also allows for addressing more memory than a 32bit application can. For gamers this wont mean much, but for tools used when developing those games or even servers running the games it can mean a whole lot of difference.

Now, on the other hand a 64bit application will use more memory in most cases as well as much of the internal data structures are 64bit instead of 32bit. This is usually about a 5% increase I think, but again I haven't checked this with T3D.

I'm no expert by no means in this area, so take anything I say with a grain of salt :)

#7 Very cool. Curious to see how well this works or breaks down if you have 32 bit on the client and 64 bit on the server. Either way, hope you keep us updated on this.

#8

Quote:Running it as an x64 application in Windows for example means you don't have to run the application through the SysWOW32 emulator which emulates 32bit behavior and allowing 32bit applications to run. This alone is known to give a 5-10% performance boost in some cases (I haven't done any tests with T3D yet as I just got it running).

And it will guarantee that the memory requirements of terrain collision will explode, compensating and killing any potential gain you get.
And that without taking the problems into account that you can expect when working with 32bit only libraries as some of those in use in Torque.
Getting the dedicated server only to 64bit likely is a much smaller task but having 32bit and 64bit in the same networked environment will likely lead you to other interesting issues.

#9 First off, only lib that T3D uses that is 32bit only is PhysX. The rest I got covered with 64bit versions. I dropped DX8 from the 64bit version as I just didn't bother spending time on that, and I think GG got plans to drop it as well?

Secondly, I just did a network test here with one 32bit client and a 64bit server/client - no problems other than the already reported issue with the lights.cs script in arts/datablocks of the FPS Genre Kit. The datatypes used most places are still 32bit in a 64bit architecture, so not so strange that it works.

Thirdly, why would the memory requirements of terrain collision explode? Again, the datatypes hasn't gone from being 32bit to 64bit. Just checked memory usage 64bit vs. 32bit in the Warrior Camp mission and the 64bit version is using ~8mb more memory (totalling at ~600mb).

This might not be a 'true' 64bit application in the sense of it using all the proper datatypes for that architecture, but that's something that could be worked on.

Like I said in a post earlier, the project I'm working on doesn't really need to support 64bit, so this was all just an exercise for me hoping to help someone that actually might need this.

#10 I expected the memory explosion to be higher due to the dublicated pointer size and the not too small amount of pointers generated by datastructures.

With a really 64bit opted code (not using 32bit variables, which runs into performance reduction as well), the explosion definitely would end higher.


I'm personally on Vista 64 too and don't see a reason to build it for 64bit.
Optimizing it for it isn't a trivial thing, nor does it yield any direct benefit for common games.
Many multi million games have shown that pretty well in the past.
Would see that differently if T3Ds license wouldn't explicitely forbid any non-game usage for the normal licenses.


I've the corresponding check options enabled to ensure that it works on X64 and as a first step, kicked out OpenAL as it is already crap on 32bit, but in conjunction with 64bit its a granted trip to hell. Its a shame that even T3D has it present instead of having a modern main audio library by default, especially when OpenALs track on XP SP3, Vista++ is taken into account.

#11 For the most part I would take 5-10% increase if we are taking FPS in exchange for 10-20% increase in RAM. If you are running a 64bit OS you are probably using 4GB at least anyway as there is no sense if you are below that.

#12 Andreas, that's great news! I agree, not every pointer needs to be 64bit. My idea was to be able to get more physical or virtual memory for the server app, and not be capped at wherever 32 bits cap you. The server app is an mmo-like game's non-distributed server that needs to work with many players at the same time. I believe, that in such a situation, being able to run an x64 server instead of a x86 is a huge leap in performance.

Andreas, are you planning to share details of this endeavour sometime in the future?

#13 I think you can still do assembly with that compiler but not inline. Build the asm file and assemble it with /coff and add the *.obj to the C++ build. As long as you do the extern c references it should link in ok.

#14

Quote:Would see that differently if T3Ds license wouldn't explicitely forbid any non-game usage for the normal licenses.

The license was changed recently, we are no longer restricted to games only. Check post #13 by brett

#15 The networking should be just fine no matter what. It does not assume endian or sizes at all.

Glad this works. Great job!

#16 You can do assembly, but in external .asm files like Howard said. Unfortunately the assembly code in T3D doesn't compile for 64bit out of the box, so I'll have to study up on that part (for now I've just replaced the assembly with instrict functions).

I'm hoping to share this before Beta 3 as I'll need to make a patch for myself so I can move onto the next beta. I've tried to change as little as possible (not changing unsigned int datatypes to size_t for example where it would make sense to do so) and just get this to compile and run. Sortof a first step for 64bit support I guess.

#17 x64 is the future, but it's been slower than expected... Really not sure why Visual Studio doesn't support inline assembly for x64.

Btw, an alternative to the inline assembly in a separate file, is to just use the byte codes and point to them...

#18

Quote:The license was changed recently, we are no longer restricted to games only. Check post #13 by brett

Thank you for mentioning that.
As I already own T3D Pro, so I've no reason to check the graph regularily :)

#19 yes x64 is the future and it is closer than most people think Microsoft said last year that of all windows systems on the planet today 25% of them are already 64 bit. they have said that with Windows 7 x64 will be the default flavor of windows. and that one year after windows 7 Launches they expect 40% of all windows systems on the planet will be 64bit.

So yeah I think that since most games take a year or two to make 64bit needs to be something that we are all thinking about very seriously.

also from I have been told VS2010 is more centered around 64Bit