D3D11 effect and Deferred context

Started by
3 comments, last by haust 12 years ago
Hello,

while learning Direct 3D 11 API It's seem to me that deferred context with multithreading are mandatory in order improve render perfomance (on systems with actual multithread support that is).

So after reading the documentation (create a deferred context, use it "as" the immediate one, finish it and get the result with a command list and then use the command list with the immediate context) I thought it would be easy to implement without threading involved in my basic framework as a first step.

(here comes the) But it seems that I've done something wrong since nothing is rendered. After more reads I've noticed that states in deferred context are not inherited from the immediate one (ok fine makes sense). However i'm using D3D11 effect framework and I don't know if how do it support deferred context.
I've seen, in the source code, that the framework uses a dirty-tag system to track modifcation and optimize cbuffer/resource/etxc updates. How does it suppose to work with a context that is always clean at the beginning on a render pass (with ClearState or FinishCommandList(TRUE, &pCommandList)) ??

I know that I WILL have to implement a specific shader framework but am I doing something wrong this the provided D3D11 effect framework ?? Did I misunderstood some point ??

Thank for any hint smile.png

haust.
Advertisement
You could modify the effect framework to overwrite all state of the context when you determine that it is a deferred context. I don't remember if this behavior is already implemented in the official sources, though, but the modification itself would be relatively easy.

Niko Suni

Effects framework in DX11 is not thread safe, aka there are situations where you cannot use the same effect concurrently in multiple threads. These situations include updating constant buffers for example, nothing good happens when you try to update the same buffer at the same time from two different threads. I've tried using effects in deferred contexts, doesn't work well.

You have few options here, either make a copy of an effect for each thread you are going to use it on,do not use effects at all or use threading primitives like locks to control concurrent access to effects.

The problem with state is something I had to struggle with my self, as it seems that command lists generated from deferred contexts are "isolated", ie when you execute command lists on the immediate context after they are generated, the state does not continue from one to another.

Creating your own shader framework is what I have done, but it takes much more time than using effects.
Thank for the replies,

After many tests I was suspecting that the effect framework was not adapted for deferred context.
May be I'm wrong but, as I already said and Corefanatic also confirmed it, a dedicated framework is the solution.

It'll be interesting to work on a shader framework.
Anyway using the D3D11 effects framework was a good experience because now I know what my needs are and how to design the new shader framework :)


haust.
Well, I've just ran the application with D3D_DRIVER_TYPE_REFERENCE and everthing render fine....

The video card (nVidia Quadro NVS 295, driver 295.73, Windows 7 32 bits) with D3D_DRIVER_TYPE_HARDWARE doesn't seem to handle deferred context as intended.
Maybe I should try with another card just to be sure.

However that won't question the need of a dedicated shader/effect framework.


haust.

This topic is closed to new replies.

Advertisement