Is there a way to shrink RenderParameter?

Dec 7, 2012 at 8:14 PM
Edited Dec 7, 2012 at 11:32 PM

Render parameters currently use 5x the memory(NUM_THREADS(4)+1)) for the parameter to make it work with multithreading,but is there some trick to easily get around this? :D or does it call for some refactoring

Dec 8, 2012 at 8:17 PM

There is no current way to reduce this, except to reduce the number of threads being used (a constant defined in pch.h).  If it was really important, you could technically put the parameter manager instance into the render view, and then you would only have as many duplicates as there are render views - which would most of the time be a win regarding memory usage.

Do you see any applications where this is an issue?

Dec 10, 2012 at 9:57 AM

well nothing in particular,I was just thinking that it'll take more space up when you start using a huge amount of parameters,like if you have 300 space ships flying around each with its transform parameters

Dec 10, 2012 at 11:13 AM

Actually in that particular situation, you would only have the number of parameters that the material would require.  The parameter manager holds one instance of a parameter for each uniquely named input to a shader program.  So while that one instance will hold 5 copies of the data to enable multithreaded processing, every instance of an entity that uses those parameters will use them serially - so we only need one 'bank' of parameters.

Of course, if there are lots and lots of material variations, then it could become an issue, but I haven't seen this issue occur yet.  It might be a nice feature to provide some metric information from the parameter manager to make the memory consumption more easily visible.  I'll see what I can do about that...

Dec 13, 2012 at 1:22 PM
Edited Dec 13, 2012 at 4:40 PM

ok wait isn't it safe to read a variable from multiple threads anyway?(sorry if i sound stupid,I'm just trying to get my head around the parameter system xD)

Dec 19, 2012 at 11:11 AM

It is safe to read data from multiple threads simultaneously - only if you aren't writing to the data on any of the threads at the same time.  So when each render view is being processed, it is processed on one thread and that thread is assigned a parameter manager.  That parameter manager is used by all of the entities in the scene within that render view, and hence there is reading and writing to the parameter system (but only for that parameter manager's slot within the parameters!).

This was exactly the reason that it had to be done with multiple copies - consider this scenario: you have two perspective render views of the same scene being processed at the same time in parallel.  The first entity in view A would set his world matrix right before rendering, and at the same time, another entity could set his world matrix on the other thread in view B.  This clearly isn't going to work out for someone :)

Instead, with separate 'slots' for each thread to use, we create a mini parameter ecosystem for the parameter managers to use and isolate them from one another.