Hi Paul, There is well known timing issue with AMD CPUs. Have you seen this document: http://developer.amd.com/assets/TSC_Dual-Core_Utility.pdf
Btw I have these AMD timing patches installed. But also tried to run without them. They don't affect the issues I descried earlier. Frankly, I do not really care about timing precision. My concern is the fact that application crashes or freezes and I cannot use FBO with multi monitor and multi threaded modes. All the CPUs these days are multicore so this is a big issue. Sure I can force SingleThreading but it would mean loosing power of aditional cores. Cheers, Wojtek -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Paul Speed Sent: Wednesday, April 02, 2008 6:54 PM To: OpenSceneGraph Users Subject: Re: [osg-users] Windows / NVidia / multi monitor / muti threading (/FBO) problems One thing... have you tried with a fresh reboot or had the machine been running for a while? The reason I ask is because I see odd timing behavior on my Athlon 64 X2 (also running XP). The clearest example of the oddity is querying the high resolution timers. Occasionally the value jumps around... but only after the machine has been running a while. This really messes with some of the timing/profiling stuff in one of our applications and sometimes causes some odd system stability when running timing sensitive applications (music recorders, etc.) The working theory (and I have not been able to prove it) is that each core has its own time but that they get out of sync. So if a thread switches cores the high res timers go crazy. It's not just my apps that show this either. CPU monitors, etc. all exhibit this problem. The monitoring application that came with my motherboard even shows the CPU speed jumping around on occasion. But only after running for a while. Note: I haven't tried bios refreshes or anything like that. I have no idea if there is a fix for this issue but thought it might be something to check before condemning nVidia, etc.. I like AMD a lot but my dual core intel does not have this problem. -Paul Wojciech Lewandowski wrote: > Hi All, > > Few threads touched the same subject recently so I decided to share > my observations and maybe provoke some discussion on the problem. Maybe > together we can get it fixed. I said "got it fixed" because I am afraid > that it might be difficult without driver changes. > > Problems are related to OSG on Windows XP & Vista with fairly recent > NVidia boards (6x00-9x00) / dual view / multi threading modes. I don't > want to discuss single monitor (or horizontal span) issues in this post. > > In my testing I went through following GeForce driver versions: 94.24, > 97.94, 162.65, 169.21, 163.75, 169.28, 169.44, 169.61, 174.74. > Tests done in DUAL VIEW / MULTITHREADING modes. Athlon62 X2 (DUAL > CORE). OSG latest SVN from last 2 weeks (2.3.x). > > OBSERVED ISSUES: > > All pre 169.xx drivers: > - Statistics does not show GPU stats. Draw timings are growing till the > moment when framerate hz start to drop. This issue is present with > number of examples. Use osgviewer dumptruck.osg to reproduce it. > > 169.xx and 174.74 drivers: > - GPU stats seem ok. But osgviewer dumptruck.osg shows complete garbage. > Things get better when osgviewer is started with --SingleThreaded > option and Threading modes are later changed with Threading handler. > > All driver versions: > - FBO use problems. Number of examples using RTT cameras (prerender, > shadow, simulation) show erratic behaviour. Usually one screen is > incorrect, sometimes apllication freezes. Output console prints FBO > error messages. FBO apply fails on one screen. Whats interesting both > screens are correctly drawn for the first frame, error appears in > consecutive frames. > > - FBO problems are also present in SINGLE monitor mutithreaded > configurations. Examples usually start correctly but freeze or FBO > textures stop to update when Threading handler changes mode. One > exception: I noticed that oldest (94.24) drivers tested here are working > correctly in single monitor mode (no matter what threading mode is > selected). They are so old that they may be single threaded > internally. Unfortunately they do show the same erratic behaviour as the > other versions in multi monitor mode. > > All above problems dissapear when examples are run with --SingleThreaded > option. Most of the problems also dissapear when run with One monitor. > There are exceptions but they seem to vary with driver versions. > > SOLUTIONS (or rather lack of them): > > Driver Release Notes, number of posts on the WEB, posts on the OSG forum > suggest that many OpenGL problems might be related to > multithreaded usage. There is a number of CPU fixes available on the > net. Some from microsoft, some from AMD or Intel. NVidia recommends > registry tweaks or turning off the Threaded optimization. I tried all > them without success. > > Only one method did change the situation. When I disabled second core on > the CPU, allmost all above problems vanished. In other words I could use > MULTIMONITOR and MULTITHREADED OSG on one core CPU. In my opinion this > is the strongest argument for the claim that there are NVidia driver > isuses with mutithreaded OpenGL. The only case where FBO was still > freezing on single core machine was when Threading mode was changed to > CullThreadPerCameraDrawThreadPerContext. > > Unfortunatelly, disabling all the cores except one is no solution at > all. I guess its better to run --SingleThreaded. I am curious what are > the others' observations ? Maybe someone found some real solutions ? > Maybe some workarounds could be made in OSG ? > > DISCLAIMERS: > > - I made all my testing on NVidia boards and have no idea how ATI boards > would behave in similar scenarios. > > - Most of the tests were done on Windows XP SP2 / Athlon 64 X2 / NVidia > GeForce 7800 GTX. In a number of cases I changed graphics board to 8800 > GTS or tested on my collegues Vista 64 bit Athlon Quad core or Intel > Core 2 Duo with 8800 GTS. In none of this cases I have noticed that > switch to other archtiecture would change observed issues that I had > with my primary configuration. Thats why I claim that problems are wider > and repeatable but your results may still vary. > > - Attempts to change "Threaded optimization" or "Multi-display/mixed-GPU > acceleration" in NVidia Control Panel either didn't help or made it > worse (instant freeze or no display). So I generally keept them at > defaults: ie Multiple display performance mode and Threaded > optimization set to Auto. > > > Thanks for the attention, > Do you have similar or different observations ? Hopefully solutions ? > > Wojtek Lewandowski > > > ------------------------------------------------------------------------ > > _______________________________________________ > osg-users mailing list > [email protected] > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
