[Solved] DX11 (SlimDX) - Multithreaded rendering setShaderValue problem

In D3D11 you set shader resources using the device context (DeviceContext.PixelShader.SetShaderResource in SlimDX). So if you're using a deferred context, the setting of the resource is deferred and the state change could happen in the right order.

What is "shader.setResource" doing?

"shader.setResource" is doing this:

effectVariable.AsResource().SetResource((ShaderResourceView)value);

I have an effect file (.fx) wich contains some global values, for example the view matrix. Then I set a value by its name (vMatrix = myMatrix). I do not know (or I want not to pay attention), which shader uses this value. Is there something deferred I can use for the whole effect? Or may I set the value for all shaders? Or can I investigate, which shaders need the value? Or is the way of using effects in Dx11 the wrong one and I have to separate the whole shaders in my C# code?

And if I have to set the values for each shader separately, then the method "SetShaderResource()" needs a slot number. What is that? Have I to count the number of each value, or something like this?

Hmmm...I'm not sure how Effects11 handles deferred contexts. I would think that this would be a case they handle, but I'd have to check through the docs and maybe the source code.

EDIT: Looking through the docs, it looks like an Effect just keeps all of its state internally and then applies it to a particular device context when you call Apply().

Quote:

Original post by Pyrogame And if I have to set the values for each shader separately, then the method "SetShaderResource()" needs a slot number. What is that? Have I to count the number of each value, or something like this?

Textures, buffers, and samplers and mapped to specific registers in a particular shader. The index of that register specifies what slot you would need to pass to SetShaderResource. Typically when you don't use the effects framework you manually assign the register, so that you know which slot you have to pass. If you do use the effects framework, it handles the mapping register mapping for you so that you don't have to worry about it.

Quote:

Original post by MJP EDIT: Looking through the docs, it looks like an Effect just keeps all of its state internally and then applies it to a particular device context when you call Apply().

Yes, but this is the core problem. I do not known, how I can set the state of an Effect in a deferred context. The problem is:

1) Set Effect A variable p to 1,0,0.
2) Effect.Apply(deferredContext)
3) render(deferredContext)
4) Set Effect A variable p to 0,1,0.
5) Effect.Apply(deferredContext)
6) render(deferredContext)
7) deferredContext.getCommandList().execute(immediateContext)

On step 7, the effects variable p is set to 0,1,0. The command list calls then:
1) Effect.Apply(immediateContext)
2) render(deferredContext)
3) Effect.Apply(immediateContext)
4) render(deferredContext)

It does not set the effect variable p to 1,0,0 before executing the first apply, because this assignment to the effect is not stored on the deferred context.

I think, if we couldn't get this working, that this may be a big design isue on the DX11-Framework. But I can't imagine, that the DX-DevTeam had forget such big thing. There must be something, I can do. The last thing I want to do, is, to create my own command list (list of delegates), and then call to execute it in the same way I'm calling the deferredContext command list execution.

Quote:

Original post by MJP Textures, buffers, and samplers and mapped to specific registers in a particular shader. The index of that register specifies what slot you would need to pass to SetShaderResource. Typically when you don't use the effects framework you manually assign the register, so that you know which slot you have to pass. If you do use the effects framework, it handles the mapping register mapping for you so that you don't have to worry about it.

Thank you for that info. But how I can distribute the registers on my resources? Every resource needs a separate register? Are there some types of registers or are they unified?... But you will understand me, if I say: no no no, I want to use the effect framework, which should be the solution for exactly this problem of managing registers etc. :)

I think you need a copy of the Effect for each thread/deferred context. AIUI from the documentation you should create the Effect and then use its Clone method to create a copy for each deferred context that you have (which should be one per thread).

That way they'll all share the same actual shaders but will have unique register state. Then when you call Apply on the effect you pass in the deferred context. So you end up with something like:

[Thread1]
1) Set ClonedEffect A variable p to 1,0,0.
2) ClonedEffect.Apply(deferredContext)
3) render(deferredContext)
4) Set ClonedEffect A variable p to 0,1,0.
5) ClonedEffect.Apply(deferredContext)
6) render(deferredContext)
7) deferredContext.getCommandList()

[Thread2]
1) OrigEffect.Apply(immediateContext)
2) render(immediateContext)
3) OrigEffect.Apply(immediateContext)
4) render(immediateContext)

Somewhere in that lot you need the immediateContext to execute the command list from the deferredContext (preferrably in Thread2). What you had with

deferredContext.getCommandList().execute(immediateContext)

and

3) Effect.Apply(immediateContext)
4) render(deferredContext)

doesn't make much sense unless you've got some method of stopping the execution from stomping all over the immediateContexts state - I mean what would happen if thread2 did step 1, then at that point thread2 did your step 7 execute and made state changes to the immediateContext that then affect thread2's step 2...

You'd probably be better of with:

[Thread1]
... Generate command list
send to thread3

[Thread2]
... Generate command list
send to thread3

[Thread3]
immediateContext.Execute(first_recieved_list)
immediateContext.Execute(next_recieved_list)

Thats my understanding anyway - I've not got to that point yet so I may be wrong! :)

[Edited by - hornet1990 on February 9, 2010 2:02:17 PM]

Indeed I believe that what hornet suggests is the intended way to handle effects across different device contexts. This way you're not modifying state in one thread that's shared in another.

Quote:

Original post by Pyrogame Thank you for that info. But how I can distribute the registers on my resources? Every resource needs a separate register? Are there some types of registers or are they unified?... But you will understand me, if I say: no no no, I want to use the effect framework, which should be the solution for exactly this problem of managing registers etc. :)

You can find the low-level documentations for these things here, including a list of the registers I'm talking about. Unfortunately it's a little patchy and you have to look through a few sections to find out what the registers are for, so I'll give you a quick list:

r# - temporary registers - used for storing operands and results of math ops
x# - indexable temp. registers - same as above, except you can index into them using the value of an r# register
v# - vertex inputs - you map your vertex input streams to these registers
t# - resource registers - you map your texture resources to these registers
s# - sampler registers - you map your sampler states to these registers, and then specify one of these when you want to sample a texture resource
cb# - constant buffer registers - you map your constant buffers to these
icb# - immediate constant buffer register - you assign "hard-coded" values to this constant buffer, instead of mapping a buffer in your app

For any single shader you would just need to make sure than any particular register is only mapped once. So if you had two textures, you would probably just assign them to t0 and t1. A different shader could then use t0 and t1 afterwards.

I wasn't suggesting that you shouldn't use the effect framework...for anything non-trivial you'll definitely want to have a wrapper over the low-level stuff so that you don't have to explicitly manage registers and slot numbers. I was just trying to help you understand what's going on under the hood, because it's useful knowledge for when you're debugging problems like the one you're having.

Thank you for your comments :) I've found the problem.

@hornet1990:
Yes, I do it like you posted it on your last passage, except that I do not send the command lists to a 3rd thread. I render simultaneously on every cpu-core, and on the end I create the command list from what I rendered (on the same thread), and render this on the real device using the immediate context. This way, all threads can render parallel, but on the end all have to use the hardware, so only one thread can execute at time. I always have to wait, until all rendering threads are ready, so this might be the right thing I do (I think so ^^).

@MJP
You are the best! I had called the apply method, but only once per pass on the begining. But I have to call this after a change to the shader state ofcourse (like setting the texture) and before the render() method.

Problem solved. Thank you very much for your help, both of you! Sorry for bother you with this "bug" of my own.