I haven't blogged in a while because I've been busy with uni and trying to get as much programming done as i can.
I've been working on the processor detection code as it is very important to allow OGE to scale depending on the hardware its running on. It has two possible methods of detecting the information it needs but it depends on the compiler and the operating system that it runs on.
In Visual C++ 2008, it will compile with the newer windows API that provides package/core/logical information. This is only available on windows XP SP3, Vista and Windows Server 2008 (possibly some others that i am not aware of). OGE will check to see if this is available when it is running, if it not, i will revert to the secondary approach.
The secondary approach retrieves the number of logical processors an OS API call, it will then attempt to retrieve the rest of the information from the CPU itself using cpuid. Combining all of this information it can work out the number of cores, although currently it can't work out the number of packages from this.
If both approaches fail, it will default to 1 package, 1 core and 1 logical processor.
On Linux, the primary method is to read in /proc/cpuinfo and parse it to find out all of the processor information it needs. If for some reason it can't do this, it will revert to the secondary approach which is the same as on windows.
Mac support still needs to be done but that can wait till later.
With using these approaches and the features of each compiler, i realise that there is a very specific situation that will result in only the logical processors being detected. This will occur if OGE is compiled using visual studio 2005 as 64bit AND it is executed on a computer that has windows XP SP2 or earlier AND an Intel multi-core processor.
The reason is that visual studio 2005 does not allow use of inline assembly when compiling 64 bit applications, so __cpuid intrinsic must be used. The flaw with it is that it only accepts one input value in EAX, and part of detecting the number of cores requires that ECX be set to 0. This means we can't compile this in, and instead say that it could not be done. As this is the secondary approach, if the target computer is running XP SP3, vista etc it won't ever use this as it will use the primary approach instead. The problem only occurs on Intel multi-core processors because there only they can have hyper-threading.
This is unlikely to ever cause problems as it can be solved in many different ways, such as using visual studio 2008 to compile 64 bit applications (it has __cpuidex intrinsic allowing ECX to be specified).
It has been interesting implementing this, but has taken far too long as well. I will happy to get on with a new task.
Monday, 20 October 2008
Thursday, 25 September 2008
Results!
I've passed my driving exam! yay!!! It went very well. We did the maneuvers very early on so i could relax a bit and just concentrate on driving around. Overall i only got 2 minors, i am very happy!
That's one thing that i don't have to worry about now and i can concentrate on starting uni.
That's one thing that i don't have to worry about now and i can concentrate on starting uni.
Wednesday, 24 September 2008
Nerves
I've got my driving exam tomorrow, part of me is looking forward to it being quietly confident that It'll be OK but the other part of me is nervous. The main reason being that you can't control what other drivers will do, it could only take one dodgy driver to cause me to fail. I'm pretty confident that i can drive to the required standard and perform the maneuvers well enough. I will just have to see how it goes.
This week has been fairly busy where i was at a wedding over the weekend which was good, the last few driving lessons and my exam tomorrow. I also have enrollment day at uni on Monday and i need to buy various things for when i start back.
Doesn't seem long ago that i had a whole four months off, now I'm down to a week...
This week has been fairly busy where i was at a wedding over the weekend which was good, the last few driving lessons and my exam tomorrow. I also have enrollment day at uni on Monday and i need to buy various things for when i start back.
Doesn't seem long ago that i had a whole four months off, now I'm down to a week...
Tuesday, 9 September 2008
System framework improvements
The System's code has had a lot of iterations to it which i do wish i could have gotten to quicker, but it's definitely worth it. It is now a lot slimmer, removing two classes (four source files) without losing any features.
When i first wrote the code it became large because i wanted to make it very flexible. I have now removed redundant code and cleaned it up a lot. The System's code needs to be fast and very solid as its the base for a lot of the engine and its plug-ins. These latest changes should be the last major ones made on these classes now (at last!!).
As it stands we now have:
We had a problem where we would get 50fps in the samples even though they were set to be ticked at 60fps (as well as any movements in the fps sample would causes large frame rate decreases). This problem has disappeared now due to these changes, getting a very stable frame rate even whilst moving around. It is also responsive to small changes in tick intervals.
Ticking the graphics system at 16.6666667 gives a frame rate of 60fps and a tick interval of 16 gives a frame rate of 62fps. Obviously this is what it should do, but it does suggest (i still need to profile to get proof) that there is a very low latency between the primary thread waking up and all of the Systems being ticked.
My next aims are to provide built-in debugging code/features to help with development (especially to track down threading and release mode issues) and possibly improve memory management, as there are a few places where we are allocating and freeing memory a lot.
When i first wrote the code it became large because i wanted to make it very flexible. I have now removed redundant code and cleaned it up a lot. The System's code needs to be fast and very solid as its the base for a lot of the engine and its plug-ins. These latest changes should be the last major ones made on these classes now (at last!!).
As it stands we now have:
- TaskThread - Wraps a thread and provides processing of tasks
- SystemGroup - Manages a group of System's and enforces a specific start up and tear down sequence for each System registered to it, as well as periodical updates (ticks).
- System - Allows a class to be managed by a SystemGroup and receives ticks.
We had a problem where we would get 50fps in the samples even though they were set to be ticked at 60fps (as well as any movements in the fps sample would causes large frame rate decreases). This problem has disappeared now due to these changes, getting a very stable frame rate even whilst moving around. It is also responsive to small changes in tick intervals.
Ticking the graphics system at 16.6666667 gives a frame rate of 60fps and a tick interval of 16 gives a frame rate of 62fps. Obviously this is what it should do, but it does suggest (i still need to profile to get proof) that there is a very low latency between the primary thread waking up and all of the Systems being ticked.
My next aims are to provide built-in debugging code/features to help with development (especially to track down threading and release mode issues) and possibly improve memory management, as there are a few places where we are allocating and freeing memory a lot.
Monday, 25 August 2008
Busy Busy...
Last week i had my driving theory test which i passed! I can't be fully happy until I've passed the practical though which is in a months time. My family, girlfriend and i went to my cousins wedding on the weekend as well, which was good.
Next month is going to be busy as i have another wedding to go to, my driving practical test and enrolment for my final year of uni. My holiday has gone so fast and i don't really feel like I've got much done at all. I had better make this last month count.
Next month is going to be busy as i have another wedding to go to, my driving practical test and enrolment for my final year of uni. My holiday has gone so fast and i don't really feel like I've got much done at all. I had better make this last month count.
Saturday, 16 August 2008
Engine initialisation and threading improvements
I haven't blogged in a while mainly because nothing major has really happened. I've mostly been learning to drive which is going very well. I have my theory test on Thursday which should be OK as I've been doing well on the practice CD i have.
I've just committed a fairly big update to the utilities and the core mainly aimed at threading as well as the engines initialisation sequence. One problem that existed was that for systems that are very slow to initialise (like OGRE) the engine would start running/ticking before it has completed.
There were many different possible solutions but the solution i went for is process every initial request (register/initialise/schedule) and only once every single one has completed, initialisation will finish. Ticking will not occur because the EngineTimingHandler has not been started yet, so game states etc cannot be ticked and cause the original problems.
A problem that existed before and probably emphasised with this solution is that all systems assumed the current time is 0 when they were created, and during initialisation they we're told it was 0. By the time everything has initialised, the time could be at least several seconds later, causing them to calculate very large time intervals which would result in incorrect calculations.
The solution now is that when a system is scheduled it is told the current time, which could be incorrect if the engine hasn't started running yet. The EngineTimingHandler solves this by telling every system that is scheduled the real current time before it starts running.
There are still many improvements to be made to OGE's threading but it has been fairly easy to make the necessary changes so i think our current approach is working well. The main improvement i want to make soon is to get OGE to work out how many threads to create at the start semi automatically. It will take various hints and requirements (from config) and retrieve details about the current CPU (such as number of packages, cores and logical processors) to work out how many threads to create.
On another note, i think its possible for us to get Intel's Threading Building Blocks working in OGE (the scheduler/algorithms part) because it allows you to specify the number of threads that the TBB scheduler can use/create. It would allow us to allocate all the threads we need and then let TBB create the remaining number of threads. On future CPU's with more cores than work that we can allocate from the various systems, we can put more workload onto the tbb scheduler.
I've just committed a fairly big update to the utilities and the core mainly aimed at threading as well as the engines initialisation sequence. One problem that existed was that for systems that are very slow to initialise (like OGRE) the engine would start running/ticking before it has completed.
There were many different possible solutions but the solution i went for is process every initial request (register/initialise/schedule) and only once every single one has completed, initialisation will finish. Ticking will not occur because the EngineTimingHandler has not been started yet, so game states etc cannot be ticked and cause the original problems.
A problem that existed before and probably emphasised with this solution is that all systems assumed the current time is 0 when they were created, and during initialisation they we're told it was 0. By the time everything has initialised, the time could be at least several seconds later, causing them to calculate very large time intervals which would result in incorrect calculations.
The solution now is that when a system is scheduled it is told the current time, which could be incorrect if the engine hasn't started running yet. The EngineTimingHandler solves this by telling every system that is scheduled the real current time before it starts running.
There are still many improvements to be made to OGE's threading but it has been fairly easy to make the necessary changes so i think our current approach is working well. The main improvement i want to make soon is to get OGE to work out how many threads to create at the start semi automatically. It will take various hints and requirements (from config) and retrieve details about the current CPU (such as number of packages, cores and logical processors) to work out how many threads to create.
On another note, i think its possible for us to get Intel's Threading Building Blocks working in OGE (the scheduler/algorithms part) because it allows you to specify the number of threads that the TBB scheduler can use/create. It would allow us to allocate all the threads we need and then let TBB create the remaining number of threads. On future CPU's with more cores than work that we can allocate from the various systems, we can put more workload onto the tbb scheduler.
Friday, 18 July 2008
First driving lesson!
I just had my first driving lesson today which went really well. Learnt some of the basics and got to drive around a car park a bit. I am at least happy i haven't stalled the car...yet. Bit of a squeeze getting into the car as its smallish and I'm not. My instructor seems good as well, i think I'll be able to learn at a good rate. I'm hoping the rest of my lessons go as well as (or better than) today's.
Subscribe to:
Posts (Atom)