Software renderer with multithreading

With multiple processors or Hyper-Threading support it should definitely give a nice performance boost!

Is there a reason why you want to do rendering in a separate thread? Are you willing to take the hit for the context switch and/or synchronization constructs? The reality is that your average user isn''t going to have a SMP machine or even a box that can do hyperthreading right now. If that isn''t the case, then threads will just complicate and slow down the game, IMHO.

Actually, there's a very good reason to do the calculations on another processor.

If it gets set up to do it with two processors, then you get the advantages of a GPU (it doesn't take up "main CPU" resources) and the advantages of doing this stuff in CPU (main memory reads are much faster than video memory reads).

I'm a firm believer that PC architecture could be reworked to remove the barrier between video and system RAM (Give the video direct access to system RAM) so that many more things become possible (to do without needlessly sacrificing performance). Like Heiarchical occlusion maps, geometry readbacks for collision detection, frame buffer manipulation, etc.

If you really COULD do the work of a GeForce FX or a Radeon 9800 (or whatever the number is, I forget) with the same framerates using only a second CPU and direct frame writes, this would be the ideal solution.

[edit]: I should add, however, that on single processor machines, the performance would be greatly less. But I'm assuming that, as a software renderer, you're realistically aiming for multiprocessor machines.

[edited by - Drilian on September 8, 2003 4:41:55 PM]

quote:

---

Original post by FranG
Is there a reason why you want to do rendering in a separate thread? Are you willing to take the hit for the context switch and/or synchronization constructs? The reality is that your average user isn''t going to have a SMP machine or even a box that can do hyperthreading right now. If that isn''t the case, then threads will just complicate and slow down the game, IMHO.

---

Context switching can be kept to a minimum. If you have two processors (or Hyper-Threading), and you split work over two threads there shouldn''t be any extra overhead. But it would indeed be wise to only activate it when multiple processors have been detected. Anyway as long as there are not dozens of threads you shouldn''t worry much about context switching as far as I know...

We are goaling for single-processor machines actually .But i just can''t end up with the fact that as long as something is rendered nothing else can be done so we decided to splitt the time and rendering to be done in another thread.Don''t know if this is right decision but it''s definetely better than sitting and doing nothing while the system renders geometry.

http://mihail121.tripod.com

> Don''t know if this is right decision but it''s definetely
> better than sitting and doing nothing while the system
> renders geometry.

Uhm, what is sitting and doing nothing while the single processor renders geometry?

---
http://www.lidgren.net/code/game/

unless I''m wrong, with a single processor withous hyperthreading, your frames will take the same time to process with or without multithreading, so what''s the point?

in a single threaded application, when the cpu renders the geometry, it does _only_ that, ok, and when the renderer is in another thread, the application doesn''t only render, but do other stuff, ok as well, the thing is it will take more time to render...
multi threading in a network game seems to me to have a point, you can launch a local server in one thread (or even one process), the game in another, and make the game connect to the local server. but I don''t see the point of having the sr in a separate thread... it would be good if the cpu did nothing while rendering, but in a software renderer, it''s not the case...

"but it''s definetely better than sitting and doing nothing while the system renders geometry"

your CPU doesn''t sit down and do nothing, it actually renders that geometry... I don''t really understand your point of view here...

It just seems pretty unnatural to me but i guess it''s the only way.It is even better cause there i will know in every moment when the system has been done rendering.

http://mihail121.tripod.com

quote:

---

Original post by Anonymous Poster
I''ve tried the multithreaded software rendering approach on a P4HT-3Ghz. I tried it on a per-polygon base, on a per object base, on a per-object geometry-only base and on an interleaved geometry/rasterizing-base...and it wasn''t worth anything in any of them (at least not on a HT cpu...a "real" dual-cpu setup may behave different).
So i''m back to "normal" now.

---

Thanks for testing that.

BTW, are you sure you were not memory bandwidth limited? Hyper-Threading only helps with arithmetically intensive work. So flat-shaded polygons normally wouldn''t benefit from it.

Could you explain how to support Hyper-Threading? I''d like to try it for my DirectX 9 pixel shader emulator...

just support multithreading, nick, and done..

well, about that..

ht of course has different resulting performance gains and non-gains than a real dual-cpu. but the interface is the same..

---

If that''s not the help you''re after then you''re going to have to explain the problem better than what you have. - joanusdmentia

davepermen.net

quote:

---

Original post by davepermen
just support multithreading, nick, and done..

---

I know, but what I actually wanted to as is, how to do it efficiently and specifically for the purpose of software rendering? There are several strategies to use multi-threading, but what''s the best approach for Hyper-Threading?

But first I got to buy me one of those Pentium 4C''s :-D

In fact, you may gain performance with multiple threads on a single cpu, since one thread may block on an IO read(maybe paging memory in from the HD), while the other thread can do useful work.

quote:

---

Original post by C0D1F1ED

quote:

---

Original post by davepermen
just support multithreading, nick, and done..

---

I know, but what I actually wanted to as is, how to do it efficiently and specifically for the purpose of software rendering? There are several strategies to use multi-threading, but what''s the best approach for Hyper-Threading?

But first I got to buy me one of those Pentium 4C''s :-D

---

i know.. well.. all i can say is they DON''T use several cpu-sections at the same time, means you cannot get more than 100% cpu usage (no mmx + sse at the same time, one used by each thread.. possibly in a future version..). all it does is while one accesses memory, it swaps to the other processor..

so when you only do a lot of math in sse say with your ps2.0 implementation, but not much memory accesses (no textures for example), you cannot gain much performance, if at all. but if you have tons of tex-accesses and sse math interleaved, then you could render say two scanlines in parallel, one in each thread.

but possibly, in the end, you don''t even want to do that, but only schedule your rendering into one thread. why? because then it really acts as a gpu.. i had winrar running to compress 1.2giga of data, and it ran at exactly 50% cpu usage :D means simply exactly on one of both cpu''s. so i could work just like i did before, with NO performance drop.. and i think this is even bether, because it means that you could real games with your renderer rendering in parallel.

then again, making it scalable to support multiple threads, possibly even multiple pc''s over gigabit ethernet, to build up renderfarms, would rock.. i could set up a gigabit ethernet between two 2.8gig HT p4 with fsb800 and dual ddr400 512mb ram.. i hope to get them together to do some nice raytracing:D

i could connect even more, but then i would need a gigabit switch *ouch my money hurts* :D

---

If that''s not the help you''re after then you''re going to have to explain the problem better than what you have. - joanusdmentia

davepermen.net