Re: [Flightgear-devel] Shader performance
After a few more tests, some more observations which seem to be right to me listed here (if that is confirmed, we may perhaps gather these and other statements to the Wiki to get some guidelines for efficient shader coding): * 'big' performance users seem to be the scientists's friends, i.e. functions like exp(x), log(x), sqrt(x) which for me make a noticeable impact :-(. I've made good experience by returning asymptotics explicitly, for instance in a light function f(x) = e / (1.0 + a * exp(-b * (x-c)) )**(1/d) simply asking if x threshold and returning e if the condition is true before attempting to evaluate the function speeds things up quite a bit in many cases while making a tiny error (in my case, 1e-4 or so). I haven't tried it yet, but I suspect now that x*x*x*x would also evaluate much faster than pow(x,4.0) since the first is just a multiplication while the second utilizes a function which is even more general than sqrt(). * GLSL doesn't go for smartness, so it has to be coded in. In an expression like mix(cheapExp, expensiveExp, fraction) even for fraction = 0 expensiveExp is computed. So again, an if (fraction == 0) in front of this can reduce the load quite a bit to compute expensiveExp only if it is really needed. * in the shaders I have seen, usually a very physics-centered approach is taken: We first take the color of an object from the texture, then apply ambient, diffuse and specular light to see what color it takes, then go to the eye and have a look at how much of it is fogged. However, an eye-centered approach seems much better to me - the first question to be asked is 'What can we see of the object?' and if the answer is '99% fog' we don't really need to know the texture or compute specular reflections. Which is to say, in many situations I would perhaps compute the fog function first (if possible) and base my decisions what else to compute for the pixel/vertex dependent on the outcome of that. For instance, in the cloud shader fog comes pretty much last - but we probably could dispense with bottom and away side shading beyond a certain fog value, because it's useless to first compute a darkening and then brighten it to transparent/white again. So far, this hasn't been too relevant because objects which are 99% fogged are soon to be unloaded anyway, because the distance to which terrain is laoded is set by the same parameter as the fog. But this may not be how to continue. The terrain-haze shader already allows the two to be different, and it has also a lot of merit to have terrain loaded even if you can't see it - weather needs to know terrain to get cloud-terrain interactions right, any terrain radar would need it (see for instance the very interesting development 787 MFD Vertical Profile here: http://flightgear.org/forums/viewtopic.php?f=30t=15200 this simply won't work under true IFR conditions when it is needed most because no terrain is loaded). All in all, it seems to me that making shader code efficient is just a very messy and ugly uphill battle in which lots of small effects sum up to something noticeable in the end... Cheers, * Thorsten -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Shader performance
Gary adressed those creating the 3d-models and aircraft in FGFS. Yes, quite. And since your own aircraft doesn't repeat and is there independent of visibility range, so in some sense this is a special case anyway. Problem is, once you have created a model, you don't control what others do with it. Someone might think that a helicopter looks cool parked on a helipad on an airport as a static object, and that a few of them are even better. So suddenly multiple copies of the model end up in the scenery. I don't know first hand what shows up in MP, but some models seem to be a big issue for other pilots from what I have heard. Ultimately, I don't care so much for theoretical arguments of what should scale how, I care for what actually does scale how. The fact is, directly looking at a cluster of ~5 parked AI aircraft decreases my framerate by 25% when I have high vertex shader load whereas I don't recall seeing this for low vertex shader load, that much I have established. The conclusion that models are a potentially large impact and matter is therefore justified. Now, I may be wrong and this has nothing to do with vertices. Then whatever it has to do with would be interesting. But GPU's getting better and better today, but still the shape of the aircraft does not need hundred of vertices to make it look smooth. I believe 'as many as needed but not more' is a very reasonable principle. For an AI plane which most of the time appears as a dot, my smoothness requirements are actually not very high, but my framerate requirements are. The argument that GPU's are getting better isn't a very good one. I have enough ideas and schemes for atmosphere light and more detailed cloud rendering worked out to keep the next-to-next generation of GPUs busy, and I'm guessing so do others. Burning performance for more realistic visuals isn't often that difficult after all... As an example, an overcast layer made of 100 m sized cloudlets would look terrific, would be technically easy to code and would drive any GPU you can buy into single digits (yes, I actually try such insanity now and then just to see with 1 fps how it could look if I had the resources to do it). * Thorsten -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Shader performance
Heiko wrote: And especially in FGFS not really Vertices is one of the big problems, but .xml's and nasal-scripts. No, you can't say that in general. It quite depends on what you do and what options you use. Whatever you compute, it costs some amount of resource, and how long your frame takes is determined by the slowest element. I used to develop in a situation in which I was completely driven by the speed at which Nasal scripts executed, i.e. I saw quite drastically the effect of switching certain Nasal scripts on or off. Handing more and more work over to the GPU means that in general things speeded up and I now see the execution speed of the Nasal scripts no longer, but rather I am now completely driven by the speed at which the GPU can do the rendering, and I actually see improvements in framerate by handing computations elsewhere, e.g. to (to be slightly provocative) Nasal. Basically, you want a situation in which all available processing pipelines are equally filled for best performance. Also, if you notice vertex count or not is a question of visibility range. If you're happy with 16 km default visibility, then it's probably not an issue. I used to think 30 km is a hell of a lot, but after having seen how 120 km look from cruise altitude and actually start to compare with real life, I actually want something like 120 km if I can get it. And since terrain vertex count goes with the square of the visibility, this becomes the determining factor rather sooner than later, and scenery models factor into that in a major way. So you can also pretend it's my fault and I'm asking too much visibility range, while all others are happier with 16 km visibility range and hires high-vertex count models (which is probably better for helicopter people :-) ). But for instance, you told in the forum that you are running a lower than 1 value of cloud density because of performance reasons. Which means that you are seeing the impact of the 3dcloud vertex shader as limiting factor, not some Nasal or xml, because what the cloud density slider does is reduce cloudlet (=vertex) count. I guess my bottomline is that any code running on a per-frame basis should be made more efficient when it can be made more efficient, regardless if it is currently the limiting factor for someone or not, simply because it may be the limiting element for someone else. @Stuart: That's very interesting. Do you have any suggestions for what information we could push onto the fragment shader? I'm still not sure how well my experiences generalize, but the obvious thing to try bothering the fragment shader with would probably be the bottom and away side shading computation. It probably also depends on what other shaders are running - for me, my terrain-haze is the major player, followed by the 3dcloud whereas skydome uses far less resources. I don't know how the balance is changing if water or urban are on. If any of those makes use of the fragment part more heavily, then shifting more things into there might not be as good. Cheers, * Thorsten -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Shader performance
On Sun, 5 Feb 2012, thorsten.i.r...@jyu.fi wrote: I haven't really seen any guidelines about efficient shader coding, but I've come across a few statements here and in the forum now and then, which I so far assumed to be true. I've now spent the last few days benchmarking my lightfield/terrain haze framework to see if I can't squeeze a bit more performance out. Since the results somewhat contradicted things I have assumed to be true before, I thought I might share my observations. 1) vertex shader is fast and efficient, fragment and geometry shaders are comparatively slow and cost performance Some thoughts here (bearing in mind that I'm no expert on the internals of GPUs): The vertex shader is run for each vertex of the mesh each time it is rendered. The fragment shader is run for each fragment generated from the mesh - if the mesh covers a small part of the screen there will be few fragments - if the mesh covers a large part of the screen there will be many fragments (excluding the early Z-clipping of fragments that some GPUs may do). Some implications: - The amount of vertex shader work (to draw a mesh) ought to increase with the #vertices and the complexity of the vertex shader. For a particular mesh and shader the cost is the same each time it is drawn. - The amount of fragment shader work ought to increase with the #fragments/pixels generated for the mesh and the complexity of the fragment shader. This changes online depending on how many pixels of the screen the mesh covers. So, e.g. for effects used on (MP/AI) aircraft it would seem preferable to push complexity to the fragment shader since, most of the time, most of the aircraft will be very small on the screen. OTOH this would seem to suggest the opposite case for the sky-dome - relatively few vertices and often covering a significant part of the screen. Pushing most of the haze shader computation from the vertex to the fragment level would seem to suggest an approximately constant cost for the haze for the same view regardless of scenery complexity since the number of hazy fragments remain about the same. It would be interesting to see more measurements on this. One could account for the cost of the increased number of processed vertices by using the case with no haze at all as a base line. Cheers, Anders -- --- Anders Gidenstam WWW: http://gitorious.org/anders-hangar http://www.gidenstam.org/FlightGear/ -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Shader performance
Pushing most of the haze shader computation from the vertex to the fragment level would seem to suggest an approximately constant cost for the haze for the same view regardless of scenery complexity since the number of hazy fragments remain about the same. Thanks for the explanations - that was *really* helpful to understand what is going on. I did a quick check pushing everything which is not vector geometry to the fragment shader, and... * below 20 km visibility range or so, the scheme appears to be a bit (~10 %) slower than it was previously as vertex-based rendering * from about 20 to about 120 km visibility range, I had a constant and quite usable framerate around 22 fps for full screen 1920x1200 resolution (I suppose since this goes per pixel, the screen resolution should affect this). * above 120 km, the vertex part seemed to become an issue again and I went down to 15 fps around 200 km visibility range (this is a lot more than I had previously seen for that range) I guess this confirms your scaling prediction. * best part - for most of the range below 100 km visibility range, maxing out the cloud view range to 75 km didn't make a lot of difference for the framerate (apparently plenty of extra capacity for vertex rendering) In summary: 120 km visibility range with clouds drawn to 75 km at 22 fps with terrain haze and sunset effects on in the F-16 at full screen resolution 1920x1200. There seems to be something going into the right direction here :-) Have to test this more systematically, and also see if I can shuffle stuff from the skydome frag part to vertex. * Thorsten -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Shader performance
Pushing most of the haze shader computation from the vertex to the fragment level would seem to suggest an approximately constant cost for the haze for the same view regardless of scenery complexity since the number of hazy fragments remain about the same. Thanks for the explanations - that was *really* helpful to understand what is going on. FWIW, I saw with gDebugger that the sky dome is made of more than 23000 vertices, even if a small amount of them are really displayed on screen. In Rembrandt, several pass are done on 1/16th of the size of the screen (1/4th of each dimension), relying on the mag filter to cover the whole screen. This is the case of the blur pass in the AO or Bloom effects. Regards, -Fred -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Shader performance
Pushing most of the haze shader computation from the vertex to the fragment level would seem to suggest an approximately constant cost for the haze for the same view regardless of scenery complexity since the number of hazy fragments remain about the same. Thanks for the explanations - that was *really* helpful to understand what is going on. FWIW, I saw with gDebugger that the sky dome is made of more than 23000 vertices, even if a small amount of them are really displayed on screen. In Rembrandt, several pass are done on 1/16th of the size of the screen (1/4th of each dimension), relying on the mag filter to cover the whole screen. This is the case of the blur pass in the AO or Bloom effects. BTW, in my other terrain engine project, the sky is drawn with a quad (4 vertices at the corners of the screen). The view direction is computed in the vertex shader and then interpolated in a varying and renormalized in the fragment shader. That way there is no wasted computation (except the region overdrawn by the terrain, but that could be optimized with a stencil buffer) -Fred -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Shader performance
Am 06.02.2012 09:51, schrieb thorsten.i.r...@jyu.fi: I guess my bottomline is that any code running on a per-frame basis should be made more efficient when it can be made more efficient, regardless if it is currently the limiting factor for someone or not, simply because it may be the limiting element for someone else. My keyboard does not have a big enough '+' key to second that! Torsten -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Shader performance
Thorsten, And especially in FGFS not really Vertices is one of the big problems, but .xml's and nasal-scripts. No, you can't say that in general. It quite depends on what you do and what options you use. Whatever you compute, it costs some amount of resource, and how long your frame takes is determined by the slowest element. Gary adressed those creating the 3d-models and aircraft in FGFS. Of course, logically you will always run out of GPU power at a certain vertice count which inludes all vertices (aircraft, terrain, clouds, trees...). But GPU's getting better and better today, but still the shape of the aircraft does not need hundred of vertices to make it look smooth. And yes, terrain itself has a big influence on framerate and perfomance. I can remember very good the time (2006/07 ??) when the first detailed Custom Scenery made by Martin Spott and Ralf Gerlich came out- I noticed a good hit on the frame rate, which was only due the more use of terrain-vertices. But that was with an old one-core processor and a very old GeForce 5200... Today I notice that even increasing the visibility no real framerate hit- even with 120km visibility. But a big increase of RAM-Usage. But again: Gary was talking about 3d-models like aircraft. And that was what I adressed as well. I experimented a bit with the different aircraft, and it always turned out that especially Nasal-scripts, and sometimes some .xml's has an big influence of perfomance. Bigger than an high vertice count. Problem is- this behavior depends a very lot on the hardware. In the forum you will find a very lot of people who seems to have an older computer, or a simple Office-computer with low graphic-perfomance. But for instance, you told in the forum that you are running a lower than 1 value of cloud density because of performance reasons. Which means that you are seeing the impact of the 3dcloud vertex shader as limiting factor, not some Nasal or xml, because what the cloud density slider does is reduce cloudlet (=vertex) count. GW on the the ocean gives me even with density =1 about 50-60fps (Fair weather)- when I'm inside the clouds and the full screen is covered with cloudlets I get much, much less (about 15-30fps). The limiting factor here seems to me the transparent textures. The LW does use less cloudlets even with density =1, and so less vertices than GW. Still I can see a higher use of CPU and lower Framerates. I can see what you wanted to say me- and I do see, that you have make great work with your Nasal-driven weather-system. You showed what is possible by using Nasal-scripts, and used this in a very intelligent way. I guess my bottomline is that any code running on a per-frame basis should be made more efficient when it can be made more efficient, regardless if it is currently the limiting factor for someone or not, simply because it may be the limiting element for someone else. Yes. And as Nasal-scripts has a natural limit of perfomance compared to code integrated into Simgear/ Flightgear your work will have much better perfomance if as much as possible has been hardcoded. Heiko still in work: http://www.hoerbird.net/galerie.html But already done: http://www.hoerbird.net/reisen.html -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Shader performance
On Sun, Feb 5, 2012 at 7:50 AM, thorsten.i.r...@jyu.fi wrote: I haven't really seen any guidelines about efficient shader coding, but I've come across a few statements here and in the forum now and then, which I so far assumed to be true. I've now spent the last few days benchmarking my lightfield/terrain haze framework to see if I can't squeeze a bit more performance out. Since the results somewhat contradicted things I have assumed to be true before, I thought I might share my observations. 1) vertex shader is fast and efficient, fragment and geometry shaders are comparatively slow and cost performance I don't know who stated that here, but I intuitively assumed that this must be right. You can imagine that I was surprised that when I trivialized the fragment part of my code, the performance didn't change at all, but when I trivialized the vertex part, the performance doubled. So it seems like the whole performance drain of my code is caused by an overworked vertex shader. I then transferred the haze color computations to the fragment shader, which improved overall performance in my benchmarks by 20-40%. It seems the optimal results appear for a shared workload between vertex and fragment shader. Since for instance 3d clouds run almost exclusively via vertex shader, this may not be an otherwise irrelevant observation. 2) vertex count doesn't matter I've read that in the forum as advice to model-builders quite often. For all I can test, that's wrong. In order to get the same framerate in default scenery and custom Italy CORINE scenery, I have to set the visibility range ~a factor 10 different. That's consistent with a hundred times higher vertex count in the CORINE scenery, or with a factor 10 higher linear resolution of landcover and elevation data, which seems about right. So the vertex count more or less directly sets my framerate. This is also relevant for models, because having a cluster of ~ 5 AI planes (which happened to be stuck into each other) in my view or not caused a 25% change in framerate, so the vertex count of models matters compared with the vertex count of scenery and is not some insignificant correction. Thorsten, #2 has long been a point of frustration for me. I've given up trying to address folks on the forum who say throw all the vertices/polygons at it that you like! Graphics cards can handle millions with no problem! Last time I looked there was even an FG wiki article that advised modelers to use as many polygons as they like. I've worked in the gaming world long enough to know otherwise. Total scene resources matter. Sure, graphics cards are optimized to quickly render large, well-designed objects. You can build a beautiful model with hundreds of thousands of polygons and that's great. But when it's in a scene with gazillions of other objects, it's a hit. Animate it and the situation just gets worse. This is why game designers build objects with minimal vertices and create detail using good texture and shading tricks. People need to understand that their wonderful creations must live and play in the same sandbox as other wonderful creations. But I am not going to rant. I am not going to rant. I am not going to rant... ;) -Gary aka Buckaroo -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Shader performance
On Sun, Feb 5, 2012 at 12:50 PM, Thorsten Renk wrote: I haven't really seen any guidelines about efficient shader coding, but I've come across a few statements here and in the forum now and then, which I so far assumed to be true. I've now spent the last few days benchmarking my lightfield/terrain haze framework to see if I can't squeeze a bit more performance out. Since the results somewhat contradicted things I have assumed to be true before, I thought I might share my observations. Very interesting, and food for thought :) 1) vertex shader is fast and efficient, fragment and geometry shaders are comparatively slow and cost performance snip Since for instance 3d clouds run almost exclusively via vertex shader, this may not be an otherwise irrelevant observation. That's very interesting. Do you have any suggestions for what information we could push onto the fragment shader? 2) vertex count doesn't matter I've read that in the forum as advice to model-builders quite often. For all I can test, that's wrong. In order to get the same framerate in default scenery and custom Italy CORINE scenery, I have to set the visibility range ~a factor 10 different. That's consistent with a hundred times higher vertex count in the CORINE scenery, or with a factor 10 higher linear resolution of landcover and elevation data, which seems about right. So the vertex count more or less directly sets my framerate. I think there are far too many variables in your examples to be able to draw a conclusion that vertex count is the over-riding factor. My understanding from Matthias' comments on the 3D cloud code is that provided the GPU isn't having to reload a different state set, then it should be very efficient indeed in handling larger numbers of vertices. So, in the 3D clouds case, asking the GPU to render a whole set of quads at once to create a cloud is more efficient than rendering each sprite one at a time. (On a related note, while the Impostor's haven't been a success, the other improvements should mean that you can use more sprites per cloud than before for the same perf cost) In your examples, the increase in vertex count will be accompanied by an increase in object count, and (in the AI case) an increase in textures. In each of these cases, the GPU will be loading and unloading state, which is inefficient. A more interesting example would be to compare the impact of a model with 1k vertices, with one with 10k vertices, with the same object count, texture etc. 3) shifting constant-per-frame computations out of the shader doesn't improve performance significantly. I suggested that here as an idea to improve performance of the cloud shaders. I was now able to construct a test case for the idea. The computation in question involved getting a per-frame constant from other constants, i.e. to compute sqrt(2 * hazeAlt * EarthRadius) where hazeAlt is the altitude up to which the haze extends which is passed as a uniform. Computing two of such square root expressions inside the vertex shader or not computing it makes the difference between 21 and 22 fps in a high vertex count benchmark test, i.e. 5%. Which is not that much in itself, but if we would find, track and eliminate all these occasions, the sum of such small improvements might well go into the 20-30%. Makes a lot of sense. I'm happy to add extra Uniforms to the 3D cloud shaders. What do you need calculated in the C++ code? -Stuart -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Shader performance
Quote: #2 has long been a point of frustration for me. I've given up trying to address folks on the forum who say throw all the vertices/polygons at it that you like! Graphics cards can handle millions with no problem! Last time I looked there was even an FG wiki article that advised modelers to use as many polygons as they like. And that's a point of frustration to me! Because no one, not Tim Moore, not me, not anyone, did say this! The wiki article is btw by Tim Moore. But they said, that the bottleneck of GPU's is not the vertice count, but other things. That never meant that you have to use many vertices as you want. ... As many vertices as needed- not more or less! From http://www.flightgear.org/forums/viewtopic.php?f=4t=6030 No one wants to see edgy aircraft as we still have in the repo. But also not oversized models like the Vostok-1. The other big problem was until now, that we didn't had a proper LOD-System- that made it difficult as well. According to TorstenB that has been improved a lot now. And especially in FGFS not really Vertices is one of the big problems, but .xml's and nasal-scripts. It is interesting to see that other Sims like X-Plane and in the past MSFS uses models with far, far more polygons and vertices than we do, and still seems to have good perfomance. How can it be? And there had been an other problem in the past and now: -Many misleading statements about that issues and no tips and helps for those interested to make it right. -People who had more of less the knowledge but kept them for themselves, instead of helping others to make their work better. Or used this to simply showoff. But that's how FGFS-Project has ever been: a tank full of sharks- survival of the fittest. Cheers Heiko -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Shader performance
Dang, I shouldn't have ranted. This added nothing to Thorsten's discussion. My apologies to the list and to Thorsten. -Gary Thorsten, #2 has long been a point of frustration for me. I've given up trying to address folks on the forum who say throw all the vertices/polygons at it that you like! Graphics cards can handle millions with no problem! Last time I looked there was even an FG wiki article that advised modelers to use as many polygons as they like. I've worked in the gaming world long enough to know otherwise. Total scene resources matter. Sure, graphics cards are optimized to quickly render large, well-designed objects. You can build a beautiful model with hundreds of thousands of polygons and that's great. But when it's in a scene with gazillions of other objects, it's a hit. Animate it and the situation just gets worse. This is why game designers build objects with minimal vertices and create detail using good texture and shading tricks. People need to understand that their wonderful creations must live and play in the same sandbox as other wonderful creations. But I am not going to rant. I am not going to rant. I am not going to rant... ;) -Gary aka Buckaroo -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Shader performance and multiple GPU?
This mirrors comments to the OSG mailing list, where people have reported performance issues with multiple GPUs and screens. There hasn't been much of a resolution there; some people have the problem, others don't. I've put together a multi-GPU machine to explore these issues; now I just need to buy another screen :) What threading mode are using? Could you post a screenshot of the OSG statistics (cycle debug statistics twice) and your X configuration file? Tim On Mon, Nov 1, 2010 at 9:06 AM, Torsten Dreyer tors...@t3r.de wrote: Hi, as pointed out in other threads, I am currently assembling a machine with five nVidia cards. The machine and the cards are fast enough to render a steady 60fps, synced to vblank. But this is only with shaders disabled. The moment, I enable shaders and 3d- clouds, the frame rate drops to 20fps and sometimes even less. This does not happen when I limit the display to just one single GPU. One GPU with dual screen (TwinView) runs at framerates beyond limits even with all shaders on and quality level to highest. The moment I add a second card to the setup, it slows down significantly. I know that shaders are little program fragments running on the GPU itself. Now, what happens, if a shader effect spawns multiple GPU's, e.g. a cloud which is visible across the entire window? Cheers, Torsten -- Nokia and ATT present the 2010 Calling All Innovators-North America contest Create new apps games for the Nokia N8 for consumers in U.S. and Canada $10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store http://p.sf.net/sfu/nokia-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Nokia and ATT present the 2010 Calling All Innovators-North America contest Create new apps games for the Nokia N8 for consumers in U.S. and Canada $10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store http://p.sf.net/sfu/nokia-dev2dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Shader performance and multiple GPU?
This mirrors comments to the OSG mailing list, where people have reported performance issues with multiple GPUs and screens. There hasn't been much of a resolution there; some people have the problem, others don't. I've put together a multi-GPU machine to explore these issues; now I just need to buy another screen :) What threading mode are using? Could you post a screenshot of the OSG statistics (cycle debug statistics twice) and your X configuration file You can find the configuration files here http://wiki.flightgear.org/index.php/FSweekend_2010#Configuration_files I'll try to post the statistics and later today. FWIW, I get occasional hanging fgfs with a complete black screen very soon during startup. Here is the output of --log-level=debug (not very informative) Processing command line arguments Finished command line arguments Initializing splash screen found path:Aircraft/SenecaII/splash.png via /sim/aircraft-dir: /home/flightgear/fg-osg/data/Aircraft/SenecaII/splash.png Unknown font name '', defaulting to Helvetica Unknown font name '', defaulting to Helvetica Unknown font name '', defaulting to Helvetica It ends up in an unkillable fgfs (not even kill -9 from root kills) and I have to reboot the machine. Looks like a deadlock in the driver :-( Cheers, Torsten -- Nokia and ATT present the 2010 Calling All Innovators-North America contest Create new apps games for the Nokia N8 for consumers in U.S. and Canada $10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store http://p.sf.net/sfu/nokia-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Shader performance and multiple GPU?
Looks like this is a hardware problem. Looking at the kernel log, I found irq 16: nobody cared (try booting with the irqpoll option) irq 16 is being used by nvidia and the onboard USB ports. After disabling USB in the BIOS, it seems like everything is running smooth. Because all my control devices are connected by usb, I re-enabled USB and started the kernel with acpi=debug. So far it's running - now I'll check shader-performance... Torsten This mirrors comments to the OSG mailing list, where people have reported performance issues with multiple GPUs and screens. There hasn't been much of a resolution there; some people have the problem, others don't. I've put together a multi-GPU machine to explore these issues; now I just need to buy another screen :) What threading mode are using? Could you post a screenshot of the OSG statistics (cycle debug statistics twice) and your X configuration file? Tim On Mon, Nov 1, 2010 at 9:06 AM, Torsten Dreyer tors...@t3r.de wrote: Hi, as pointed out in other threads, I am currently assembling a machine with five nVidia cards. The machine and the cards are fast enough to render a steady 60fps, synced to vblank. But this is only with shaders disabled. The moment, I enable shaders and 3d- clouds, the frame rate drops to 20fps and sometimes even less. This does not happen when I limit the display to just one single GPU. One GPU with dual screen (TwinView) runs at framerates beyond limits even with all shaders on and quality level to highest. The moment I add a second card to the setup, it slows down significantly. I know that shaders are little program fragments running on the GPU itself. Now, what happens, if a shader effect spawns multiple GPU's, e.g. a cloud which is visible across the entire window? Cheers, Torsten -- Nokia and ATT present the 2010 Calling All Innovators-North America contest Create new apps games for the Nokia N8 for consumers in U.S. and Canada $10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store http://p.sf.net/sfu/nokia-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
