poor FPS, Swap_Buffers and mat_viewportscale

[spongman]

I’m getting much lower FPS than I would expect at higher resolutions (1920x1200).

showbudget was showing that most of the time was spent in Swap_Buffers:

however, i noticed that the Swap_Buffers was significantly reduced, if i set mat_viewportscale 0.99999 :

obviously the number of pixels being drawn isn’t significantly different. can anyone explain what’s going on here?

it would seem to indicate something weird in the fragment shaders. is there something in there that’s disabled by having a non-1 viewport scale?

here’s my sysinfo:

Processor Information:
    Vendor:  GenuineIntel
    Speed: 2671 Mhz
    4 logical processors
    4 physical processors
    HyperThreading:  Unsupported
    FCMOV:  Supported
    SSE2:  Supported
    SSE3:  Supported
    SSSE3:  Supported
    SSE4a:  Unsupported
    SSE41:  Unsupported
    SSE42:  Unsupported

Operating System Version:
    Windows 7 (64 bit)
    NTFS:  Supported
    Crypto Provider Codes:  Supported 323 0x0 0x0 0x0
    
Video Card:
    Driver:  NVIDIA GeForce GT 520 

    DirectX Driver Name:  nvd3dum.dll
    Driver Version:  9.18.13.623
    DirectX Driver Version:  9.18.13.623
    Driver Date: 30 Aug 2012
    Desktop Color Depth: 32 bits per pixel
    Monitor Refresh Rate: 59 Hz
    DirectX Card: NVIDIA GeForce GT 520 
    VendorID:  0x10de
    DeviceID:  0x1040
    Number of Monitors:  2
    Number of Logical Video Cards:  2
    No SLI or Crossfire Detected
    Primary Display Resolution:  1920 x 1200
    Desktop Resolution: 3840 x 1200
    Primary Display Size: 26.65" x 16.65"  (31.42" diag)
                                            67.7cm x 42.3cm  (79.8cm diag)
    Primary Bus: PCI Express 16x
    Primary VRAM: 1023 MB
    Supported MSAA Modes:  2x 4x 8x 
    
Sound card:
    Audio device: Speakers (Realtek High Definiti
    
Memory:
    RAM:  8191 Mb
    
Miscellaneous:
    UI Language:  English
    Microphone:  Not set
    Media Type:  DVD
    Total Hard Disk Space Available:  5246124 Mb
    Largest Free Hard Disk Block:  1400325 Mb
    OS Install Date: Dec 31 1969
    Game Controller: None detected

[lexa2]

Pretty strange bug really. You’re right that you most likely hitting fillrate shortage due to some pixel shader eating up all of it. It might be a problem with of the fullscreen post-processing shaders. What could you do is to turn off HUD and chromatic postprocessing in the game settings menu and try using one of the methods to disable noise postprocessing shader described here:

https://forums.blackmesasource.com/showthread.php?p=502093#post502093

What else would be interesting is try changing dxlevel used from what you use to other among 90, 95 and 98. Then, checking what’s displayed with mat_fillrate 1 might give and insight on what is wrong here.

What else? Hmm, maybe check for overdraw-related problems, there was a cvar for that. Use “find overdraw” in console, it’d be easy to determine which one is correct to use.

[spongman]

ok, super weird stuff going on.

first up, i’m running win7 x64, up-to-date everything, dx11 hardware.

• I have all the perf/video settings set to disabled/low
• I tried removing the .vcs files, no fix
• I tried removing game_shader_dx9.dll, no fix
• I tried mat_fillrate 1. i couldn’t see any difference between the two mat_viewportscale values, except the fps, of course.
• I tried the overdraw thing, it showed overdraw around the lights. again, no visible difference between the two mat_viewportscale values.
• apparently, the game is detecting dxlevel ‘95’. i tried adding ‘-dxlevel 98’ to the startup parameters. after starting bms, the screen resolution and video settings were reset, so i changed them back to 1920x1200, disabled/low, etc… after that the rendering was really weird. the letters of the main menu had black boxes around them, as if alpha-blending was broken. the red background of the ‘showbudget’ display was all messed up, almost as if the vertex buffer was being overwritten by some other data:
  
  

the weird thing is that the difference in the number of pixels drawn between mat_viewportscale 1 and mat_viewportscale 0.99999 is tiny (around .1%) but the fps difference is huge.

the fps seems to vary almost linearly for other values of mat_viewportscale, but at ‘1’ it hits a cliff. there’s some inneficiency that’s triggered when it’s set to 1.

[lexa2]

@spongman

first up, i’m running win7 x64, up-to-date everything, dx11 hardware.

Yep, I’ve seen details on your hardware in the first post of the thread thus I had also been surprised but the stuff that’s going on.

@spongman

[*]apparently, the game is detecting dxlevel ‘95’. i tried adding ‘-dxlevel 98’ to the startup parameters. after starting bms, the screen resolution and video settings were reset, so i changed them back to 1920x1200, disabled/low, etc… after that the rendering was really weird. the letters of the main menu had black boxes around them, as if alpha-blending was broken. the red background of the ‘showbudget’ display was all messed up, almost as if the vertex buffer was being overwritten by some other data:
bm_c1a3b0003.jpg
[/LIST]

You had restarted the game after changing the resolution and gfx settings, hadn’t you? I’ve seen similar problems on my rig while been messing with different resolutions, switching fullscreen/windowed, e.t.c. After changing two or three different settings pressing “Apply” after each I end up with messed up rendering that been looking similar to what could be seen on your screenshot. Quiting the game and starting it up again fixed the problem.

@spongman

the weird thing is that the difference in the number of pixels drawn between mat_viewportscale 1 and mat_viewportscale 0.99999 is tiny (around .1%) but the fps difference is huge.

the fps seems to vary almost linearly for other values of mat_viewportscale, but at ‘1’ it hits a cliff. there’s some inneficiency that’s triggered when it’s set to 1.

Yes, linear FPS scale with the vieportscale changes is something that is expected to get in as long as FPS is fillrate-capped. Having sudden drop when it is set to 1 is a really strange thing. The only possible reason I could think of in case it’s not a fullscreen post-processing shaders kicking-in and behaving wrong (which seems not to be the case as you tried to de-facto turn them off by removing shader dll and things hadn’t get better) are:

a) Driver-related problem. There are a lot of things nVIDIA drivers do “behind the scenes” and some execution paths could only kick in if the size of the offscreen render buffer matches the resolution of current d3d swapchain. I’ve seen some signs of similar behavior with OpenGL when been implementing a small app to test Adaptive/Standard vsync behavior in the dual display environment for nVIDIA cards. It might be that driver does something strange/wrong and causes FPS drop you observe. There are no obvious ways to check it except for trying downgrading or upgrading driver version in hopes that the problem would disappear. Also it’s worth checking if you get the same drop in windowed mode.

b) Problem inducted by some third-party software messing up with the game’s render context. MSI Afterburner, Steam Community in-game, recording tools like xsplit, FRAPS or DXtory - all they could possibly cause problems like this. But I have to admit I had never hit anything like the problem you describe caused by any of the tools listed above.

[spongman]

@lexa2

You had restarted the game after changing the resolution and gfx settings, hadn’t you?

yeah, i did have the kinds off issues you described with settings not sticking initially, but i did restart after setting them, just to make sure. i also tried different combinations of .vcs/.dll presence, to no avail.

@lexa2

Yes, linear FPS scale with the vieportscale changes is something that is expected to get in as long as FPS is fillrate-capped. Having sudden drop when it is set to 1 is a really strange thing. The only possible reason I could think of in case it’s not a fullscreen post-processing shaders kicking-in and behaving wrong (which seems not to be the case as you tried to de-facto turn them off by removing shader dll and things hadn’t get better) are:

a) Driver-related problem. There are a lot of things nVIDIA drivers do “behind the scenes” and some execution paths could only kick in if the size of the offscreen render buffer matches the resolution of current d3d swapchain. I’ve seen some signs of similar behavior with OpenGL when been implementing a small app to test Adaptive/Standard vsync behavior in the dual display environment for nVIDIA cards. It might be that driver does something strange/wrong and causes FPS drop you observe. There are no obvious ways to check it except for trying downgrading or upgrading driver version in hopes that the problem would disappear. Also it’s worth checking if you get the same drop in windowed mode.

I was running an older nvidia driver when i first saw this problem. i forget which version, but i upgraded to the latest in the hopes of finding a fix

@lexa2

b) Problem inducted by some third-party software messing up with the game’s render context. MSI Afterburner, Steam Community in-game, recording tools like xsplit, FRAPS or DXtory - all they could possibly cause problems like this. But I have to admit I had never hit anything like the problem you describe caused by any of the tools listed above.

i don’t have any of those installed, and i don’t have anything installed that i think would mess with it. regardless, i’m not sure what would be sensitive to the viewscale value…

anyway, i loaded the two screenshots above into photoshop, re-scaled them to account for the viewscale change, and took the difference

it does look like there’s some slight difference in the shadows (although i didn’t change any setting other than the viewscale).

[lexa2]

@spongman

…
anyway, i loaded the two screenshots above into photoshop, re-scaled them to account for the viewscale change, and took the difference
diff.jpg
it does look like there’s some slight difference in the shadows (although i didn’t change any setting other than the viewscale).

Hmm, differences look like there’s a some kind of an ambient occlusion kicking in (you could easily see that the lighting differs at the places that are expected to be affected by radiosity simulation done in the AO simulating pixel shader).

This theory is pretty much in line with the FPS drop you’re facing as it is a known fact that driver-forced AO for nVIDIA cards only works in case you have offscreen backbuffer the same size as your screen resolution is (check investigations done by DSfix author on this topic if you’re interested in the gory details from the programmers PoV).

Check your nVIDIA driver setting. Make sure you have AO disabled. You could also try installing nVIDIA Inspector and using it to force AO disabled for hl2.exe profile.

[spongman]

@lexa2

Hmm, differences look like there’s a some kind of an ambient occlusion kicking in…

that was it!

i force-disabled ambient occlusion in the nvidia driver and now there’s no difference between mat_viewportscale 0.99999 & 1.

you the man

[lexa2]

Good to hear you resolved this one. You’re welcome.
Please, add “[SOLVED]” to the thread title if you have such possibility. If not - friendly moderators, could you please help this thread with being marked as solved? Thanks in advance.