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.
Monday, 25 August 2008
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.
Subscribe to:
Posts (Atom)