Happy new year! Vivian,
On Friday, December 30, 2011 10:48:40 Vivian Meazza wrote: > The hangs are caused by mipmap generation on the fly by OSG? The hangs are caused by mipmap generation by the driver which happens on forst use of a texture. > The old texture files are static and I would expect them to work into the > future, but the new dds textures will leave them further behind as work > progresses. The only problem in htat is that some users will lose out on > some eyecandy - it will not affect the basic operation of the sim. Which is in this case sad I think. If it's easy to fit both needs I think we should. > > You do not experience any hangs? > > None that I have seen so far Ok. I have also seen one of the machines at the flightgear booth at the fsweekend which did not show any problems. But Thorstens huge machine really hangs in an unaccaptable way. I would really never tolerate this as a user ... > > What is the motivation for you to use dds files? > > It's a better way of storing cubemaps for reflections or other layered > images. The built in mipmap OSG algorithm is a bit slow - using dds works > around this (for some systems) Ok, granted. Use it for that. > > What do you gain by not using the usual image files? > > Dds textures remain in video memory, so we get improved performance when > switching textures. We expect that at least some people will see smoother > performance when loading scenery textures. I haven't been able to measure > any gain, but there are some have reported that they see a subjective > improvement. No, this really should not be a difference. Probably this is what I refer to as these hangs. But the reason is not that dds is in video memory and other textures are not. These *are really all* in video memory. There is no difference between dds and png. The driver decides where to put which buffer objects so that it is accessible to the gpu. And depending on the memory pressure on GPU's memory of the whole system driver the driver might page something out or not. So, once you really reach these huge GPU boards memory limits you might see that using compression you start paging less. But our working set is way below. The real reason appears to me like being the initial mipmap computation when allocating a texture in the driver. And an other post of Erik in this thread tells me that we should try to provide a mipmapping method that already runs in the database loader thread so that on initial allocation in the driver the mipmaps are already present. Also according Eriks comment, compression on the fly on the upload path in the driver seems to work without delay. So, for drivers that announce the compresin extension we can still tell the driver to store the textures compressed on the gpu to minimize gpu memory paging. So, still, since it is technically incorrect to provide these s3 patent precompressed textures to a driver that does not announce the apropriate extension and since we are not allowed to code something that deompresses this, I think we should avoid using this compression for all the provided models/textures. I think of a warning that is issued from the image loader in flightgear that detects when these precompressed textures are seen. So even people using drivers that just offer this extension have a chance to see that the provided textures will not work for others. > > The motivation behind this mentioned change is to sort out the best > > compromise > > so that the hangs hopefully disappear - which I hope to get with > > precomputed > > mipmaps - and being able to display fine with any driver/gpu. > > Seems to work here - I have tried > > --prop:sim/rendering/texture-compression="dxt5" > > I hope that is the right syntax - no warning from fg anyway. I don't see any > problems with running the F16 using that. I might be entirely wrong of > course. Yes, that is thought like that. But since you do not see the hangs in any configuration you can just sit down and watch us testing :) Thanks anyway! Mathias ------------------------------------------------------------------------------ Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
