• Advertisement
Sign in to follow this  

what good are cores?

This topic is 693 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

can anyone give me an example of a real world game that uses multiple cores for mission critical code, where multi-threading was obviously the best way to do it?

 

multi-threading just for multi-threading's sake doesn't count, and neither does using additional threads for non-mission critical code like smoke particle systems.

 

i'm talking about true parallel processing of the basic tasks of render, input, and update.

 

ideally, each basic task would have one or more processors dedicated to it (how about one processor per entity? <g>) , update would update some drawing data for render from time to time and set a flag that it had posted new data for exchange (to be passed to render). same idea with input passing info to update, or perhaps handling the input directly. render and audio would just hum along, checking for new data to display or play.

 

but are we at that point yet where it really would be better from a performance standpoint?   forget about the additional implementation costs of multi-threading for a moment - which are non-trivial.

 

more importantly, do we even need the gains it could bring? right now the typical bottleneck is one processor feeding the GPU (and memory access of course).  we'd still have one core feeding the gpu - perhaps with data from multiple cores.

 

so, what good are cores (at this point in time)? can they do anything truly useful? or just more BS bling bling chrome on high end machines?

 

parallelism only lends itself to processes that are inherently parallel in nature. it seems that very little of the basic tasks in a game are parallel in nature.    update in parallel and dealing with collisions wouldn't be easy. in render, only one CPU can talk to the GPU at a time, so its not really parallel either. aspects of scene composition maybe, but it seems that in both render and movement you must at some point merge back to a single chokepoint thread, to marshal all your parallel results together and apply them.

.

 

Share this post


Link to post
Share on other sites
Advertisement

 

Hodgman: Moreover, in D3D11, you can perform resource management tasks on any thread, and create multiple command buffers, to record draw/state commands on many threads (before a single "main" thread submits those command buffers to the GPU). D3D12/Vulkan head further in this direction.

Can you give a link so I can read more? I would love to be able to manage texture resources in a separate thread.....

Share this post


Link to post
Share on other sites

Hodgman: Moreover, in D3D11, you can perform resource management tasks on any thread, and create multiple command buffers, to record draw/state commands on many threads (before a single "main" thread submits those command buffers to the GPU). D3D12/Vulkan head further in this direction.

Can you give a link so I can read more? I would love to be able to manage texture resources in a separate thread.....

The ID3D11Device interface is thread-safe -- it's got all the routines for creating/destroying resources. If you need Map or UpdateSubresource, you can use them on a secondary ID3D11DeviceContext created from ID3D11Device::CreateDeferredContext and then have the main thread execute the command buffer generated from that context. Alternatively, you can call Map on the main context, pass the pointer to a secondary thread, have it write data into the resource, then have the main thread call Unmap.

Share this post


Link to post
Share on other sites
Honestly, the fact you think this means you are a good 15 years behind the curve right now - threads have been a pretty big deal for some time and far from 'bling bling'.

Threads and cores are two different things imho; having hundreds of threads doesn't imply you need many cores.

 

I believe it's actually pretty hard to usefully use more than 1-2 cores full time.

Share this post


Link to post
Share on other sites

Hodgman:

I'm currently creating the texture and map(ing) it in the main thread, then executing another thread that has a pointer to the mapped data and manipulating it there. Then when the thread tells my program it is done, the main thread unmaps the texture and I can use it in my render.

 

This method works fine, but there is still a slight dip in fps. If I could do everything in another thread and then tell the main thread when it can use the texture, then there should be no noticeable dip in fps (theoretically). I've spent the last two hours (nearly) looking up how to do this. The methods I came up with all failed except one, and that one is ugly and produces even more of a dip in fps than my original one. It also causes my screen to blink during the update!

 

I would love to see an example of how it is done. Even pseudo-code would be great.

Share this post


Link to post
Share on other sites

 

Honestly, the fact you think this means you are a good 15 years behind the curve right now - threads have been a pretty big deal for some time and far from 'bling bling'.

Threads and cores are two different things imho; having hundreds of threads doesn't imply you need many cores.

 

I believe it's actually pretty hard to usefully use more than 1-2 cores full time.

 

 

I have observed this situation quite often in a preprocessing tool using OpenMP:

 

Do a very simple thing like building a mip-map level in prallel: Speed up is 1.5... very disapointing

Do a complex thing like ray tracing: Speed up is 4... yep - that's the number of cores

 

My conclusion is that memory bandwidth limits hurt the mip-map generation.

I assume it would be faster to do mips and tracing at the same time, so memory limit is hidden behind tracing calculations.

 

Are there any known approaches where a job system tries to do this automatically with some info like job.m_bandWidthCost?

I've never heared of something like that.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement