Not logged in, Join Here! or Log In Below:  
 
News Articles Search    
 

 Home / General Programming / Threading a 3d engine Account Manager
 
Archive Notice: This thread is old and no longer active. It is here for reference purposes. This thread was created on an older version of the flipcode forums, before the site closed in 2005. Please keep that in mind as you view this thread, as many of the topics and opinions may be outdated.
 
Sandy McArthur

March 13, 1999, 10:49 AM

I recently got a 2nd processor for my machine and I was wondering how could/would I make the my 3d engine take advantage
of both processors?
--
Sandy McArthur
sandymacjr@writeme.com
ICQ UIN: 625201
"So many idiots, so few comets"

 
Sandy McArthur

March 13, 1999, 10:51 AM

Typo in the URL it should be http://thecity.eu.org

 
Jeroen

March 14, 1999, 02:35 PM



Sandy McArthur wrote:
>>I recently got a 2nd processor for my machine and I was wondering how could/would I make
>>the my 3d engine take advantage of both processors?

As fas as I know (Although admittedly I'm no expert on multi-threading/tasking), it is the
OS which assigns the tasks to different proc's. So if the OS you're using supports multiple
CPU's, your programs simply run faster. I don't think it's possible to assign for example
geometric calculations to one and rasterizing to the other processor.

Jeroen

 
Rock

March 15, 1999, 09:20 AM

>>As fas as I know (Although admittedly I'm no expert on multi-threading/tasking), it is the
>>OS which assigns the tasks to different proc's. So if the OS you're using supports multiple
>>CPU's, your programs simply run faster. I don't think it's possible to assign for example
>>geometric calculations to one and rasterizing to the other processor.

I'm not an expert in this area either, but I believe that only NT can utilize multiple processors (for Windows platforms), and I'm pretty sure you need to write your engine using multiple threads. NT then tries to run certain threads on certain processors, so trying to minimize data sharing/locking should help the program run more efficiently (but I guess that applies to any multi-threading programs).

Rock

 
Rock

March 15, 1999, 09:20 AM

>>As fas as I know (Although admittedly I'm no expert on multi-threading/tasking), it is the
>>OS which assigns the tasks to different proc's. So if the OS you're using supports multiple
>>CPU's, your programs simply run faster. I don't think it's possible to assign for example
>>geometric calculations to one and rasterizing to the other processor.

I'm not an expert in this area either, but I believe that only NT can utilize multiple processors (for Windows platforms), and I'm pretty sure you need to write your engine using multiple threads. NT then tries to run certain threads on certain processors, so trying to minimize data sharing/locking should help the program run more efficiently (but I guess that applies to any multi-threading programs).

Rock

 
Sandy McArthur

March 15, 1999, 12:40 PM

Rock wrote:
>>I'm not an expert in this area either, but I believe that only NT can utilize multiple
>>processors (for Windows platforms),
True. NT is the only Microsoft operating that supports multiple processors.
I run Stampede Linux, which I don't reccomend for the linux novise but kicks ass in general.
Sandy McArthur
http://TheCity.eu.org

 
Sandy McArthur

March 15, 1999, 01:01 PM

Jeroen wrote:
>>I don't think it's possible to assign for example geometric calculations to one and rasterizing to the other processor.
You can't AFAIK but 2 intense threads will be balanced on seperate processors to take better advantage of the processor cache.

Here is what ideas I've had since the 1st post. Please rip these apart if you know a flaw in them. This is my 1st experience with treads.

1) have 2 "worker" threads that get "told" about objects that need stuff to be done. This should let you run with out sharing/locking because a thread only works on it's given tasks.
2) have 2 threads that just run but check a flag on each object to see if it is being worked on. This wouldn't need a "controler" thread like the 1st idea and wouldn't need pointers passed arround as much but I think it would be possible for the threads to check the object at the same instace and collide on the same object.

Any other ideas out there?

Sandy McArthur
http://thecity.eu.org

 
David Smith

March 23, 1999, 07:09 AM

Yep, you need alteast 2 threads in your program, if you have only one then it can only execute on 1 CPU. But don't get caught up on the idea 2CPUs = 2 threads. Each thread only executes for a very small time, one moment your rendering thread is on CPU 1 and your input thread is on CPU 0, a hundredth of a second later they have switched. And the threads in your program are never the only threads executing in the system.
The goal is to break the program into as many tasks as possible that can be performed in parallel without creating so many that the overhead in swapping threads negates the gaines.
Rendering and receiving user input could be preformed in parallel so could be put in separate threads. But Rendering and transforming objects in a scene may not be parallelizable.
If your system had 3 CPUs and your program has only 2 tasks that could be performed in parallel you would gain nothing by creating 3 threads, sure they would be executing on all 3 processors but always atleast 1 would be waiting for the others.
>
>> This wouldn't need a "controler" thread like the 1st idea and wouldn't need pointers passed >> arround as much but I think it would be possible for the threads to check the object at the >> same instace and collide on the same object.
>>
>
If you no nothing of thread programming you have just made a very keen observation. What you need to research is thread synchronization, lookup MUTEXs and SEMAPHORES. There the basics of thread programming. A mutex can only be owned by 1 thread at a time, so you create a mutex for your shared variable and before any thread tries to access it it has to request access to the mutex, the thread gets suspended until the mutex is made availible for that thread. I have only done thread programming in windows but am sure that these aspects are the same everywhere.
>
>
Dave.

 
Harmless

April 06, 1999, 03:44 AM

Rock wrote:
>>>>As fas as I know (Although admittedly I'm no expert on multi-threading/tasking), it is the
>>>>OS which assigns the tasks to different proc's. So if the OS you're using supports multiple
>>>>CPU's, your programs simply run faster. I don't think it's possible to assign for example
>>>>geometric calculations to one and rasterizing to the other processor.

>>I'm not an expert in this area either, but I believe that only NT can utilize multiple processors (for Windows platforms), and I'm pretty sure you need to write your engine using multiple threads. NT then tries to run certain threads on certain processors, so trying to minimize data sharing/locking should help the program run more efficiently (but I guess that applies to any multi-threading programs).

All you can do is create a thread you cannot assign it to an individual processor. In practice however the operating system will load balance as close to evenly as possible. (It generally does a better job than you would do second guessing it by hand as long as you have at least 3 threads to balance between) In general if you are looking for good areas to multithread in a 3d engine I have found the following areas to be useful (even on single processor machines):

Run physics and polygon creation in one thread, while running the actual rasterization of the polygons in another thread. This is a useful model under direct3d especially when using DrawPrimitive, because a second call to DrawPrimitive while the first one is running could otherwise block execution of your rasterization/physics thread, possibly costing you over half your frame-rate on certain card/scene combinations.

Streaming textures from disk is sometimes best done asyncronously as well. If you are running a single thread and go to read a texture from disk to move up to a higher mipmap level you can lose a frame or more (hell, if the drive stopped spinning you could lose a whole second or more) waiting for the next larger mipmap to get loaded from disk. This isnt an issue on small maps or for small worlds but once your world starts to get large enough to need to stream parts on and off disk it becomes more and more of a performance issue. Loading everything always results in huge performance problems like can strike most 3d games these days when they swap out textures to disk that haven't been accessed and use a single thread model for retrieving them. With asyncronous texture loading you can still use the lower mipmap level as a standin until the other texture is available raising your overall framerate.

Moving to a fully multithreaded model can allow you to switch from the 'big loop' network model to multiple blocking streams. This isn't an efficiency win (usually its a small loss), but it DOES greatly save programmer time, especially if you start allowing asyncronous file transfers, voice transmission, etc.

I move my control consoles off to seperate threads (i run my 'console' from a telnet session) this allows my console to act as a debugger stopping and starting other threads, installing blocks and inspecting variables.
I do it this way so that I can interact with the console completely independantly of the rasterization portion of the engine, from a completely different machine if need be.

-Harmless

 
This thread contains 9 messages.
 
 
Hosting by Solid Eight Studios, maker of PhotoTangler Collage Maker.