295 replies to this topic

[xWiredx]

Hmm... actually the BIOS says 4.5GhZ (4502, to be exact). Think the monitoring software and Windows 10 are fighting. So I'm at 4.5 during these tests. So getting ~10-15% more performance out of a system with 5% higher clocks is still something, and turning off Flash hardware acceleration is still good (better than no HUD, even). For Hexacore and Octocore users, CPU thread assignments are ineffective, but for people with quads and lower they are probably worth something. Good summary?

[Goose]

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

… and turning off Flash hardware acceleration is still good (better than no HUD, even).

I'd decided that was snake oil, myself, as I'd only ever see ~5 frames difference, but I'm always on Teh Beta, not that anyone has come out and said "Scaleform grabs the local copy of Flash."

Guess I need to try again …

Oh: A Gulftown @ 4.26GHz still doesn't like 0Affinity to be crowded …

[Goose]

Snake Oil: Starring north, with nose into the rocks, a C4 of New River

Accel off
hud = 111
hud off = 117
Accel on
hud = 113
hud off = 119

[xWiredx]

Huh. Go figure.Then again, one could postulate that your CPU's weaker IPC compared to mine means your gains won't be as big. It definitely could be snake oil, though.

Maybe we should comprehensively test. Like... 4 runs, 2 on new maps and 2 on old maps, and use the same maps for both my tests and yours? I'd prefer to keep to 60-180 seconds. I mean, really when it comes down to it our numbers are just rough sketches that show a trend, but nothing concrete. Lots of variables.

River City, Forest Colony, Tourmaline, and Canyon Network? We could easily outline a path to take and all that.

[Goose]

I thought the Flash Gag was tuning it off had a benefit?

I still like to run clockwise laps around the New River Bridges …

[Goose]

(A SMRT Guy™ would'a done this by now) Do we have any idea what are the hard and easy views in the game? I have my thing about "New River Testing, C4, 00°" as easy, and this one spot in the Academy as bad, but it's not like I've done a proper survey: Anybody have anything for me?

Also: We wann'a do this in framerate, or GPU Load? I vote the later, as I recommend a framerate limit to all …

[xWiredx]

Hmm... that is a good question.

I do know that when you are dropped in from a dropship the fps tanks, but I don't think we get that satisfaction with the testing grounds, do we? I haven't looked at the new maps or CW maps in the testing grounds.

Maybe I'll just go on a walk-through of some of these.

I don't use a framerate limit and am less CPU-bound than many. Limiting fps makes it harder to actually judge how easy or hard to render a specific view is, since if its really easy you'll never see the fps shoot up. Averages are also skewed by caps. Watching GPU load might help you find how CPU-bound you are, but it won't tell you as much about how your GPU is handling it since if the CPU limitation is removed the GPU will just spike to as high as it can all the time (again, unless fps is capped, which limits data even further).

Another aspect we need to consider is the mech's speed and if moving much faster has an effect on overall performance. I think we might actually see a small impact, but nothing too substantial.

I guess it's really no wonder why PGI doesn't do this testing and just blanket recommends something that we know isn't going to be entirely satisfactory to many gamers.

[Goose]

Setting a limit brings up minimums, which seems moar useful to the most people. I'd heard early on it'd help me, with my then-smaller build, and testing like I play always made sense to me.

It also reinforces how you shouldn't just look at fps: Where the bogus River City Tunnel spike would obviously lower fps sans limiter, I can say both GPU load and GPU FB/ Memory Controller in lock-step, 'cause I'd though to look, what with my limiter; That both Shadows and Object Detail effect the size of the spike might not have been so obvious, ether now on a GTX 980Ti, nor then, on a GTX 770 …

It's also the kissing-cousin, in my mind, to the thing about setting "Prefer Max Power" in the nVidia Control Panel: A couple of times the card down-clocked without frames dropping below 42, which I interpret as settings are too low.

But I digress …

[xWiredx]

I have no problem testing both ways if I have the time, honestly.

[Goose]

Might big "if" you have, there …

[Goose]

[confusing set of excuses]

Right.

I've found a string that helps greatly with pop-in: e_LodCompMaxSize has a default of six, but if you jack it into the high teens … You get a new set of pretty good problems to have. Set to nineteen, you can stand on the bridge of E6 River City and look up at the buildings facing the water in C4 and seem them filled in. But that level of detail at that range means shimmer, and you can see how shadows aren't being applied (until ~160m,) and then you get on Polar and the framerate takes quite a hit. I'm in the process of walking this number down: I'll let you know …

Polar @ e_LodCompMaxSize = 19:





You can see the un-smooth transition in time of day, there at ~ 3:25 …

---

Note the load on Core 0: That's got'a be Task2, as I don't see Water being important on Polar. Teh default listings for both Task2 and Task4 seemed to make them out as special, and I've embraced it as a form of short-cut in this development work: This would seem to validate that gambit.

I do think I'll move Task0 from 3 down to 2 …

---

I keep using SMAA via ReShade: It always does something, but liking is occasionally an problem. It took a while to find something outside the cockpit it was effecting, suggesting it's more trouble then it's worth; And there's this weird stretch of time when it didn't seem to be getting along with TXAA. But that's over, and it still makes the cockpit frames look awesome …

There's this note, line 338 of the actual SMAA.h file, about dropping the SMAA_THRESHOLD all the way down to 0.2 when used with Temporal, so I'm now doing that.

ReShade has a way to test if you have access to the depth buffer, which seems an issue if the game in question gives a turkey 'bout anti-cheat at all: Only with this have I gotten though my head SMAA Prediction is something you just turn off, and also SMAA_EDGE_DETECTION should not be set to 3, ever.

You'll also want to set "sys_flash_edgeaa = 0" in the user.cfg if you start injecting AA …

---

r_AntialiasingTAAMode = 4
r_MotionBlurMaxViewDist = 4000
r_MotionBlurQuality = 2
r_MotionBlurShutterSpeed = X

seems to be mandatory strings for using the two Temporal-related AA mode, TXAA and PostAA. I set "X" to equal my framerate limit; I'd guess 30 or 42 would make sense for potatoes, while the refresh for your monitor is the number for everyone else.

r_PostAAEdgeFilter = Y
r_PostMSAAEdgeFilterNV = Z

will also have to be addressed, as the default yields FXAA-SuperSchmear. If you want to inject SMAA, you need to set Y to 1 and Z to 0; Otherwise you don't even set a Y, and you pick between 2 or 3 for Z.

r_AntialiasingTAAFalloffHiFreq = A
r_AntialiasingTAAFalloffLowFreq = B

are the last two Temporal strings you might consider upping from the defaults (6 and 2, respectively,) and there are results to be had, but it's quite the time-sink to play with, and is a mouth-full to describe: First, it's much more noticeable under PostAA then TXAA; Jacking "HiFreq" will reduce shimmer for most of the world around you; Jacking "LowFreq" can effect the subtitle world shimmer, but will increase the schmear you see of other 'Mechs moving, of even yourself if you check in 3rd Person View. (See: Any given pixel of your 'Mech is painted just like itself from one frame to the next, ergo.)

There are a few more switches for Temporal, but I've only ever poked my eye out with them:

;r_AntialiasingTAASharpening =
;r_MotionBlurAdaptiveSampling =
;r_MotionBlurFrameTimeScale =
;r_MotionBlurThreshold =
;ca_MotionBlurMovementThreshold =
;cl_motionBlur =
;r_MotionBlur =
;r_MotionBlurThreshold =

are all Borrowing Trouble as far as I'm concerned.

I wish I could say I carefully studied what these do to a cards' load … But I didn't, and no-one on the planet can predict how a load "grows" as Hz and shader-count decreases across video cards.

Sorry …

---

So: I woun't call it a close second, but if you don't have access to TXAA, I think PostAA, with SMAA via ReShade isn't too bad. If you could add some DSR, or this "GeDoSaTo" thing I've heard of, it would be even better, but then you'd be talking about Real Video Cards.

I do prefer TXAA2x,with MFAA added from the nVidia driver, and then ether turn down the FAXX, or add SMAA via ReShade, once again.

But this last would require a GTX 9xomethingZero, and I don't know if a NineSeventy could pull it off, let alone a NineSixty …

[xWiredx]

Goose, on 28 February 2016 - 11:00 AM, said:

I've found a string that helps greatly with pop-in: e_LodCompMaxSize has a default of six, but if you jack it into the high teens … You get a new set of pretty good problems to have. Set to nineteen, you can stand on the bridge of E6 River City and look up at the buildings facing the water in C4 and seem them filled in. But that level of detail at that range means shimmer, and you can see how shadows aren't being applied (until ~160m,) and then you get on Polar and the framerate takes quite a hit. I'm in the process of walking this number down: I'll let you know …

So I didn't know about this cvar. That's interesting. More on that in a second.

Hadn't cleaned out the user.cfg in a while, and it needed to be done. Things like fov no longer need to be in there. Settled on this for now:

sys_TaskThread0_CPU = 0
sys_TaskThread1_CPU = 1
sys_TaskThread2_CPU = 2
sys_TaskThread3_CPU = 0
sys_TaskThread4_CPU = 3
sys_TaskThread5_CPU = 2

sys_main_CPU = 0
sys_physics_CPU = 3
sys_streaming_CPU = 1
e_ShadowsResScale = 4.0
e_TerrainTextureLodRatio = 3
e_CoverageBufferReproj = 1
e_TerrainTextureStreamingPoolItemsNum = 512
e_LodRatio = 40
e_ParticlesMinDrawPixels = 1.5
e_ParticlesMotionBlur = 0
e_ParticlesObjectCollisions = 1
e_CullVegActivation = 80
e_ParticlesEmitterPoolSize = 12288
e_ParticlesPoolSize = 24576
e_LodCompMaxSize = 16
r_HDRGrainAmount=0
r_DynTexAtlasCloudsMaxSize = 128
r_DynTexAtlasSpritesMaxSize = 256
r_EnvTexUpdateInterval = 0.025
r_VegetationSpritesTexRes = 256
r_UseParticlesHalfRes = 2
r_TexMinAnisotropy = 16
r_UseParticlesGlow = 0
r_WaterCausticsDistance = 250

This is mostly considered extra eye candy. So far, I've observed about 2.4GB of VRAM usage and 1.2GB of system RAM usage during a regular match. This drops to about 930MB VRAM / 900MB system RAM when I get back to the mech lab. So not much different, maybe about 200MB of VRAM heavier than past observances at the peak.

That cvar though... between that and a higher LODRatio value, I don't see much popping (if at all) anymore. I'm a very happy camper. Good find, Goose!

[Goose]

[mind explodes with a million things, again]

I just tried "e_ShadowsResScale = 11" and got nowhere: 4.0 does something?

r_radialBlur = 0
g_radialBlur = 0
e_ParticlesMotionBlur = 0

is my cure for the SRMs to teh Face slowdowns. I know it looks dumb, but I've seen both "g" and "r" versions across the 'net …

I'd read maxing out the Anisotropic filtering via the driver works better, so I'd zero out all the user.cfg versions. Maybe the guy whom suggested it didn't set all three?

r_TexMaxAnisotropy = 0
r_TexMinAnisotropy = 0
r_Texture_Anisotropic_Level = 0

What's e_ParticlesPoolSize do for you? I'd read setting to zero meant dynamic …

… Er: I did warn that "rebuilding the shader cache with MFAA on is excruciating," didn't I?

Edited by Goose, 28 February 2016 - 06:58 PM.

[xWiredx]

Small update: CW uses about 3.4GB of VRAM @ 1080p with my settings. 1.68GB of system RAM.

e_ShadowsResScale is something I think I just pulled from something somewhere. I don't recall. I'd have to look at it.

e_ParticlesPoolSize isn't set to 0 by PGI, its set to 12288, and the other one that I have set to 12288 is normally set to 6144 or something. I just doubled them to see if it would help and... I think it might but I have no good way of quantifying it.

[Goose]

Er: 3.3GB main and 1.9GB VRAM on Canyon, just now …

[Goose]

I'd forgotten I'd received this in the "mail:" https://bitsum.com/t...ading-the-load/

[NocturnalBeast]

Still runs fine on my aging system. Recently enabled HPET http://www.tomshardw...hpet-fully.html (works for Win 10 too!). Also, killing the Cortana process in Win 10 frees up a decent amount of RAM too.

[Lordred]

Most recent reports from team AMD: 8350 with no overclocks.

All CVAR settings deleted, running a clean user.cfg

Map: Forest Colony (Dayish)

Settings: 1080p Very High.

Report: Playable.

[NocturnalBeast]

Lordred, on 02 March 2016 - 08:50 PM, said:

Most recent reports from team AMD: 8350 with no overclocks.

All CVAR settings deleted, running a clean user.cfg

Map: Forest Colony (Dayish)

Settings: 1080p Very High.

Report: Playable.

What do you consider "playable"? as long as I stay close to 60fps (vsync) the game works fine for me.

[Goose]

Lordred, on 02 March 2016 - 08:50 PM, said:

Report: Purrdy.

FTFY