Mutlithreaded rendering.... (RFC)

Started by
26 comments, last by Harvester 24 years, 1 month ago
I agree that multithreading with a single processor won''t speed your process at all for CPU intensive tasks.
However if some task are most of the time waiting (like I/O), it''s very very interesting to use cause it saves a lot of time.
About your idea of creating a render thread and a Game Logic thread, I''m thinking about it for some time now, but I''ve not try it.

It''ll simplify your code (not at all if you don''t know thread, semaphors ans mutex), but I doubt it''ll fasten your app, maybe I''m wrong...

Another problem with that is that on different Pc the game logic will not work as often, so your IA can be very affected (varying from stupid to highly intelligent).
You might have to had a time counter to resolve that problem.



-* Sounds, music and story makes the difference between good and great games *-
-* So many things to do, so little time to spend. *-
Advertisement
Just to be clear:
quote:
However, I believe the original idea in the parallel mode point was that the 486
was pipelined, which is true. The second pipeline only handled about a third of
the instruction set, and only ran the instructions it could handle about 1 in a 3
times, but it was there. The 586 was simply pipelined much much better.

Multipipelined arhitecture becomes only with Pentium class processors. 486 have only one pipeline, Pentium - two pipelines and PII&PIII - three pipelines



FlyFire/CodeX
http://codexorg.webjump.com

In the concept of POSIX threads under Linux, still the threads are child processes as if you had used fork(). However, each child process in the case of threads has access to the global data-space of its parent process (thread).

------------------------------------------
Text copied from Leroy's document

Linuxthreads - POSIX 1003.1c kernel threads for Linux

Copyright 1996, 1997 Xavier Leroy ~ (don't flame me on its date... its not out-of-date )~(Xavier.Leroy@inria.fr)


DESCRIPTION:

This is release 0.7 (late beta) of LinuxThreads, a BiCapitalized
implementation of the Posix 1003.1c "pthread" interface for Linux.

LinuxThreads provides kernel-level threads: each thread is a separate
Unix process, sharing its address space with the other threads through
the new system call clone(). Scheduling between threads is handled by
the kernel scheduler, just like scheduling between Unix processes.

--------------------------------------------------------
(http://pauillac.inria.fr/~xleroy/linuxthreads/README)
ps: Xavier Leroy is also the author of the man pages on the POSIX threads.


If its of much concearn if the parallel processing was tech. avaliable on the 80486 or the Pentium, i could check in some books... it will defenetly have info in there about it.

If we're talking about a Hello World in ASM, i could code it too . However, i could never write a large application in ASM (i can't understand how they made those demos... Futurekids RULED!!!! ~for those who remember ~)

c 'ya around

Edited by - Harvester on 3/3/00 4:55:08 PM
... LEMMINGS ... LEMMINGS ... LEMMINGS ... LEM..... SpLaSh!...Could this be what we stand like before the mighty One?Are we LeMmIngS or WhAt!? ;)
quote:Original post by FlyFire
Multipipelined arhitecture becomes only with Pentium class processors. 486 have only one pipeline, Pentium - two pipelines and PII&PIII - three pipelines

Bzzt. Still wrong! The 486 had an additional pipeline that handled instructions such as 16 bit multiplies and additions. What you''re probably thinking of is that the Pentium was the first (x86) 2-way superscalar architecture. This is different than multiple pipelines. Pipelined means multiple instructions can be processed in the same cycle. Superscalar means that multiple instructions can be dispatched in the same cycle. If you still want to argue that, then why do AGI''s apply to the 486? For those of you who don''t know what an AGI is, it''s short for Address Generation Interlock, and they occured when one pipeline needed an address that was being computed by another pipeline.

Harvester: I''ll give you that Linux handles threads as processes; however, you''re original claim was that UNIX threads are handled as processes. I know for a fact that this isn''t the case for Solaris 7 machines.
Unless you have multiple processors and are running a variant of NT, your multithreaded programs won''t run _any_faster than single threaded ones. Even when waiting for I/O.

You can''t run two threads at once on a single processor - you can only task switch (in doing so, the processes will run slower as data specific to the processes is switched in and out of the registers).

Paul Groves.
http://home.clara.net/paulyg
OpenGL for Beginners
Paul Grovespauls opengl page
You must use threads for high latency code, such as code waiting for I/O...
It speeds up the process, cause while waiting for I/O, another part of your code is still working.
Of course, if you only load the level once in memory, you don''t need any thread to do that.
Task switching is pretty fast on todays computers, so (apart having many many threads) you won''t be slown by switching between threads.

-* Sounds, music and story makes the difference between good and great games *-
-* So many things to do, so little time to spend. *-
quote:Original post by Pauly

Unless you have multiple processors and are running a variant of NT, your multithreaded programs won''t run _any_faster than single threaded ones. Even when waiting for I/O.

You can''t run two threads at once on a single processor - you can only task switch (in doing so, the processes will run slower as data specific to the processes is switched in and out of the registers).

Paul Groves.
http://home.clara.net/paulyg
OpenGL for Beginners


There you go

In fairness, multithreading makes applications more interactive . The total time spent running the two threads will be no different - we just have to make that clear.

Frontpage for example locks up while FTPing your website to the ISP server. WTF? How hard could it have been to make that function multithreaded?

Scowl.

Paul Groves.
http://home.clara.net/paulyg
OpenGL for Beginners
Paul Grovespauls opengl page

This topic is closed to new replies.

Advertisement