Sign in to follow this  
RhoneRanger

Multi Threaded apps

Recommended Posts

Hey guys! I have a question about buffer locking in seperate threads. Are there any worries, implications etc? What I want to do is take a vertex/index buffer from one thread, lock it, fill it's contents and unlock it in a different thread.

Share this post


Link to post
Share on other sites
This can be a little dangerous - Direct3D doesn't really like being accessed from multiple/different threads [smile]

You'll be able to get it working if you specify D3DCREATE_MULTITHREADED in your IDirect3D9::CreateDevice() call. In doing so D3D will make sure its thread-safe, but performance can suffer as a consequence.

You might well want to change your program so that all of the D3D related code stays in a single thread, but maybe farm out the logic/processing to worker threads. When these threads finish working the original "master" thread copies the data into a VB/IB/wherever.

hth
Jack

Share this post


Link to post
Share on other sites
Thanks for the reply. I have not coded any d3d stuff outside the main thread, instead I pass the data into the main thread and lock the BUffers there.

I was thinking IF the buffers were thread safe, that it would be a lot easier just to pass the buffer itself in a function in a seperate thread, something like this....


//////////////////////////////////////////////////////////////////

void DoStuff(VertexBuffer * VB)
{
VB->Lock();
CopyData;
VB->Unlock();
}
//////////////////////////////////////////////////////////////////

but I was not sure if this would be thread safe or not.

Share this post


Link to post
Share on other sites
Quote:
Original post by RhoneRanger
but I was not sure if this would be thread safe or not.

I think that code could work, but it probably has a large number of possibilities for exploding [smile]

For example, if you try to render from that VB while it's locked (a possibility if you're not careful with your general MP code) the draw call will fail on you. Similarly, if you try to acquire a second lock on the resource it'll fail as it's currently being held by the other thread.

If you designed your system so that it made sure that any extra lock/draw calls are blocked until the worker thread returns, it'll probably be safe - but at that point you'll possibly start to lose the benefit of being multithreaded...

Multithreading in multimedia/general is going to be a big thing in the next few years, but it's questionable whether the core graphics rendering will really benefit much (as I see it) due to the inherantly non-parallel way of issuing rendering instructions to the hardware. Your software (the logic/processing) can be MP and the hardware implementation on the GPU is likely to be massively parallel - but theres still that non-parallel interconnect over the AGP/PCIE bus ...

hth
Jack

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this