parameter setting question

Dec 31, 2014 at 4:15 PM
hi Jason,

While comparing the sample projects "Basic computer shader" and "Image processor", two different approaches were used for setting the shader resources (the image to be sampled).
In "basic computer shader", after the texture is loaded from the file, it's set using the call:
m_pRenderer11->m_pParamMgr->SetShaderResourceParameter( L"InputMap", m_Texture );
In "image processor", the texture is loaded and set via a reference:
m_pInputParameter = m_pRenderer11->m_pParamMgr->GetShaderResourceParameterRef( std::wstring( L"InputMap" ) );
If I use the first approach in "image processor", it will show nothing on screen. When I look at these two methods (SetShaderResourceParameter() and InitializeParameterData() ), they seem like doing the same thing, end up calling SetParameterData(). So why is that "image processor" must use the second approach?
Jan 2, 2015 at 2:46 PM
This has to do with the pipeline execution method used in each case. The BasicComputeShader sample uses a simple, single render task structure to perform its work. The image processor sample actually has multiple different render tasks happening (one for the image processing, one for the text rendering).

The parameter system is designed to work with multiple threads in parallel accessing (both reading and writing) parameter data. The SetShaderResourceParameter method is actually a way to set a value for only a single thread (the thread is determined by the parameter manager pointer being passed to the setting object), while the InitializeParameterData does the same thing with the exception that it sets the value for all of the threads at once.

This inconsistency between the two methods is indeed not optimal. It would be better to find a way to utilize the first method (SetShaderResourceParameter) in both instances. That should be possible to do though - instead of directly setting the value in the parameter manager, we should be able to set the value in a parameter writer and let that do the parameter setting for us. That would probably require a new type of pipeline executor to be created as well (for calling dispatch). Let me think about the best way to do this, and we can make an update to correct the disparity.

Thanks for bringing this up!
Marked as answer by wxz on 1/3/2015 at 6:52 AM