I didnвЂ™t understand them so lets get rid of them totally and see what happens). So I then removed the shaders completely from the pipeline (i.e. I wasnвЂ™t expecting to find anything partly because I donвЂ™t really properly understand shaders but it all looked ok. Step 4 ShadersДЄs the deferred pipeline uses a different set of shaders I went through each one and checked it for anything that was wrong. So I removed everything that wasnвЂ™t essential conditions, accesses to the property tree even the odd cull visitor but nothing made a difference to the performance. For example a massive inefficiency or thread locking wait state having removed pretty much everything that wasnвЂ™t essential So IвЂ™ve got a cut down three stage deferred pipeline now I need to look at the code.ДЄs itвЂ™s looking like itвЂ™s not the number of stages, and with a rendering pipeline that is similar to the forward one then I should be getting the same rate (IвЂ™m not) if not then it canвЂ™t be theВ GPU, or rather it could be, but before coming back to this I first needed to remove anything that looked possibly unnecessary. Effectively no magic solution was found here (I wasnвЂ™t expecting one after some study of theВ OSGВ documentation and lists). I tried each of the possible options and although things improved slightly the change was consistent between both the forward and deferred pipeline. Referring to figure(1) below you can see that IвЂ™ve reduced the number of stages in the deferred pipeline to just 3 and yet each stage is taking much longer than the equivalent in forward rendering.ДЄt this point I was confused something was clearly odd and usually you can gain performance improvements by hacking out half of it but this wasnвЂ™t producing any noticeable differences.

So IвЂ™ve continued up until the point where there was almost nothing left. Next more of the stages had to go I also removed all of the unnecessary items from the pipeline (conditions, 16bit buffers etc) just in case these were affecting theВ OSGВ processing. IвЂ™m not a glsl / gpu expert but I do understand enough of how graphics is done to know that this is often the cause. I then fiddled about with the texture buffers (just in case it something was stalling theВ GPUВ because the buffers werenвЂ™t in the right format. I started by removing bloom, ambient occlusion, but no difference. All measurements were taken with the same osg debug elements on screen. To gain a reasonable baseline I used the same in-air initial position and then removed something from the deferred pipeline and measured it. IвЂ™m usingВ ALSВ (with FG 3.5(git)) as a comparison. The background to this work required a lot of studying of the code, configuration and notes 1 Looking at the card from aВ GPUВ monitor (MSIВ Afterburner) I see aВ GPUВ activity of around 1% вЂ“ so something is obviously wrong. I have a reasonable system and over the last few months IвЂ™ve changed graphics cards (GTX460 to R9 290) and what struck me as strange was that changing graphics cards didnвЂ™t really same to make much difference to the frame rate. The second reason is the performance itвЂ™s long been recognized that deferred pipeline is slow I would expect a performance hit вЂ“ but it seems to be disproportionate. Personally there are two reasons that IвЂ™m investigating this the first is to figure out the ability to have post processing effects that arenвЂ™t possible with forward rendering. Long term I donвЂ™t know whatвЂ™s right and itвЂ™s not really up to me anyway so IвЂ™m just presenting my findings. What I personally like about rembrandt is the ability to have light sources. Rembrandt shadows are too flickery and a shadow map as Thorsten has added toВ ALSВ is arguably 2В a much better way than the way Rembrandt does it. The deferred configurable pipeline has great possibilities but poor performance.ДЄLSВ works exceptionally well and ThorstenR has done amazing stuff with it and not burnt frame rate at all.

Flightgear graphics