   [MDX] Bug in PresentationParameters, documentation or hardware?
  Good afternoon,I'm working on a simple MDX sample to show how to code your own MDX app from ground up using a default Windows Form project. After stuggling for some time with inexplicably low framerates, I changed a bunch of parameters to see where the issue was coming from.It turned out that I hadn't set the PresentationInterval in the PresentParameters for creating my device, which gave me a framerate of ~40 fps for just rendering a simple mesh. I assumed this ommission would work out, since the docs say that:Quote:For a windowed swap chain, this value must be PresentInterval.Default (0).When I use this PresentInterval.Default value for this property though, the framerate does not improve at all. Setting this value to PresentInterval.Immediate however gives me a framerate of 4400+ fps. How about that? To be sure, I checked the C++ docs and these tell something completely different, but offers no recommendation:Quote:Windowed mode supports D3DPRESENT_INTERVAL_DEFAULT, D3DPRESENT_INTERVAL_IMMEDIATE, and D3DPRESENT_INTERVAL_ONE. D3DPRESENT_INTERVAL_DEFAULT and the D3DPRESENT_INTERVAL_ONE are nearly equivalent (see the information regarding timer resolution below). They perform similarly to COPY_VSYNC in that there is only one present per frame, and they prevent tearing with beam-following. In contrast, D3DPRESENT_INTERVAL_IMMEDIATE will attempt to provide an unlimited presentation rate.So, I have two questions:1) Should I just use PresentInterval.Immediate, the managed docs be damned?2) I don't understand why the framerate is so terribly low when using PresentInterval.Default. I understand it's trying to match the monitor's refresh rate, but that's obviously 60Hz rather than 40Hz. Plus, some occasional slowdowns to ~10 fps when using this value seems to hint at another problem. I've been having various issues with my GeForce 7800GTX on previous occasions, so I was wondering if this issue might have something to do with that infernal card again. It almost seems like it only works properly in fullscreen. This problem doesn't show when I run the sample in fullscreen, no matter what value I use for the PresentationInterval. Checking back to my dreaded instancing sample, I also found that this one runs perfectly in fullscreen (~69 fps) while it can only render the exact same scene at ~2 fps in Windowed mode. It's built on the MDX SampleFramework, so any issues with PresentParameters should be gracefully handled...Has anyone experienced similar issues with a 7800GTX or have I just gotten myself a buggy card here? I must have tried just about all drivers by now and I also tried contacting NVidia about this through the registered partners site, but I haven't heard from them yet [headshake]Thanks for reading this rather huge question and for any feedback you can provide.   
  I had noticed this myself (also on nvidia hardware, a 6600gt, if that matters) and found that setting PresentInterval.Default wasn't equivalent to PresentInterval.One.In fact Default seems to half v-sync (my monitor is at 100hz and the fps stays at a constant 50 with Default).However, explicitly setting the PresentInterval to PresentInterval.One resulted in a proper v-sync'd frames per second.I can't give you any real explanation as to why this is though [smile]Regards,ViLiO   ;  I just gave it a go with an application of mine. If I didn't specify a PresentInterval, I got an FPS of 43-44. If I specified ONE, I got 87 FPS. If I use Immediate, I get over 400.It must be defaulting to Two, though when I try to create my device with that setting I get an invalid call exception.This is MDX2.0, btw. You guys didn't specify :). 7600GT, too :).   ;  Thanks for the replies guys, at least I know now that it's not my card that's causing this issue. After the instancing horror from some time ago and with this new problem, I was seriously beginning to wonder if I should ship it back.If someone with an ATI card could check this out to see what happens, that'd be great. This way we could determine if the problem is a NVidia specific issue or if it's something with (Managed?) DirectX. Though this won't magically solve the problem, I'd like to know who to blame for my lost time [wink]Thanks again!   ;Quote:Original post by remigiusIf someone with an ATI card could check this out to see what happens, that'd be great. This way we could determine if the problem is a NVidia specific issue or if it's something with (Managed?) DirectX. Though this won't magically solve the problem, I'd like to know who to blame for my lost time I'll get right on it as soon as I get back to my computer.  I have a Radeon X550 that should work just fine for an ATI test. [smile]-AJ   ;  On my Radeon 9600xt It defaults to One, I'll have to test it out on my NVidia card and see what happens.However I'm using MDX 1.0.2902 so maybe its a MDX 2.0 problem.  In any case, why not just use Immediate?  It's much more useful so you can gauge performance etc.;Quote:Original post by remigius1) Should I just use PresentInterval.Immediate, the managed docs be damned?Yes, this is a documentation bug.Quote:2) I don't understand why the framerate is so terribly low when using PresentInterval.Default. I understand it's trying to match the monitor's refresh rate, but that's obviously 60Hz rather than 40Hz. Plus, some occasional slowdowns to ~10 fps when using this value seems to hint at another problem. Here's the documentation, with a couple of bold hints from me:Windowed mode supports D3DPRESENT_INTERVAL_DEFAULT, D3DPRESENT_INTERVAL_IMMEDIATE, and D3DPRESENT_INTERVAL_ONE. D3DPRESENT_INTERVAL_DEFAULT and the D3DPRESENT_INTERVAL_ONE are nearly equivalent (see the information regarding timer resolution below). They perform similarly to COPY_VSYNC in that there is only one present per frame, and they prevent tearing with beam-following. In contrast, D3DPRESENT_INTERVAL_IMMEDIATE will attempt to provide an unlimited presentation rate.Full-screen mode supports similar usage as windowed mode by supporting D3DPRESENT_INTERVAL_IMMEDIATE regardless of the refresh rate or swap effect. D3DPRESENT_INTERVAL_DEFAULT uses the default system timer resolution whereas the D3DPRESENT_INTERVAL_ONE calls timeBeginPeriod to enhance system timer resolution. This improves the quality of vertical sync, but consumes slightly more processing time. Both parameters attempt to synchronize vertically.On a sidenote, why are you using 60 Hz as a monitor refresh rate? That's murder [smile]   ;Quote:Original post by ThorgrimOn my Radeon 9600xt It defaults to One, I'll have to test it out on my NVidia card and see what happens. However I'm using MDX 1.0.2902 so maybe its a MDX 2.0 problem.  In any case, why not just use Immediate?  It's much more useful so you can gauge performance etc.Thanks for checking this out. I'm also using MDX1.0, but from Sirob's reply I gather it's an issue on both platforms. I already went for immediate, seems the best choice indeed.Quote:...On a sidenote, why are you using 60 Hz as a monitor refresh rate? That's murderAnd thanks for pointing this out too, guess I stopped reading too soon [smile]As for my refresh rate, it's the only rate my Dell FlatPanel supports at 1280x1024, so sue them for accessoiry to murder :p From what I read the refresh rate shouldn't matter too much for LCD's though and it's pleasant enough to work with (not to mention for Oblivion l00tness [wink]).   ;  Well, it seems the issue has been resolved, but I said I'd do it, so here it is:ATI Radeon X550PresentInterval.Default - Avg. 60 fpsPresentInterval.One - Avg. 79 fpsPresentInterval.Immediate - Avg. 3135 fpsProbably doesn't help much except to reinforce the previously made point [smile]-AJ   ;  You should allow the user to select the update interval. At least the following options are recommended:V-Sync Off =  immediateV-Sync On = oneV-Sync + Triple buffer = one + back buffer count = 2The reason for this is that some people are very sensitive to the tearing that the V-Sync Off mode caused. They need V-Sync On. Unfortunately if the GPU can’t reach the display frequency it will drop to the half, third and so on. Y-Sync + triple Buffer solve this but consume more video memory.  