Hi Emilian, > Understood... > I will refrain from any further tests/opinions on this topic then. Please > accept my apologies, and disregard any of the issues I've raised. > Everything's working smooth, and looks better than IRL... it's just my > imagination playing tricks, better get my eyes checked
that's not a very fair assessment of my response. I identified one out of four issues as 'not touched by the commit', acknowledged two more (corn rows,/lack of specular), asked you for additional information with regard to one of them (dds and specular) and sketched my solution how corn rows can be fixed. So there's really no need for you to feel ignored and get ironic on me. With regard to the last issue, just maybe I should explain this more clearly: I'm a scientist, and I believe in evidence. I don't believe in claims, opinions, convictions of others,... if you want me to believe what you say is true, then the way to do that is to show me the evidence. I don't believe you because you're such a nice guy and not even because you've read so many books and articles on 3d rendering (nothing personal, just acquired habit). Now, you have an observation that when there's heavy load on the system, the framerate gets uneven. I have the same observation. Some people attribute that to Nasal, so any stuttering just proves Nasal is bad and we should run all in C++. You attribute this to the vertex shader, so any stuttering proves load in the vertex shader is bad and we should move all to the fragment shader. My personal pet theory is that whenever there's high load in the system, it tends to run less evenly, because I get the same uneven framerate with a Nasal bottleneck, a vertex shader bottleneck and a fragment shader bottleneck. It'd be interesting to find the actual cause (which I suspect is things being shuffled in and out of memory as you turn, a kind of mico 'sit in the F-16 and look back for the first time' effect) and fix it if possible. What makes such feedback useless for me is that I can't possibly win the argument, because whatever my data and experience is doesn't count. We've all witnessed the Nasal discussion, so take the case of texture2D inside conditionals. My experience shows that texture2D costs 80% of the additional performance for an overlay texture, texel mixing costs 20%. So it'd be efficient to only load a texture when needed. You have taught me that this can't be done in a non-uniform conditional no matter how desirable, and I've read the source you gave me and two others. But all sources agreed I can look up a texture inside a uniform conditional, because there are no issues with gradients in a uniform. Thus, I have three sources in agreement with my own tests that texture lookup conditional on shader quality level uniforms works as it should. Which means if I have four overlay textures but only use one at my current quality level, I can save a lot of performance. Yet you insist that this shouldn't be done and causes problems, in spite of three references, the conceptual point that an uniform conditional cannot create a discontinuous gradient in a draw and my practical experience agreeing it can be done and runs faster. So just how am I supposed to have a meaningful discussion about performance with you? What could possibly convince you? Somehow, whenever I find a way to make shaders run faster, your response goes along " it might give *you* a fps boost in corner cases". It doesn't matter if the algorithm is genuinely more efficient, it's always just my performance gain whereas it runs worse for everyone else. How do you know that? Do you have the code I've discarded because it didn't work fast enough? Did you test the code I have discarded on 5 different systems? Where is any bit of evidence for what you say? As far as it stands, it's just a wild claim, backed up by exactly nothing. Also, it's always just a corner case. No, it isn't. Things which I have optimized from code blocks I've taken from others (you among them) is not passing what is essentially a constant as a varying vec3, not passing a varying vec4 but a varying vec3 when the alpha channel is trivial, not normalizing a vector before and after passing it from vertex to fragment shader but just once and not doing pixels underneath other opaque pixels and you're not going to convince me that these only improve things only for me or that these affect corner cases. I actually spend a lot of time and effort on optimization, and I really start building a picture of how things tie together and how they affect framerate. The tree code in atmospheric light scattering runs now two times as fast for me as the first working version, and I'm actually somewhat proud of that. I value your insights on obscure driver-specific problems and unexpected pitfalls, but I frankly don't think I need your lectures in how to optimize shader code, I've seen little evidence that you habitually do that in the code you maintain. So, for these reasons, I don't really care if you think that the stuttering would go away if more load would go to the fragment shader. It didn't do that for me when I put more load to the fragment shader, it isn't absent in situations I can make clearly fragment shader dominated and I see no conceptual reason why this should be the case as both shaders run per frame. As I said, I care for evidence. So where's the evidence that what you say can be linked to vertex vs. fragment as opposed to other factors? Without the evidence, why is what you say more than just 'Doesn't really run that smooth on my somewhat older system.' No, probably doesn't. Neither does your IAR-80 on mine. Neither does Rembrandt on mine. But that's probably just my aging hardware and not your or Fred's fault. On the other end, I got also feedback like 'Don't mind putting more stuff in even if it doesn't run for you any more - it runs really well for me, and the next generation of GPU's is going to be even faster.' There is no way to please every hardware requirement, hence I don't try. So, we can make this conversation becoming useful, in which case you start showing me your evidence and start taking mine more seriously, we can try finding enough evidence to link a problem to a cause and learn from each other or we can take all problems as proof of what we've always known and leave it at that. Cheers, * Thorsten ------------------------------------------------------------------------------ Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
