295 replies to this topic

[Goose]

Goose, on 21 December 2014 - 04:15 PM, said:

How do you play this thread, again?

Do I got'a go over my thing about setting sys_MaxFPS, again?



DSR is a Harsh Mistress

---

New River in LowLight







The one time I thought to screen cap it was during this set (sorry)

---

New River in Broad Daylight

---

New Acid Bath in … Broad Daylight

---

Sad HPG in Vacuum





HPG is not hard

[Goose]

[Demoman]So[/Demoman]

I've been derping around with AA: I like DSR quite a bit, but more then a bump or two, and you can't read a damn thing in the front end, and picking your smoothness seems to be about finding a livable compromise, instead of finding "just right."

I've seen that I can't run my one card at max DSR of 3600 x 2880: It's pegged. If I remove

q_ShaderWater = 0
r_FogShadows = 0
r_fogShadowsWater = 0
r_silhouettePOM = 0
r_UsePOM = 0

then 3118 x 2494 is also out of reach.

Or was it 2700 x 2160: Too Damn Small to Read …

I did find out I'd heard wrong about how to use MultiFrame Sampled: To get MSAA 4x at reduced effort, you need to set

r_MSAA_quality = 0
r_MSAA_samples = 2

where as without those strings, you'd get MSAA 8x, at a GPU load of a bit more then the 4x none of us can use. Ether way, you need to reduce your Shaders slider to keep from red-lining your card in the Training Grounds.

Also: You have to be a Block II Maxwell; The GTX 750 twins don't have access to it. I can ask my GTX 650Ti for DSR …

Anyways: I've dropped my resolution to 2204 x 1764 for readability.

That I seem to have gotten away with bumping up my Particles is perplexing: Wasn't that bottle-necked by the CPU?

---

New River Dusk

---

New Forrest Day

[xWiredx]

Promising results. Maybe now that I'm on Win10 FRAPS will behave again and I can run some 64-bit tests on my machine. To be continued...

[Goose]

Goose, on 30 October 2015 - 06:01 PM, said:

I did find out I'd heard wrong about how to use MultiFrame Sampled: To get MSAA 4x at reduced effort, you need to set

r_MSAA_quality = 0
r_MSAA_samples = 2

Set in-game to TXAA, combined with the above, and you get … Something kind'a nice, but with a GPU load up in the 90s, in a real match, and SMAA via ReShade actively backfires upon.

I've never actually searched for a correlation between GPU loads in-game and TrainingTesting Grounds: I have this ballpark number of ~70% load in Teh Grounds that should keep the card from redlining in-game for about two standard deviations of crap-in-flight, without things looking sub-par. But this is my chief reason for wanting a benchmark …

Yes: Trying to figure out what everyone else was talking about with the ScaleForm/ No HUD Thing was the only time I test without a framerate limit set, ever …

No: The extra load from River City Tunnel doesn't count towards anything …

[Flapdrol]

Swapped out the pentium for a used 4670K, seems to handle the particles of exploding mechs slightly better, maybe? Maybe a bit smoother?

Not that much of a difference to be honest, but I now have 4 cores showing 45-50% average load instead of 2 cores near 100%.

hope my 30 euro H81 board doesn't explode

Edited by Flapdrol, 04 November 2015 - 03:05 PM.

[Goose]

And now for something whole expected





Moar River City, as I still think it the hardest map.

I'd noticed Core 5 had a secondary load in my recent tests, which got me thinking: What was that 22DEC2014 patch that made the AMD FX users so happy? I just sort'a derp'd between then'n now, not doing much testing 'till I got this new video card. I rem'd out my old set of thread placements and did a couple of tests, but the problem becomes "what's where in the first place," 'cause when Teh Devs move them, it means the .docs I'd used as a baseline becomes obsolete: I'd never had a direct way of telling what was on a given core.

Anyways: I'm now moving sys_physics_CPU, sys_streaming_CPU, and both of sys_TaskThread1_CPU and 3; As I'm a hexacore, it's much easier for me to see loads get moved then it would be on a quad, and I believe it took all four moves to stop Core 5 from showing a load on it's Hyperthread … But I should go back and double-check if each was necessary.

I can also say "Moving sys_main_CPU onto 0 is bad, 'cause r_WaterUpdateThread is already there." It doesn't make a lick of sense, but Main and Water on the same core made any map stumble around badly when I was testing over a year ago. Main is on zero in the .docs I have, and Water is supposed to be up on five …

Why this "Main hates Water" thing doesn't render dual-cores unplayable is a mystery to me: Even if there's a third setting I've put in causing it, thus making this train-wreak myself, I put such settings into my other, smaller, test boxes, too, which don't show the issue …

At any rate, someone with a quad core should move those four strings someplace not one, as that's where "core 5" settings roll over to on a quad, and now get to test moving the remaining threads (other then immovable "ca_thread0Affinity," and "ca_thread1Affinity" which still seems to be on four) to see what's the … "best ratio of Core One load to GPU load/ FPS" seems the best way to phrase it.

---

I've found the *****† for Temporal AA … But "promising" is not how I'd describe the results.

r_AntialiasingTAAMode = 4
r_PostMSAAEdgeFilterNV = 0
r_MotionBlurAdaptiveSampling = 0
r_MotionBlurFrameTimeScale = 0
r_MotionBlurShutterSpeed = 140
;r_MotionBlurThreshold = 0.0001
;r_MotionBlurThreshold = 1000
r_AntialiasingTAASharpening = 0
r_MotionBlurMaxViewDist = 8000
r_AntialiasingTAAFalloffHiFreq = 12
r_AntialiasingTAAFalloffLowFreq = 1.5

I'm working up the theory "FalloffLowFreq" is the second most important setting to making viewed 'Mechs not schmear badly, but as you move it from it's default "2" you change the shimmer in low contrast terrain, like the paint on the roads, or the expantion joints on the bridges, of New River. FalloffHiFreq works on over half the terrain you see (on River, anyways) and not your own 'Mech (I test by going 3rd person, see.) If you jack ether or both of these numbers, you should set Sharpening to zero, as it seem to add stroobing to things I was trying to get calmed down. But it's not so bad if you leave both Freqs' alone …

Most important is ShutterSpeed: It's default is 13, as in 1/13th of a second. I say jack this to at lest your framerate limit, and maybe twice as much. I should think setting it to 200 or so would be pointless: 200 is the minimum to freeze-frame in photography, and thus you may as well turn off Temporal at that point. Testing on the two smaller boxes of mine, with FPS limits of 42, seem to take ShutterSpeed 42 very well, and better then the big box liked 70. I don't get it, ether … But you get to spend hours testing for a number you think works most often, as refresh, framerate limit, spead of 'Mech invovled, distance to screen, time of day on the maps that change it, all take turns complaining about something Temporal is doing.

Mode 4 says something about being 8x Sparse Grid: I should really be checking if the GPU Core loads are changing with this junk.

TimeScale seems to overwrite your settings with something close to the defaults, which we all already carp about; I can't make heads nor tails of Threshold, so I'm leaving it; I turned off Sampling very early in my tests, and should go back to it, someday …

---

Still using ReShade for SMAA (love what it does to a Spiders' cockpit,) and two "bumps" of DSR (plus 33% Smoothness), as well as being mostly Very High in-game.

---

I have gotten turned around as to what the internal FXAA option is: It looks as good in a Spider cockpit as SMAA, but since FXAA is also supposed to be a part of default PostAA, why does that look so much worse on a static image?



































† Ya Rly

Edited by Goose, 28 November 2015 - 09:17 AM.

[darqsyde]

Posted elsewhere, thought it should go in here as well.

4790K@4.4
7870 @1050/5GHz
16G RAM

1080p, Motion Blur Low, No AA, Full Window.
Crimson 15.11.1, FRTC 60

Edited by darqsyde, 06 December 2015 - 10:52 AM.

[Goose]

Right: Teh Secret AMD Build







Don't have the controls on this box to take it into combat, but doing laps of New River in a Crab is worth something, if you accept my theory 'bout "GPU load of ~70%, with any FPS limit you care to name." The hodos' are the New River Tunnel, which has loaded up a card since the word "go" …

If we treat a FX like a Hyperthreaded Intel, and thread placements just roll over when you run out'a cores, then big-bad ca_thread0Affinity is on core(s) #2/ 3 … Which show the second lightest load(s) here …

[Goose]

Once more with Teh Secret AMD Box









Well: Turning off the Frame Pacing thingie in the ATI driver seems to have worked better then just adjusting it's slider without restarting the game, or without rebooting.

But those loads: Not what I was expecting.

The last two cores should be loaded with ca_thread1Affinity, the other render-er, and I've seen that get more busy then it's big brother when in the Testing Grounds: Here, it's just asleep.

I will say I think the GPU load is too damn high for not really being in-game.

What is this fool box?



And a Radeon 7850 of no small water …

[Goose]

Goose, on 26 December 2014 - 07:49 AM, said:

Not sys_main_CPU: ca_thread0Affinity … Until I get a'lot moar testing done under this "22DEC2014 Octacore Patch" …

I said what, when?

[demoman]SO:[/demoman]

I got the clue the 22DEC2014 patch reshuffled the threads a month or two ago, when I upgraded my video card, and noticed a secondary load on Core 5, even though I'd gone out'a my way to give ca_thread0Affinity that core all to itself. A quick'n dirty set of tests led me to

sys_main_CPU = 1
sys_physics_CPU = 1
sys_streaming_CPU = 0
sys_TaskThread1_CPU = 1
sys_TaskThread3_CPU = 0

for my Intel hexacore.

Not that this set does anything for quadcores: ca_thread0Affinity wraps around onto Core 1 on such CPUs, so three of those strings don't actually do anything in such a case.

But now I think I've got something for y'all:

sys_streaming_CPU = 0
sys_TaskThread3_CPU = 0
sys_physics_CPU = 3
sys_TaskThread1_CPU = 2
 
sys_TaskThread0_CPU = 3
sys_TaskThread5_CPU = 2
 
sys_main_CPU = 3
sys_TaskThread4_CPU = 3

should move everybody off of Core 1 that can.

This is not a well-developed set: The Hard and Fast rules of "0Affinity alone" and "Main and Water must be separated" are met, but, in theory, the better the rest are sorted, the less MHz your CPU needs, down to whatever it is 0Affinity demands …

It could be Main and Task4 don't need moving …

To rephrase it, these moves should yield

;0 = water, streaming, task2, task3
;1 = ca0
;2 = main, task5, task1
;3 = ca1, physics, task4, task0

which should be unbad for quads.

I still don't know how all these task theads interact with "sys_job_system_max_worker" (or even "sys_job_system_enable"), or why Task2 and Task4 seemed special (before 22DEC2014, they were given cores all to themselves, and seemed petty busy,) or even why dualcores don't just train-wreak out of hand (Main and Water not mixing is kind'a big deal,) but this should be enough to get everyone going in the right direction … so the can report back.

Or maybe Teh Devs will chime in with something useful …

[xWiredx]

Goose, on 19 December 2015 - 11:51 AM, said:

Devs will chime in with something useful …

Wishful thinking.

So I have a very small amount of time during this weekend's event where I can test this (assuming FRAPS decides to cooperate, I am loathe to begin reinstalling all this logging crap tbh). I will be running the same mech the entire time, so at least there's one less variable. I'll keep my same 180 seconds of testing format as way back when. Again, assuming everything cooperates.

[xWiredx]

HUD on vs HUD off (and yes, 64-bit is finally cooperating!)

Test scenario: MAD-BH2 walkthrough killing Atlas, Jenner, Catapult, Cicada, and firing on Commando. Time: 180 seconds. Testing grounds location: Tourmaline. All graphics settings: very high. Hardware: in signature

HUD on: Min - 113, Max - 201, Avg - 154.544
HUD off: Min - 91, Max - 207, Avg - 157.311

As you can see, turning the HUD off on a modern high-end gaming system results in at maximum a 6fps difference, and on average about a 3fps difference. Mileage may vary if you have lesser hardware, and you should strongly consider turning down the following settings: particles, environment, shadows. Less draw calls makes for a happier CPU in a DX11 world.

I will post some match numbers a bit later. I just ran through 4 matches with no CPU mods in the user.cfg. About to pop those in to see if there's any real tangible benefit.

[NocturnalBeast]

I will make this easy guys, just buy the newest Nvidia card that you can and buy the fastest, multi-core Intel processor and fastest internet that you can get (hard-wired to the modem through LAN) and the game will run fine!

[Oderint dum Metuant]

Ed Steele, on 19 December 2015 - 06:08 PM, said:

I will make this easy guys, just buy the newest Nvidia card that you can and buy the fastest, multi-core Intel processor and fastest internet that you can get (hard-wired to the modem through LAN) and the game will run fine!

I think you missed the point of the thread.

[xWiredx]

Goose, gonna hafta say that the CPU assignments are more snake oil than anything for me and my hexacore:



Still, between the last time I had real numbers from testing in March and this latest patch, I think I've gained a little bit of performance. The only ones I can specifically nail down are these:

Canyon Network: 50% higher max FPS, 10% higher avg FPS
HPG Manifold: 10% higher max FPS, 10% higher avg FPS
Frozen City Night: 5% higher max FPS, 15% higher avg FPS

That 64-bit switchover and other subsequent performance enhancements have been pretty decent for me. AMD users are probably about 5-10% better off now than they were at the beginning of the year. Skylake users are probably -really- happy with their systems.

I think another thing we can deduce here is that the newer maps with the nicer textures, more geometry, and destructible bits do seem to incur a somewhat decent performance hit compared to our first run of maps (and not by just a little bit, probably between 10-20% for most people). This was something I was worried about, and now I'm pretty sure that worry is warranted.

[NocturnalBeast]

xWiredx, on 19 December 2015 - 04:33 PM, said:

HUD on vs HUD off (and yes, 64-bit is finally cooperating!)

Test scenario: MAD-BH2 walkthrough killing Atlas, Jenner, Catapult, Cicada, and firing on Commando. Time: 180 seconds. Testing grounds location: Tourmaline. All graphics settings: very high. Hardware: in signature

HUD on: Min - 113, Max - 201, Avg - 154.544
HUD off: Min - 91, Max - 207, Avg - 157.311

As you can see, turning the HUD off on a modern high-end gaming system results in at maximum a 6fps difference, and on average about a 3fps difference. Mileage may vary if you have lesser hardware, and you should strongly consider turning down the following settings: particles, environment, shadows. Less draw calls makes for a happier CPU in a DX11 world.

I will post some match numbers a bit later. I just ran through 4 matches with no CPU mods in the user.cfg. About to pop those in to see if there's any real tangible benefit.

Since the MWO HUD uses Scaleform, I have gotten a slight fps boost by Adobe Flash hardware acceleration off (have to do that through your browser).

[xWiredx]

Ed Steele, on 20 December 2015 - 11:10 AM, said:

Since the MWO HUD uses Scaleform, I have gotten a slight fps boost by Adobe Flash hardware acceleration off (have to do that through your browser).

Actually... that does seem to slightly help. I didn't notice any real difference visually or anything, but the numbers seem to point in a positive direction when turning HW acceleration off for Flash. It seems to give better avg FPS than when turning the HUD off, though the mins really don't move in a meaningful way. This suggests that things are slightly more stable. Overall, the percentage increase in avg FPS is small, but this is probably something we can recommend (especially to AMD users) going forward.

HUD on: Min - 113, Max - 201, Avg - 154
HUD off: Min - 91, Max - 207, Avg - 157
HW Accel off: Min - 111, Max - 199, Avg - 160

Edited by xWiredx, 20 December 2015 - 12:11 PM.

[Goose]

xWiredx, on 19 December 2015 - 11:38 PM, said:

Goose, gonna hafta say that the CPU assignments are more snake oil than anything for me and my hexacore:

Haswell-E @ 4.3, right?

I should think theres' a critical mass of Hz and IPC where nuance like getting 0Affinity alone ceases to matter, but not everyone can get there …

[xWiredx]

Actually, I just went to confirm that and apparently I had reset something somewhere. Only gets to 3.8GhZ when I run something CPU intensive. Looks like PGI might have made more of an improvement than I thought? I'll have to go and fiddle with my BIOS settings again... Was at 4.3 I think for testing in March. Was at 4.46 for a decent while, though.

[Goose]

xWiredx, on 20 December 2015 - 01:26 PM, said:

Actually, I just went to confirm that and apparently I had reset something somewhere. … Looks like PGI might have made more of an improvement than I thought?

That seems to be the "problem:" 22DEC2014 came though, and while "all" the AMD FX guys did a happy-dance, us well-clocked Intel types just sort'a nodded like Mussolini, which is to say "we derp'd" …

Edited by Goose, 01 January 2016 - 09:25 AM.