Pages: « 1 2 3 4 »
  Print  
Author Topic: I'm bookmarking this day  (Read 10180 times)
Offline (Female) IsmAvatar
Reply #15 Posted on: September 14, 2009, 02:24:49 AM

LateralGM Developer
LGM Developer
Location: Pennsylvania/USA
Joined: Apr 2008
Posts: 886

View Profile Email
The problems with threading is that if you wish to draw, they *must* be synchronized in order to avoid two problems:
1) frame lag - e.g. one second into the game, thread1.object is on frame 30 and draws such, while thread2.object is on frame 20 - a 10-frame difference)
2) tearing - a fractional-frame difference between the threads. If your frames are drawn 30 times a second, and there is a 0.900 frame lag between two threads, then you will get one thread's image drawn, and then the other's image drawn only 1/300th of a second before the screen gets flushed, causing the image to flash or not appear at all.

Thread issues are almost always solved with synchronization, which means waiting for one of the threads to catch up (or reach a certain synchronization point, such as the begin of the Draw phase - in which case you don't care if there's a 10-frame difference between the threads, as long as it's not a fractional difference like 10.001 or 0.900).
Logged
Offline (Male) Josh @ Dreamland
Reply #16 Posted on: September 14, 2009, 06:58:57 PM

Prince of all Goldfish
Developer
Location: Pittsburgh, PA, USA
Joined: Feb 2008
Posts: 2958

View Profile Email
And waiting for the threads to catch up would often be disadvantageous. It would be a pain in the ass to synchronize the threads in the first place, but then you have the fact that people might not want it done so.

That being the case, I think the best way is to let the user do it with my surface method (Possibly double buffering them, as well. I could implement a specific function set for doing so.)

In fact... I could probably fully implement an automatic system that worked off of that surface idea. The draw event of threaded instances would be called while the target is set to a specific buffer for thread two.
Logged
"That is the single most cryptic piece of code I have ever seen." -Master PobbleWobble
"I disapprove of what you say, but I will defend to the death your right to say it." -Evelyn Beatrice Hall, Friends of Voltaire
Offline (Male) RetroX
Reply #17 Posted on: September 14, 2009, 07:36:41 PM

Master of all things Linux
Contributor
Location: US
Joined: Apr 2008
Posts: 1055
MSN Messenger - classixretrox@gmail.com
View Profile Email
While I don't know how much hell this would be to program, you should have thread scripts like create_thread(), destroy_tread(), set_thread(), while the set_thread() would always set back to the original thread at the end of events so that drawing can be done.  That way, you can use multiple threads within objects.
Logged
My Box: Phenom II 3.4GHz X4 | ASUS ATI RadeonHD 5770, 1GB GDDR5 RAM | 1x4GB DDR3 SRAM | Arch Linux, x86_64 (Cube) / Windows 7 x64 (Blob)
Quote from: Fede-lasse
Why do all the pro-Microsoft people have troll avatars? :(
Offline (Male) Josh @ Dreamland
Reply #18 Posted on: September 14, 2009, 08:51:03 PM

Prince of all Goldfish
Developer
Location: Pittsburgh, PA, USA
Joined: Feb 2008
Posts: 2958

View Profile Email
Objects can potentially be moved to a separate thread by threading the instance handling code and treating it as a set of separate lists. Scripts can be threaded by turning them over to the kernel to run until they complete. It will be impossible to obtain a return value from a threaded script. (It would have to set a global variable when it is done.)

Functions would look like this:
script_start_thread(script)
thread_create()
instance_set_thread(inst,thread)
thread_destroy(thread)
instance_exists_thread(object,thread)
instance_exists_allthreads(object)

The last function probably raised some O_o. It exists for efficiency, so that instance_exists won't waste time iterating an unused feature. Because of this, threaded instances would be essentially nonexistent. At best, they would exist when the function is called on their own thread. This function would deliberately iterate all threads.
Logged
"That is the single most cryptic piece of code I have ever seen." -Master PobbleWobble
"I disapprove of what you say, but I will defend to the death your right to say it." -Evelyn Beatrice Hall, Friends of Voltaire
Offline (Female) IsmAvatar
Reply #19 Posted on: September 15, 2009, 12:14:53 AM

LateralGM Developer
LGM Developer
Location: Pennsylvania/USA
Joined: Apr 2008
Posts: 886

View Profile Email
LGM uses threads to load the Game Information and Global Game Settings frames without freezing LGM itself. Those frames are simply inaccessible until they are fully loaded, and if the user requests them and they are not fully loaded yet, LGM will wait for them to finish loading (essentially it will momentarily freeze). Similarly, LGM calls Enigma in a thread so that LGM isn't frozen while enigma is running. We actually use several threads for enigma. One for running enigma itself, one for retrieving output, and one for retrieving errors. Whenever output/error text is retrieved, it synchronizes with LGM and appends it to a textarea.

These are just a few examples of how threads are useful.
Logged
Offline (Unknown gender) Game_boy
Reply #20 Posted on: September 15, 2009, 10:33:55 AM
Member
Joined: Apr 2008
Posts: 228

View Profile
Yeah, threads are useful to run code in parallel even on single-core hardware, but the real use for the future is multi-core. AMD's launching a 12-core server chip in a few months for example, and even on the desktop it's clear the future contains more cores.
Logged
Offline (Male) RetroX
Reply #21 Posted on: September 15, 2009, 02:53:27 PM

Master of all things Linux
Contributor
Location: US
Joined: Apr 2008
Posts: 1055
MSN Messenger - classixretrox@gmail.com
View Profile Email
12 cores? :o

Anyways, I thought the max was 32?
Logged
My Box: Phenom II 3.4GHz X4 | ASUS ATI RadeonHD 5770, 1GB GDDR5 RAM | 1x4GB DDR3 SRAM | Arch Linux, x86_64 (Cube) / Windows 7 x64 (Blob)
Quote from: Fede-lasse
Why do all the pro-Microsoft people have troll avatars? :(
Offline (Female) IsmAvatar
Reply #22 Posted on: September 15, 2009, 05:59:07 PM

LateralGM Developer
LGM Developer
Location: Pennsylvania/USA
Joined: Apr 2008
Posts: 886

View Profile Email
And chances are you'll never use more than 4 cores.
Logged
Offline (Unknown gender) Game_boy
Reply #23 Posted on: September 16, 2009, 11:41:30 AM
Member
Joined: Apr 2008
Posts: 228

View Profile
And chances are you'll never use more than 4 cores.

That's why it's a server chip; they can usually scale to any number of threads.

But we'll never use more than 640k of memory...

--

@Retro

Where did you hear that? Cray uses tens of thousands of x86 cores in its more recent supercomputers.
Logged
Offline (Male) RetroX
Reply #24 Posted on: September 16, 2009, 02:19:54 PM

Master of all things Linux
Contributor
Location: US
Joined: Apr 2008
Posts: 1055
MSN Messenger - classixretrox@gmail.com
View Profile Email
Where did you hear that? Cray uses tens of thousands of x86 cores in its more recent supercomputers.
Well, I thought one individual processor was limited to 32 cores.  Or do you mean multiple processors?  I thought I read it somewhere, but I forgot. :/
Logged
My Box: Phenom II 3.4GHz X4 | ASUS ATI RadeonHD 5770, 1GB GDDR5 RAM | 1x4GB DDR3 SRAM | Arch Linux, x86_64 (Cube) / Windows 7 x64 (Blob)
Quote from: Fede-lasse
Why do all the pro-Microsoft people have troll avatars? :(
Offline (Unknown gender) Game_boy
Reply #25 Posted on: September 16, 2009, 02:38:10 PM
Member
Joined: Apr 2008
Posts: 228

View Profile
Well, I thought one individual processor was limited to 32 cores.  Or do you mean multiple processors?  I thought I read it somewhere, but I forgot. :/

I don't know; you could be right. Intel's Larrabee [GPU that runs x86 instructions] will have up to 48 cores, and they demoed a (non-x86, proof-of-concept only) chip with 80 cores a few years ago.

Logged
Offline (Male) RetroX
Reply #26 Posted on: September 16, 2009, 08:21:29 PM

Master of all things Linux
Contributor
Location: US
Joined: Apr 2008
Posts: 1055
MSN Messenger - classixretrox@gmail.com
View Profile Email
I don't know; you could be right. Intel's Larrabee [GPU that runs x86 instructions] will have up to 48 cores, and they demoed a (non-x86, proof-of-concept only) chip with 80 cores a few years ago.
I've never heard of a 48-core processor, and, to be honest, it sounds pretty pointless in my opinion unless you have 48 things you want to do at once.
Logged
My Box: Phenom II 3.4GHz X4 | ASUS ATI RadeonHD 5770, 1GB GDDR5 RAM | 1x4GB DDR3 SRAM | Arch Linux, x86_64 (Cube) / Windows 7 x64 (Blob)
Quote from: Fede-lasse
Why do all the pro-Microsoft people have troll avatars? :(
Offline (Unknown gender) luiscubal
Reply #27 Posted on: September 17, 2009, 08:33:31 AM
Member
Joined: Jun 2009
Posts: 452

View Profile Email
It seems pointless because programmers aren't used to threads yet.
Honestly, you DO have many things to do at once. Synchronization issues aside, think about this: A single game could have:

1. A thread to do the drawing
2. A thread to handle the input
3. A thread to perform AI
4. A thread to handle the audio
5. A thread to handle collisions
6. A thread to handle GC(since it was in its own thread, GC would no longer be bad for game speed)

So a single game could use 6 threads, so 6 cores would be used.
Now, onto more futuristic situations - you could have the OS use a different core, leading us to 7 cores being used.
Then, antiviruses(assuming you use Windows and not Linux) could use a different core, so they wouldn't affect the game speed. We're now reaching the 8 cores.

Of course, you could merge this things into a single core, but this way would allow multiple cores to be used.

And, yes, I know 8 cores != 48 cores, but then again, why have only *one* thread to handle drawing? And why just *one* to handle AI? Done efficiently, a really big number of cores/threads could mean a really good speed.
Logged
Offline (Male) Josh @ Dreamland
Reply #28 Posted on: September 17, 2009, 09:13:31 AM

Prince of all Goldfish
Developer
Location: Pittsburgh, PA, USA
Joined: Feb 2008
Posts: 2958

View Profile Email
1. A thread to do the drawing
  Why bother
2. A thread to handle the input
  Mark does that, you end up getting the mouse in eight different positions during a lagtastic step
3. A thread to perform AI
  Can't think of an instance that'd be useful, but that wouldn't be part of ENIGMA
4. A thread to handle the audio
  That's necessary, everyone does that
5. A thread to handle collisions
  That would be awful. Unless you had them split up across multiple cores, there'd be more harm than good to come from doing that. (Taking sync on all this into account)
6. A thread to handle GC(since it was in its own thread, GC would no longer be bad for game speed)
  GC? Garbage collection? This is C++. The only garbage collection I do is leftovers from instance_destroy(), and that causes next to no lag. But yeah, it wouldn't hurt, and that's probably the best use for threads here.
Logged
"That is the single most cryptic piece of code I have ever seen." -Master PobbleWobble
"I disapprove of what you say, but I will defend to the death your right to say it." -Evelyn Beatrice Hall, Friends of Voltaire
Offline (Unknown gender) Game_boy
Reply #29 Posted on: September 17, 2009, 11:24:43 AM
Member
Joined: Apr 2008
Posts: 228

View Profile
I don't know; you could be right. Intel's Larrabee [GPU that runs x86 instructions] will have up to 48 cores, and they demoed a (non-x86, proof-of-concept only) chip with 80 cores a few years ago.
I've never heard of a 48-core processor, and, to be honest, it sounds pretty pointless in my opinion unless you have 48 things you want to do at once.

It's a GPU. That means it runs graphics. Rendering 3D graphics is highly parallelisable - though shaders aren't enirely like cores, modern graphics cards have up to 1600 of them per chip. So Larrabee will use all 48 cores.
Logged
Pages: « 1 2 3 4 »
  Print