295 replies to this topic

[Goose]

I'll just leave these here …

[Lordred]

Doth my eyes deceive me?

Thou have achieved 12 addressed threads?

[Goose]

Er: Yes?

But I've often had loads something like this, and think all those <8% are just the "background count" of a well-developed OS install.

The spikes at the end, where I died, should be all the particles threads I'm setting

Spoiler

sys_limit_phys_thread_count = 0
p_num_threads = 12

puts a thread on each of my "logical" cores, where the default would be 5 out'a 6 physical cores

The real story here is "I've changed my mind as to what 22DEC2014 patch ment." This was the "AMD" patch I'd deemed to be the shuffling of CryTek default thread placement into a "PGI default," and the later "one setting performance increase" was "sys_spec_Physics" being turned down. I now think 22DEC2014 was some kind of reduction in math precision. AMD's current inability to run two floating-point threads on the same module would seem a great way not to run Cryengine; But if you can get the engine to only need the half-math-co instead of trying to get the engine to not trigger a civil war within the CPU, then you'd improve the AMD users happiness, right?

I do think sys_spec_Physics got turned down at some point, as we started hearing 'bout fratricide 'mongst missiles, which is what I saw when I try it myself, years ago.

Anyways: Where I had all the treads placed manually over the holidays, I'm now down to

;0 = main, task3
;1 = physics, task5
;2 = task4, streaming
;3 = ca1,  task0
;4 = task2, water
;5 = ca0, task1
 
sys_TaskThread3_CPU = 0
r_WaterUpdateThread = 4
sys_streaming_CPU = 2

and still testing.

Where before I was all 'bout getting "ca0" all alone on a core, I'm now gambling the "task system" is there to recover unused cycles, and unload wang'd threads. Ergo, you should have a task# on every core, even if you hope to never resort to the one sharing with ca0.

For reference

Spoiler

;ca_thread0Affinity = type: int current: 5
;ca_thread1Affinity = type: int current: 3
;r_WaterUpdateThread = type: int current: 5
;sys_main_CPU = type: int current: 0
;sys_physics_CPU = type: int current: 1
;sys_streaming_CPU = type: int current: 1
;sys_TaskThread0_CPU = type: int current: 3
;sys_TaskThread1_CPU = type: int current: 5
;sys_TaskThread2_CPU = type: int current: 4
;sys_TaskThread3_CPU = type: int current: 3
;sys_TaskThread4_CPU = type: int current: 2
;sys_TaskThread5_CPU = type: int current: 1
 
;Hexa
;0 = main
;1 = physics, streaming, task5
;2 = task4
;3 = ca1, task0, task3
;4 = task2
;5 = ca0, task1, water
 
;Quad
;0 = main, task2
;1 = physics, streaming, task5, ca0, task1, water
;2 = task4
;3 = ca1, task0, task3
 
;Triple
;0 = main, ca1, task0, task3
;1 = physics, streaming, task5, task2
;2 = task4, ca0, task1, water
 
;Dual
;0 = main, task4, task2
;1 = physics, streaming, task5, ca1, task0, task3, ca0, task1, water

So as you can see, I think having water with ca0 is just bad, and I've made shore there's a task# with main. Oddly, this seems to have unloaded ca1 and task4.

Having more then one task# on a core mean what?

I don't have access to an Intel Quad just now, and I forget if it would be set up different from a FX-8xy0; I still have to make time for test on my Pentium G620.

There is a concept of "threads going out of sync" I really wish I could address; I keep thinking thread placement might change with CPU Hz, but I'm not so confident of my overclocking skills to be de-tuning systems willy-nilly for such test …

We've completely lost Smokiejedis' tests, haven't we?

[Goose]

New River, 1000 Hours, as per SoP:





My "notes" show 3.5GB "commit VRAM," to go with a 4.9GB commit main as reported by Process Explorer, but I wasn't bright enough to screen-shot it; Gwad only know when I'll be on Forrest 1000 Hours, if only to prove it's not that hard to render …

I think I've hit on a tweak:

Spoiler

sys_limit_phys_thread_count = 0
p_num_threads = 6
p_num_jobs = 12

where p~threads is equal to your core count, and p~jobs is twice as many.

Edited by Goose, 16 March 2016 - 07:02 AM.

[xWiredx]

Haven't looked at the graphs yet, but just from experience do you think it feels and plays less stuttery? When you drag your lasers into the ground right in front of you do you still get a slideshow?

[Goose]

I think you are discribing the

r_radialBlur = 0
g_radialBlur = 0
e_ParticlesMotionBlur = 0

set there, xWiredx, but that sounds like a properly specific test.

I think jacking the two "p" statements would ease the load from all the crap in the air on New River.

[xWiredx]

Goose, on 16 March 2016 - 07:06 AM, said:

I think you are discribing the

r_radialBlur = 0
g_radialBlur = 0
e_ParticlesMotionBlur = 0

set there, xWiredx, but that sounds like a properly specific test.

I think jacking the two "p" statements would ease the load from all the crap in the air on New River.

The sad part about that effect in the air is that in UE4 the performance cost isn't nearly as great for a better-looking effect because it's properly shuffled off to the GPU.

I do set particlesmotionblur to 0 already and dragging lasers into the hill right in front of me incurs one hell of a performance hit on my system. I'll have to try setting the radialblur settings as well, but I don't see a significant impact when taking a lot of fire right to the face like you mentioned. I think part of the problem is still that dragging the lasers spews tons of little dirt and fire particles. I'm hoping that spreading the particle load across threads might help a bit.

[Goose]

Annnd I rem'd out all six statements and found nothing.

I will say `in cleaning out dead-wood from my user.cfg, I only really have "r_MotionBlurMaxViewDist = 4000" and "e_LodCompMaxSize = 9" diccing with my LoDs anymore.'

But I also have

r_UseGSParticles = 1
e_ParticlesPoolSize = 0

so maybe …

Edited by Goose, 17 March 2016 - 04:00 PM.

[Goose]

So, I still haven't triggered xWiredx's Particle Hell, even though I've seen it before; What I am doing is going into Onslaught/ Armageddon++ and just talking it.

If you're Lucky©, some SRM-bearing lights will show up ahead of the main body and spam you in the face, which shows GPU spikes. I have yet to effect this …

What is happening is with those eight linesф active, I don't have a framerate drop until there's a lot of fire happening; Without, I'm down ~20fps as the vanguard approaches …

Also: I'd said, somewhere, the two hardest views in the game where wandering around the Advanced Academy, looking at Teh Capt.; With almost all of my LoD statements gone, I don't have that issue anymore.

ф

Spoiler

r_radialBlur = 0
g_radialBlur = 0
e_ParticlesMotionBlur = 0
r_UseGSParticles = 1
e_ParticlesPoolSize = 0
sys_limit_phys_thread_count = 0
p_num_threads = 6
p_num_jobs = 12

Edited by Goose, 21 March 2016 - 03:56 PM.

[Goose]

So I got my New River game.





The hodo at the seven-minute mark is the blooming tunnel.

It seems HWiNFOs "GPU Memory Allocated" is the same as Process Explorers' GPU commit; I didn't have PE open, so I don't know how much main was taken up by the game.

I am perplexed 'bout there only being one "secondary load" above 8% …

[Goose]

To field someone's question:









ReShade won't grab the overlay(s) when you screen-grab, but you lose whatever it is you where asking ReShade for.









… And MFAA in the "root" profile of the nVidia driver.

[Goose]

So how hard is New Forrest?





I think I got a face full of SRMs, there at the 7:10 mark …

But look at the cores: Nine out'a 12 show Real Loads.

[Goose]

Fielding quistions, just not in a timely manner.

How To ReShade:



(Not pictured is the part where you pick the DirectX version.)



"Highlighted" is the switch you need to change if you want the on/off switch to explain itself. I find it handy set to one …



The Gents whom wrote SMAA have this one note 'bout an extra setting for use with Temporal AA, so here's a profile for use with a game embracing it; Feel free to have more profiles.





And here we have the heart of the matter: The internal settings for SMAA, all of which can be deemed "SMAA 1x"

Spoiler

* SMAA_PRESET_LOW (%60 of the quality)
#define SMAA_THRESHOLD 0.15
#define SMAA_MAX_SEARCH_STEPS 4
#define SMAA_DISABLE_DIAG_DETECTION
#define SMAA_DISABLE_CORNER_DETECTION

* SMAA_PRESET_MEDIUM (%80 of the quality)
#define SMAA_THRESHOLD 0.1
#define SMAA_MAX_SEARCH_STEPS 8
#define SMAA_DISABLE_DIAG_DETECTION
#define SMAA_DISABLE_CORNER_DETECTION

* SMAA_PRESET_HIGH (%95 of the quality)
#define SMAA_THRESHOLD 0.1
#define SMAA_MAX_SEARCH_STEPS 16
#define SMAA_MAX_SEARCH_STEPS_DIAG 8
#define SMAA_CORNER_ROUNDING 25

* SMAA_PRESET_ULTRA (%99 of the quality)
#define SMAA_THRESHOLD 0.05
#define SMAA_MAX_SEARCH_STEPS 32
#define SMAA_MAX_SEARCH_STEPS_DIAG 16
#define SMAA_CORNER_ROUNDING 25

* If temporal supersampling is used, [SMAA_THRESHOLD] 0.2 could be a reasonable value, as low
* contrast edges are properly filtered by just 2x.

are the reivent notes from the SMAA devs; Additionally, Mr. CeeJay thinks a range of 0.08~0.12 is a useful norm. I've crept up to 0.15, myself …

Mr. CeeJay also likes SMAA_CORNER_ROUNDING to be zeroed out, so keep that in mind if you think the HUD is illegible.

It's worth pointing out the lack of access to a depth buffer here in MWO means SMAA_PREDICATION is useless to us, and a setting of 3 for SMAA_EDGE_DETECTION is patently unhelpful. In turn, you should also set RESHADE_DEPTH_LINEARIZATION up in Profile Settings to 0.

Note you can just alt-tab out'a the game, make an adjustment (pushing "save") then alt-tab back in and see the results right then'n there.

I've done about zero benching with any of the "settings" below "High:" I don't think a card big enough load MWO would ever see more then a 5% load change between on and off … Which I guess is maybe heavier then forcing Anisotropic filtering to 16x, but not by much.

On the assumption you would use ReShade with PostAA, what seems to amount to SMAA T2x, let me point out "It comes with FXAA by default." You can turn it down

Spoiler

r_PostMSAAEdgeFilterNV = x; 0 = Off, 1 = SuperSchmear, 2 = Kind'a Blurry, 3 = A Little Sharp

or even substitute the internal SMAA

Spoiler

r_PostMSAAEdgeFilterNV = 0 and r_PostAAEdgeFilter = 1

… but somehow ReShade looks better, even with/ dispite my Placebo Goggles. Anyways: Set both to zero if you're gon'a run ReShade, or other inject-able AAs.

As an aside, I recommend adding "sys_flash_edgeaa = 0" to your user.cfg if you inject any non-hardware AA (FXAA from the nVida driver, or Morphological from Crimson,) as any such AA will grab the HUD weather you like it or not, so it seems best practice to do so.

Also: DSR, MFAA, and SGSSAA are hardware AAs …

[Goose]

Goose, on 30 April 2016 - 10:55 AM, said:

… or even substitute the internal SMAA

Spoiler

r_PostMSAAEdgeFilterNV = 0 and r_PostAAEdgeFilter = 1

… but somehow ReShade looks better, even with/ dispite my Placebo Goggles. Anyways: Set both to zero if you're gon'a run ReShade, or other inject-able AAs.

"Placebo Goggles" is the phrase: With access to five systems at this point, I see jack-all for "internal SMAA."

Dial in the FXAA to your liking, or else inject SMAA with ReShade/ SweetFX …

[Goose]

http://www.adriancou...graphics-study/

http://www.pcgamer.c...means-in-games/

[darqsyde]

i7-4790k@4.4, 16gb 2400mhz RAM, Sabertooth z97 Mark2, Sapphire RX480 4Gb Nitro.

Mining Collective, Domination
1080p, Full Window, DX11, MB Low, Vsync Off, Damage Glow On, Very High (AA Off)

Edited by darqsyde, 06 December 2016 - 02:07 PM.