Suggestion for the constant buffer updates

Feb 9, 2014 at 7:02 PM
Right now in the EvaluateMappings method of the constant buffer, first it's checked if the parameter has changed by declaring a value from it to a value in the constant buffer mappings.Isn't it better if the parameters just have a "bool m_dirty;" in them?And set it whenever their value is changed.

The second suggestion is for the actual data updates - instead of branching out and checking for the parameter type(the cases increase with the number of parameter types supported).Isn't it better if you just store a void pointer to the parameter's internal data and a size_t for size, then set them when the parameter is created.For instance:

m_pAddress = &m_vData;
m_uSize = sizeof(m_vData)

so then you can directly do a cemcpy without checking type and casting?
Feb 15, 2014 at 9:24 PM
Thanks for the suggestions. Here are some comments:

For your first point, the complication comes in when you consider how to handle multiple threads. Each parameter may or may not have been run on the same thread in the previous frame, which means that since the parameter data is stored according to thread that you couldn't be sure if the bool flag applied or not. Ultimately it boils down to the fact that you can't assume that a render pass will run on the same thread every frame. Does that make sense?

For the second point, the main issue here is that because of the design of the parameter system, it is possible that a parameter could share the same name with another parameter but have a different type. That is primarily because the parameter system uses a polymorphic base class, which was a decent choice at the time. However, since then I have started to experiment with a newer system that actually uses the type safety of C++ to its fullest extent. That prototype actually reduces about 3/4 of the code for the pipeline manager and the parameter system, so it is definitely going to be changed in the next version of the engine. In addition, all of the changes are internal to those two systems, which makes the application code changes negligible...

Thanks again for the suggestions!