20,741
edits
Understanding Rembrandt: Difference between revisions
Jump to navigation
Jump to search
→Scene Complexity
(pm2wiki) |
|||
| Line 21: | Line 21: | ||
I sort of see this on my card - if I'm fragment-limited, it switches to synchronized framrates, I get either 25 or 30 or 60 fps, but not 33 or 47. Completely different when the vertex shader jams, then I get to see arbitrary numbers. Which is a neat first-look diagnostics. Rembrandt is clearly fragment-dominated on my box. | I sort of see this on my card - if I'm fragment-limited, it switches to synchronized framrates, I get either 25 or 30 or 60 fps, but not 33 or 47. Completely different when the vertex shader jams, then I get to see arbitrary numbers. Which is a neat first-look diagnostics. Rembrandt is clearly fragment-dominated on my box. | ||
The thing is, it only takes a few errors in the C++ code that could massively inflate the amount of primitives sent to effects/shaders. And Rembrandt is obviously not well understood now that Fred is not maintaininig it currently. So there might be some low-hanging fruits there, but I am not going to spend hours going through the code unless I see tangible results. | The thing is, it only takes a few errors in the C++ code that could massively inflate the amount of primitives sent to effects/shaders. And Rembrandt is obviously not well understood now that Fred is not maintaininig it currently. So there might be some low-hanging fruits there, but I am not going to spend hours going through the code unless I see tangible results. | ||
| Line 36: | Line 34: | ||
the other thing I noticed is that CPU load doesn't seem to decrease despite AGL/ASL attitude being too high to realistically cast shadows - would these be things that we could add to the effects/shaders to reduce rembrandt workload a bit ? | the other thing I noticed is that CPU load doesn't seem to decrease despite AGL/ASL attitude being too high to realistically cast shadows - would these be things that we could add to the effects/shaders to reduce rembrandt workload a bit ? | ||
== Reducing Complexity ? == | |||
What would be involved in editing effects/shaders to simply discard 50% of all vertices ? I just want to see for myself if that's having an effect here or not ? | |||
In a vertex shader it's fairly difficult to do. To effectively discard a vertex, you need to evaluate some criterion based on its coordinates/attributes and then if that criterion is true move it out of the view frustrum and return, so you run a 'minimal' set of operations. | |||
The obvious thing to do if you want to test response to vertex numbers is to set visibility lower so that terrain is simply not showing up at the vertex shader at all in a controllable way. A theoretically elegant way if you can is to set random numbers as vertex attributes and to move the vertex out of the view frustrum if the random number is smaller than a threshold. But in passing attributes, you're of course changing the pipeline in a substantial way... | |||
If you want to test scaling of fragment shaders, that's much easier to do - evaluate another criterion in the first line which is true half of the time (say whether you're in the right half of the screen, you can test against gl_FragCoord which is the fragment position on the screen) and then insert a discard; if you want to dump the fragment without computing anything. | |||
== Profiling == | == Profiling == | ||