884
edits
Understanding Rembrandt: Difference between revisions
Jump to navigation
Jump to search
Undo revision 68517 by EmmanuelFrance (talk)
m (fps -> FPS) |
(Undo revision 68517 by EmmanuelFrance (talk)) |
||
| Line 5: | Line 5: | ||
Try to better understand -and document- Rembrandt internals, so that we can better troubleshoot performance issues. | Try to better understand -and document- Rembrandt internals, so that we can better troubleshoot performance issues. | ||
Ok, I just tried Rembrandt again (after spending 5 minutes reading the wiki article), and while my computer is much less powerful than yours, I am also getting roughly ~15 | Ok, I just tried Rembrandt again (after spending 5 minutes reading the wiki article), and while my computer is much less powerful than yours, I am also getting roughly ~15 fps at ksfo with the ufo - and looking at those OSG stats, there's a hell lot of stuff going on obviously, i.e. we have 10 different cameras 3 of them extremely busy (0,1 and 5) | ||
The performance is actually decent, though ALS with all goodies maxed out gets 25 | The performance is actually decent, though ALS with all goodies maxed out gets 25 fps for the same scene under Linux (there's the grass shader needing lots of noise calls for instance). I don't get a huge green bar. | ||
The big hit comes when I try to see Las Vegas (with the Urban shader) - that drives me down to 3 | The big hit comes when I try to see Las Vegas (with the Urban shader) - that drives me down to 3 fps. Or when I try to activate filtering and switch it to 3 - then my framerate likewise dives down to 4. | ||
So I remember how this went - the base performance of Rembrandt without shadows was actually pretty decent on my box under Windows, 30 | So I remember how this went - the base performance of Rembrandt without shadows was actually pretty decent on my box under Windows, 30 fps or so. Switching shadows on cost me some of that but was still flyable, but the shadows were flickering so much that I got a headache after 5 minutes, so I needed to switch the filtering to max. to be able to look at it - and that killed the framerate for good. | ||
If this is something that we really want to investigate more closely, I guess it would be a good idea to read the "deferred rendering" paper that Fred linked to in the article - at least those parts describing the 3 cameras that seem really busy (geometry/shadows/lighting) | If this is something that we really want to investigate more closely, I guess it would be a good idea to read the "deferred rendering" paper that Fred linked to in the article - at least those parts describing the 3 cameras that seem really busy (geometry/shadows/lighting) | ||
== Scene Complexity == | == Scene Complexity == | ||
Purely from a troubleshooting standpoint, I would like to know what kind of effect/impact we can expect from discarding vertices/triangles and quads from all three cameras (having 10 | Purely from a troubleshooting standpoint, I would like to know what kind of effect/impact we can expect from discarding vertices/triangles and quads from all three cameras (having 10 fps even at night time seems very odd), i.e. if discarding those translate into any proportional/tangible performance gains | ||
Actually, the base idea of deferred rendering is that it should be pretty insensitive to the amount of vertices you feed to it because it really has a minimal geometry shader (computationally cheaper than default even, it basically only notes where stuff is on the screen and stores the non-projected position in a buffer) and all the actual work of lighting etc. is done in the fragment pipelines. So I'd be very surprised if it responds at all to changes of the vertex load. | Actually, the base idea of deferred rendering is that it should be pretty insensitive to the amount of vertices you feed to it because it really has a minimal geometry shader (computationally cheaper than default even, it basically only notes where stuff is on the screen and stores the non-projected position in a buffer) and all the actual work of lighting etc. is done in the fragment pipelines. So I'd be very surprised if it responds at all to changes of the vertex load. | ||
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 | 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 29: | Line 29: | ||
The number of vertices etc. should be fairly minimal then, shouldn't it ? | The number of vertices etc. should be fairly minimal then, shouldn't it ? | ||
ok, when going to zero-scenery places, I am getting rock-solid 60 | ok, when going to zero-scenery places, I am getting rock-solid 60 fps/25ms here (daytime), with Rembrandt running with aircraft shadows, even with maxed out settings. | ||
Can we work with that ? What about you ? | Can we work with that ? What about you ? | ||
I remember your "orbitview" (?) project where you placed a huge sphere into the scenery. Could this help us to do some troubleshooting, i.e. using Nasal to place a few models (and possibly light sources) and see what's having an impact ? | I remember your "orbitview" (?) project where you placed a huge sphere into the scenery. Could this help us to do some troubleshooting, i.e. using Nasal to place a few models (and possibly light sources) and see what's having an impact ? | ||
| Line 49: | Line 49: | ||
I am going to check what the C++ runtime profile looks like in comparison to the classical renderer. | I am going to check what the C++ runtime profile looks like in comparison to the classical renderer. | ||
Okay, I left rembrandt running for 10 minutes with the profiler enabled: fgcommand("profiler-start") - for some reason, the profile showed that "osgParticles" were eating up /some/ resources despite being not enabled - I tried to explicitly disable them, but that would still not change anything, so I removed the corresponding subsystem from src/Main/fg_init.cxx, which gave me +8 | Okay, I left rembrandt running for 10 minutes with the profiler enabled: fgcommand("profiler-start") - for some reason, the profile showed that "osgParticles" were eating up /some/ resources despite being not enabled - I tried to explicitly disable them, but that would still not change anything, so I removed the corresponding subsystem from src/Main/fg_init.cxx, which gave me +8 fps: | ||
<syntaxhighlight lang="diff"> | <syntaxhighlight lang="diff"> | ||
diff --git a/src/Main/fg_init.cxx b/src/Main/fg_init.cxx | diff --git a/src/Main/fg_init.cxx b/src/Main/fg_init.cxx | ||
| Line 83: | Line 83: | ||
== Shadows at night time == | == Shadows at night time == | ||
Well, something seems a bit odd there, because rembrandt is doing shadows, right ? And when I switch to night time mode, I am still just getting 10-15 | Well, something seems a bit odd there, because rembrandt is doing shadows, right ? And when I switch to night time mode, I am still just getting 10-15 fps and seeing similar subsystem/osg activity. | ||
as far as I know it's doing shadows at night just as well. If you drive your ufo to a Rembrandt-defined light source, I think it will cast a shadow also at night. I don't think the shadow part is off just because the sun is down. | as far as I know it's doing shadows at night just as well. If you drive your ufo to a Rembrandt-defined light source, I think it will cast a shadow also at night. I don't think the shadow part is off just because the sun is down. | ||
| Line 96: | Line 96: | ||
== Zero Scenery Tests == | == Zero Scenery Tests == | ||
Using '''--aircraft=ufo - --enable-rembrandt --prop:/sim/rendering/shadows/map-size=8192 --prop:/sim/rendering/shadows/num-cascades=4''' | Using '''--aircraft=ufo - --enable-rembrandt --prop:/sim/rendering/shadows/map-size=8192 --prop:/sim/rendering/shadows/num-cascades=4''' | ||
I can even get way beyond 60 | I can even get way beyond 60 fps when there's not scenery to be displayed, it would be interesting to check what Fred did there, i.e. if there are heuristics in place to recognize this ? We would probably want to add a few static models to the scenery and see what the performance impact is like. | ||
I think through roughly a dozen different test cases like these, one could incrementally understand rembrandt and its stages - obviously, one would now need to edit some of the XML files and maybe some effects/shaders to see how things are affected | I think through roughly a dozen different test cases like these, one could incrementally understand rembrandt and its stages - obviously, one would now need to edit some of the XML files and maybe some effects/shaders to see how things are affected | ||