Jump to content
  • Advertisement
Hexaa

DX11 Performance Issue DirectX Maximized Window

Recommended Posts

I develop a test application with directx 11 und fl 10.1. Everything is working as expected and fine, but when I maximize the window with my graphics in it, the time per frame increases drastically. like 1ms to 40ms. If it stays at a lower resolution range, it works perfectly. But i need to support it in the maximized resolution also.

Destination hardware and software specs:

  • NVS 300 graphics card
  • Windows 7 32-bit
  • resolution 1920x1080
  • Application that draws few sinuses with direct3d, c# via sharpdx
  • Windows forms with a control and sharpdx initialized swapchain, programmed to change backbuffer on resize event (would occur without that too though)
  • I used a System.Stopwatch to find the issue at the code line: mSwapChain.Present(1, PresentFlags.None); where the time it needs when maximized increases by a lot suddenly.

If i drag and resize it manually at some resolution the frame time jumps, seems weird.

If i comment out the drawing code, I get the same behavior. On my local development machine with a HD4400 i don't have this issue though, there it works and the frame time isn't affected by resizing at all.

Any help is appreciated !

I am farily new to programming in c#, windows and with DirectX also, so please be kind:P

Share this post


Link to post
Share on other sites
Advertisement

I can buy an NVS 300 for US$6 now and is an architecture from 2008 - not exactly a powerhouse :) First instinct is to simply blame that hardware.

What resolution in windowed mode runs at 1ms, compared to the 40ms of 1080p? Is there any in-between performance levels -- e.g. a certain resolution where it takes 10ms per frame?

Share this post


Link to post
Share on other sites
40 minutes ago, Hodgman said:

I can buy an NVS 300 for US$6 now and is an architecture from 2008 - not exactly a powerhouse  First instinct is to simply blame that hardware.

What resolution in windowed mode runs at 1ms, compared to the 40ms of 1080p? Is there any in-between performance levels -- e.g. a certain resolution where it takes 10ms per frame?

Haha yes it's pretty old hardware now, it is mandatory to support it though sadly :/

Okay I had present sync interval set to 1 so it's more like a jump from ~16ms to 40ms, but you know.

If i set it to sync interval 0 and change the creation of the graph window to like 1600x900 i get all my expected 2-3ms if not lower, even on that old hardware. I mean i can completely comment out my drawing and still, if i drag it to a certain resolution (from 1600x900 close to the resolution of maximum) it jumps from that 2-3ms to ~40ms. Staying in that resolution range isn't an option either though. There isn't any level in that, certain resolution and immidiate increase. It is not fullscreen and there is also a control panel on one side, so even in maximized it wont reach 1920x1080.

It's confusing me a lot. I read about present() can block if frames are queued, i know to little about that though to say if that is the issue, it is called in an idle loop, so that might hint to that though. But again, can the gpu performance suffer so much at a tiny resolution increase, if i drag it higher.

thanks for help :)

Share this post


Link to post
Share on other sites

Yeah it's certainly odd. That card is supposed to support high resolution multi-monitor output and hundreds of megs of texture data, so a single ~8MB texture (1920*1080*4B) should be fine, so your "no drawing" situation should have no reason for this performance issue...

I have seen random ~40ms stalls on the GPU side when video memory is over-comitted (e.g. trying to use 1.1GB of texture data on a 1GB GPU), as this causes the driver to panic half way through a frame and shuffle lots of resources around... but... if you're not actually drawing anything, this shouldn't be happening to you.

Present is where the CPU will block if it's getting too far ahead of the GPU. e.g. if the CPU does 1ms of work per frame and the GPU is doing 16ms of work per frame, then you should expect to see the CPU block inside Present for 15ms.

It's a bit complicated, but you can use the GPUView tool to inspect exactly what the GPU is doing at every point in time here and try to identify the stall.

Share this post


Link to post
Share on other sites

Okay i'm trying to installing it now. Hopefully it can help me, thanks. I will report back if i have trouble or find something issue with it.

thanks so far

Share this post


Link to post
Share on other sites

Solved by disabling Aero Theme... Noticed the performance suffers a lot if the window gets over the start button. Switched to windows classic theme for test and worked. Still learned something with this tool you showed me at least, so thanks :) day saved

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!