3Dmigoto now open-source...
  133 / 143    
@DSS: no problem about the iniparams thing. If extending it a lot reduces performance then better leave it like it is now. I can survive, just not do thoughtless overspending of iniparams :p. Except that it's cool if you want to make separate variables for mouse, SBS, etc. That would be enough for me.
@DSS: no problem about the iniparams thing. If extending it a lot reduces performance then better leave it like it is now. I can survive, just not do thoughtless overspending of iniparams :p.

Except that it's cool if you want to make separate variables for mouse, SBS, etc. That would be enough for me.

CPU: Intel Core i7 7700K @ 4.9GHz
Motherboard: Gigabyte Aorus GA-Z270X-Gaming 5
RAM: GSKILL Ripjaws Z 16GB 3866MHz CL18
GPU: MSI GeForce RTX 2080Ti Gaming X Trio
Monitor: Asus PG278QR
Speakers: Logitech Z506
Donations account: masterotakusuko@gmail.com

Posted 04/17/2018 06:20 AM   
So I'm kinda having a hell of a time updating one of my fixes to take advantage of presets for a more seamless experience than before. Problem is that it seems to utilize mostly the same HUD shaders/textures for every scene, with the same texture properties, etc. I've managed to pick out a few criteria for triggers so have mostly achieved what I'm looking to do, but I'm also running into a few hiccups along the way. One of the challenges I'm facing is, from what I've gathered, that seems like values set under presets can only entirely be momentary toggles, and no persistence once the preset is inactive. I've tried setting "post" on both constants and convergence and that seems to have no effect. Is this a correct observation, and if so, any possibility of getting implemented? Here's an example of what I'd like to achieve in one case. On the titlescreen has a menu at screen depth (like most other menus), so adjusting it's depth along with the software mouse cursor by the same param has them aligned fine. Great. Awesome. Fan-f***ing-tastic! However, going into the Options or Load screens from here brings up a menu that is slightly pushed into depth on it's own, which breaks alignment with the mouse cursor, but it uses same shaders/textures as every other menu so I can't set up a specific preset here. However, on the title screen there is a unique texture (game's logo) that I can use to set a preset for it (and that texture disappears when going into these other menus). Idea is to create the preset here so that once the preset becomes inactive it will set an iniparam to 1 as a flag so that I can pick up in the mouse.hlsl as a special condition and make the necessary adjustment. That title screen preset would be the only one to set that flag, and then one of the presets that gets loaded later will then change that flag back to 0 so that the mouse can be aligned with all the standard menus from there on. I've tried using the texture itself to set the param on post, but for some reason that doesn't seem to get picked up. I feel like using textures/shaders to change params seem to only be localized to those associated shaders, and not globally like they are in presets. Is this correct (and on the chance it is, any possibility of adding a global vs local flag)? Also you had asked me what was my intention when I was asking about priorities for presets, and essentially when setting up various conditions for different presets, there may be certain cases where 2 presets can be triggered at once. Perfectly fine if they are changing different values (ie. one a constant, one for convergence or different constant), but if they are both changing the same value it would be nice to be able to set which one takes effect over the other. It sounds like that could be handled through the ordered naming convention, so I'll wait for that update, but just explaining this to answer the question from before. Related to this, I'm dealing with an issue of a constant seemingly changing values on it's own. I have the value only being changed through presets, so I have a feeling I've got one or more that are competing at once. There's one preset that I want to be active in this situation, and have even set up Exclude_Preset conditions for each of the other presets on the triggering texture, but it's still going back and forth (like, it'll be on the active preset for about 2 seconds, quickly blip over to the other setting for about 0.5-1 second, and then back to the active one. Really aggravating). Not sure if a priorities system would help here, but that's kinda the idea. Anyways, no rush on all this, ofc, and thanks for entertaining feedback and requests as always!
So I'm kinda having a hell of a time updating one of my fixes to take advantage of presets for a more seamless experience than before. Problem is that it seems to utilize mostly the same HUD shaders/textures for every scene, with the same texture properties, etc. I've managed to pick out a few criteria for triggers so have mostly achieved what I'm looking to do, but I'm also running into a few hiccups along the way.

One of the challenges I'm facing is, from what I've gathered, that seems like values set under presets can only entirely be momentary toggles, and no persistence once the preset is inactive. I've tried setting "post" on both constants and convergence and that seems to have no effect. Is this a correct observation, and if so, any possibility of getting implemented?

Here's an example of what I'd like to achieve in one case. On the titlescreen has a menu at screen depth (like most other menus), so adjusting it's depth along with the software mouse cursor by the same param has them aligned fine. Great. Awesome. Fan-f***ing-tastic! However, going into the Options or Load screens from here brings up a menu that is slightly pushed into depth on it's own, which breaks alignment with the mouse cursor, but it uses same shaders/textures as every other menu so I can't set up a specific preset here. However, on the title screen there is a unique texture (game's logo) that I can use to set a preset for it (and that texture disappears when going into these other menus). Idea is to create the preset here so that once the preset becomes inactive it will set an iniparam to 1 as a flag so that I can pick up in the mouse.hlsl as a special condition and make the necessary adjustment. That title screen preset would be the only one to set that flag, and then one of the presets that gets loaded later will then change that flag back to 0 so that the mouse can be aligned with all the standard menus from there on. I've tried using the texture itself to set the param on post, but for some reason that doesn't seem to get picked up. I feel like using textures/shaders to change params seem to only be localized to those associated shaders, and not globally like they are in presets. Is this correct (and on the chance it is, any possibility of adding a global vs local flag)?


Also you had asked me what was my intention when I was asking about priorities for presets, and essentially when setting up various conditions for different presets, there may be certain cases where 2 presets can be triggered at once. Perfectly fine if they are changing different values (ie. one a constant, one for convergence or different constant), but if they are both changing the same value it would be nice to be able to set which one takes effect over the other. It sounds like that could be handled through the ordered naming convention, so I'll wait for that update, but just explaining this to answer the question from before.

Related to this, I'm dealing with an issue of a constant seemingly changing values on it's own. I have the value only being changed through presets, so I have a feeling I've got one or more that are competing at once. There's one preset that I want to be active in this situation, and have even set up Exclude_Preset conditions for each of the other presets on the triggering texture, but it's still going back and forth (like, it'll be on the active preset for about 2 seconds, quickly blip over to the other setting for about 0.5-1 second, and then back to the active one. Really aggravating). Not sure if a priorities system would help here, but that's kinda the idea.

Anyways, no rush on all this, ofc, and thanks for entertaining feedback and requests as always!

3D Gaming Rig: CPU: i7 7700K @ 4.9Ghz | Mobo: Asus Maximus Hero VIII | RAM: Corsair Dominator 16GB | GPU: 2 x GTX 1080 Ti SLI | 3xSSDs for OS and Apps, 2 x HDD's for 11GB storage | PSU: Seasonic X-1250 M2| Case: Corsair C70 | Cooling: Corsair H115i Hydro cooler | Displays: Asus PG278QR, BenQ XL2420TX & BenQ HT1075 | OS: Windows 10 Pro + Windows 7 dual boot

Like my fixes? Dontations can be made to: www.paypal.me/DShanz or rshannonca@gmail.com
Like electronic music? Check out: www.soundcloud.com/dj-ryan-king

Posted 04/18/2018 08:19 PM   
[quote="DJ-RK"]One of the challenges I'm facing is, from what I've gathered, that seems like values set under presets can only entirely be momentary toggles, and no persistence once the preset is inactive. I've tried setting "post" on both constants and convergence and that seems to have no effect. Is this a correct observation, and if so, any possibility of getting implemented?[/quote] Anything set inside the [Preset] will be restored to the previous value once that preset becomes inactive, so if you want a value to remain persistent after the preset has finished, [i]don't set it in the preset [b]at all[/b][/i] - either set it from the command list you used to trigger the preset in the first place (if it's ok for it to be set part-way through a frame), or attach a command list to the preset and set it from there (if you want it set on the present call when presets are processed), e.g. from DOAXVV: [code] [PresetBurst] ; ... ; We want the w4 flag to remain cleared after the preset finishes until it is ; next set by the auto-convergence stanza. The preset can't do this itself (and ; would restore the previous value when finished), but it can trigger a command ; list when it finishes and that command list can clear the flag: run = CommandListBurst [CommandListBurst] ; Prevent this convergence override from being interpreted as the user changing ; the convergence: post w4 = 0 [/code] [quote]I've tried using the texture itself to set the param on post, but for some reason that doesn't seem to get picked up. I feel like using textures/shaders to change params seem to only be localized to those associated shaders, and not globally like they are in presets. Is this correct (and on the chance it is, any possibility of adding a global vs local flag)?[/quote]They are global, but if you are also setting that value in a preset then the preset may be reverting it. You can also check the frame analysis log to a) make sure your post stanza is being executed (if you only used "pre checktextureoverride" or the texture had changed by the time the post command list came up it may not) and b) check that nothing else in the command list is clobbering it afterwards (but beware that the frame analysis log doesn't include anything that presets change). [quote]Related to this, I'm dealing with an issue of a constant seemingly changing values on it's own. I have the value only being changed through presets, so I have a feeling I've got one or more that are competing at once. There's one preset that I want to be active in this situation, and have even set up Exclude_Preset conditions for each of the other presets on the triggering texture, but it's still going back and forth (like, it'll be on the active preset for about 2 seconds, quickly blip over to the other setting for about 0.5-1 second, and then back to the active one. Really aggravating). Not sure if a priorities system would help here, but that's kinda the idea.[/quote]Monitor the d3d11_log.txt to see when the presets are being triggered - I think the log mis-reports them as key inputs ("User key [de]activation") as that was where presets were built on, but it's there.
DJ-RK said:One of the challenges I'm facing is, from what I've gathered, that seems like values set under presets can only entirely be momentary toggles, and no persistence once the preset is inactive. I've tried setting "post" on both constants and convergence and that seems to have no effect. Is this a correct observation, and if so, any possibility of getting implemented?

Anything set inside the [Preset] will be restored to the previous value once that preset becomes inactive, so if you want a value to remain persistent after the preset has finished, don't set it in the preset at all - either set it from the command list you used to trigger the preset in the first place (if it's ok for it to be set part-way through a frame), or attach a command list to the preset and set it from there (if you want it set on the present call when presets are processed), e.g. from DOAXVV:

[PresetBurst]
; ...
; We want the w4 flag to remain cleared after the preset finishes until it is
; next set by the auto-convergence stanza. The preset can't do this itself (and
; would restore the previous value when finished), but it can trigger a command
; list when it finishes and that command list can clear the flag:
run = CommandListBurst
[CommandListBurst]
; Prevent this convergence override from being interpreted as the user changing
; the convergence:
post w4 = 0


I've tried using the texture itself to set the param on post, but for some reason that doesn't seem to get picked up. I feel like using textures/shaders to change params seem to only be localized to those associated shaders, and not globally like they are in presets. Is this correct (and on the chance it is, any possibility of adding a global vs local flag)?
They are global, but if you are also setting that value in a preset then the preset may be reverting it. You can also check the frame analysis log to a) make sure your post stanza is being executed (if you only used "pre checktextureoverride" or the texture had changed by the time the post command list came up it may not) and b) check that nothing else in the command list is clobbering it afterwards (but beware that the frame analysis log doesn't include anything that presets change).

Related to this, I'm dealing with an issue of a constant seemingly changing values on it's own. I have the value only being changed through presets, so I have a feeling I've got one or more that are competing at once. There's one preset that I want to be active in this situation, and have even set up Exclude_Preset conditions for each of the other presets on the triggering texture, but it's still going back and forth (like, it'll be on the active preset for about 2 seconds, quickly blip over to the other setting for about 0.5-1 second, and then back to the active one. Really aggravating). Not sure if a priorities system would help here, but that's kinda the idea.
Monitor the d3d11_log.txt to see when the presets are being triggered - I think the log mis-reports them as key inputs ("User key [de]activation") as that was where presets were built on, but it's there.

2x Geforce GTX 980 in SLI provided by NVIDIA, i7 6700K 4GHz CPU, Asus 27" VG278HE 144Hz 3D Monitor, BenQ W1070 3D Projector, 120" Elite Screens YardMaster 2, 32GB Corsair DDR4 3200MHz RAM, Samsung 850 EVO 500G SSD, 4x750GB HDD in RAID5, Gigabyte Z170X-Gaming 7 Motherboard, Corsair Obsidian 750D Airflow Edition Case, Corsair RM850i PSU, HTC Vive, Win 10 64bit

Alienware M17x R4 w/ built in 3D, Intel i7 3740QM, GTX 680m 2GB, 16GB DDR3 1600MHz RAM, Win7 64bit, 1TB SSD, 1TB HDD, 750GB HDD

Pre-release 3D fixes, shadertool.py and other goodies: http://github.com/DarkStarSword/3d-fixes
Support me on Patreon: https://www.patreon.com/DarkStarSword or PayPal: https://www.paypal.me/DarkStarSword

Posted 04/18/2018 10:30 PM   
Had a really good night of progress thanks to all this, so thanks! Almost done the project I'm working on that's been related to all these inquiries. In the meantime, I do have another inquiry... any way (or plans for or possibility of in the future) of having keys only be active or deactivated by presets? Or be able to have different values assigned to them based on the currently active preset? One way I can imagine this is where we would need the more robust programming engine, where we could set multipliers to the values, and adjust those multi's in the preset, but wondering if there is something that may be achievable sooner.
Had a really good night of progress thanks to all this, so thanks! Almost done the project I'm working on that's been related to all these inquiries.

In the meantime, I do have another inquiry... any way (or plans for or possibility of in the future) of having keys only be active or deactivated by presets? Or be able to have different values assigned to them based on the currently active preset? One way I can imagine this is where we would need the more robust programming engine, where we could set multipliers to the values, and adjust those multi's in the preset, but wondering if there is something that may be achievable sooner.

3D Gaming Rig: CPU: i7 7700K @ 4.9Ghz | Mobo: Asus Maximus Hero VIII | RAM: Corsair Dominator 16GB | GPU: 2 x GTX 1080 Ti SLI | 3xSSDs for OS and Apps, 2 x HDD's for 11GB storage | PSU: Seasonic X-1250 M2| Case: Corsair C70 | Cooling: Corsair H115i Hydro cooler | Displays: Asus PG278QR, BenQ XL2420TX & BenQ HT1075 | OS: Windows 10 Pro + Windows 7 dual boot

Like my fixes? Dontations can be made to: www.paypal.me/DShanz or rshannonca@gmail.com
Like electronic music? Check out: www.soundcloud.com/dj-ryan-king

Posted 04/21/2018 06:40 AM   
The [Key] and [Preset] sections do actually have a condition option that only allows them to activate if the corresponding ini param is non-zero that might do what you need: [code] [KeyFirstPersonAim1] key = f condition = z1 convergence = 0.02 [/code] That was originally added as a poor man's substitute for key combos (in MGSV), and I was actually thinking about deprecating and removing it since we can now do that directly - but if you have a use for it, it can stay :)
The [Key] and [Preset] sections do actually have a condition option that only allows them to activate if the corresponding ini param is non-zero that might do what you need:

[KeyFirstPersonAim1]
key = f
condition = z1
convergence = 0.02


That was originally added as a poor man's substitute for key combos (in MGSV), and I was actually thinking about deprecating and removing it since we can now do that directly - but if you have a use for it, it can stay :)

2x Geforce GTX 980 in SLI provided by NVIDIA, i7 6700K 4GHz CPU, Asus 27" VG278HE 144Hz 3D Monitor, BenQ W1070 3D Projector, 120" Elite Screens YardMaster 2, 32GB Corsair DDR4 3200MHz RAM, Samsung 850 EVO 500G SSD, 4x750GB HDD in RAID5, Gigabyte Z170X-Gaming 7 Motherboard, Corsair Obsidian 750D Airflow Edition Case, Corsair RM850i PSU, HTC Vive, Win 10 64bit

Alienware M17x R4 w/ built in 3D, Intel i7 3740QM, GTX 680m 2GB, 16GB DDR3 1600MHz RAM, Win7 64bit, 1TB SSD, 1TB HDD, 750GB HDD

Pre-release 3D fixes, shadertool.py and other goodies: http://github.com/DarkStarSword/3d-fixes
Support me on Patreon: https://www.patreon.com/DarkStarSword or PayPal: https://www.paypal.me/DarkStarSword

Posted 04/21/2018 07:51 AM   
You can bet'cha big black booty you bloody beautiful bastage I got a use for it! Especially if I can set up 2 separate keys, assigned to the same input and use the condition to decide which one gets activated.
You can bet'cha big black booty you bloody beautiful bastage I got a use for it! Especially if I can set up 2 separate keys, assigned to the same input and use the condition to decide which one gets activated.

3D Gaming Rig: CPU: i7 7700K @ 4.9Ghz | Mobo: Asus Maximus Hero VIII | RAM: Corsair Dominator 16GB | GPU: 2 x GTX 1080 Ti SLI | 3xSSDs for OS and Apps, 2 x HDD's for 11GB storage | PSU: Seasonic X-1250 M2| Case: Corsair C70 | Cooling: Corsair H115i Hydro cooler | Displays: Asus PG278QR, BenQ XL2420TX & BenQ HT1075 | OS: Windows 10 Pro + Windows 7 dual boot

Like my fixes? Dontations can be made to: www.paypal.me/DShanz or rshannonca@gmail.com
Like electronic music? Check out: www.soundcloud.com/dj-ryan-king

Posted 04/21/2018 12:44 PM   
Hi Guys, bo3b, DSS, and everyone involved, I wanted to thank you for getting ReShade to work with 3DMigoto. The 4 sharpening effects really bring out the detail in compatible games, without touching anything else or hitting performance. Then 4x DSR with 0% smoothness eradicates all the jaggies especially caused by the sharpening effects. The result is a jaggyless and beautifully crisp image which oozes detail, all in glorious 3D. I humbly salute all of you!
Hi Guys,

bo3b, DSS, and everyone involved, I wanted to thank you for getting ReShade to work with 3DMigoto. The 4 sharpening effects really bring out the detail in compatible games, without touching anything else or hitting performance. Then 4x DSR with 0% smoothness eradicates all the jaggies especially caused by the sharpening effects.

The result is a jaggyless and beautifully crisp image which oozes detail, all in glorious 3D.

I humbly salute all of you!

Windows 10 64-bit, Intel 7700K @ 5.1GHz, 16GB 3600MHz CL15 DDR4 RAM, 2x GTX 1080 SLI, Asus Maximus IX Hero, Sound Blaster ZxR, PCIe Quad SSD, Oculus Rift CV1, DLP Link PGD-150 glasses, ViewSonic PJD6531w 3D DLP Projector @ 1280x800 120Hz native / 2560x1600 120Hz DSR 3D Gaming.

Posted 04/26/2018 11:28 PM   
Question, in case it's possible and I didn't know about it: is there a way to do things in shaders in alternate frames? I'm asking because there are some Japanese NES games and some Sega Master System games that have active 3D (30fps per eye) and not anaglyph, so what I want to do is obscuring the view of a different eye per frame, combining the use of "stereo.z" with the other unknown to me thing. I don't know if the time variable could be used for this in a certain way.
Question, in case it's possible and I didn't know about it: is there a way to do things in shaders in alternate frames?

I'm asking because there are some Japanese NES games and some Sega Master System games that have active 3D (30fps per eye) and not anaglyph, so what I want to do is obscuring the view of a different eye per frame, combining the use of "stereo.z" with the other unknown to me thing. I don't know if the time variable could be used for this in a certain way.

CPU: Intel Core i7 7700K @ 4.9GHz
Motherboard: Gigabyte Aorus GA-Z270X-Gaming 5
RAM: GSKILL Ripjaws Z 16GB 3866MHz CL18
GPU: MSI GeForce RTX 2080Ti Gaming X Trio
Monitor: Asus PG278QR
Speakers: Logitech Z506
Donations account: masterotakusuko@gmail.com

Posted 04/29/2018 08:45 AM   
You could use a custom compute shader from the present call and use a state buffer to keep track of whether you are on an odd or even frame, but the feature I'm working on at the moment will probably make it a lot easier... in the next version you should be able to do something like: [code] [Present] x = (x + 1) % 2 if x == 0 ; do something else ; do something else endif [/code] I am knee deep in expression parsing code at the moment - left associative binary operators are working :)
You could use a custom compute shader from the present call and use a state buffer to keep track of whether you are on an odd or even frame, but the feature I'm working on at the moment will probably make it a lot easier... in the next version you should be able to do something like:

[Present]
x = (x + 1) % 2
if x == 0
; do something
else
; do something else
endif


I am knee deep in expression parsing code at the moment - left associative binary operators are working :)

2x Geforce GTX 980 in SLI provided by NVIDIA, i7 6700K 4GHz CPU, Asus 27" VG278HE 144Hz 3D Monitor, BenQ W1070 3D Projector, 120" Elite Screens YardMaster 2, 32GB Corsair DDR4 3200MHz RAM, Samsung 850 EVO 500G SSD, 4x750GB HDD in RAID5, Gigabyte Z170X-Gaming 7 Motherboard, Corsair Obsidian 750D Airflow Edition Case, Corsair RM850i PSU, HTC Vive, Win 10 64bit

Alienware M17x R4 w/ built in 3D, Intel i7 3740QM, GTX 680m 2GB, 16GB DDR3 1600MHz RAM, Win7 64bit, 1TB SSD, 1TB HDD, 750GB HDD

Pre-release 3D fixes, shadertool.py and other goodies: http://github.com/DarkStarSword/3d-fixes
Support me on Patreon: https://www.patreon.com/DarkStarSword or PayPal: https://www.paypal.me/DarkStarSword

Posted 04/29/2018 01:26 PM   
[quote="DarkStarSword"]You could use a custom compute shader from the present call and use a state buffer to keep track of whether you are on an odd or even frame, but the feature I'm working on at the moment will probably make it a lot easier... in the next version you should be able to do something like: [code] [Present] x = (x + 1) % 2 if x == 0 ; do something else ; do something else endif [/code] I am knee deep in expression parsing code at the moment - left associative binary operators are working :)[/quote] I dont know whether to rejoice or cry right now after spending the past 3 weeks going round in circles on my Xcom 2 DLC fix, which this would/will greatly have benefitted. I'm sure I'll do both once that update is released (tears of joy, of course). Thanks for finally taking this task on.
DarkStarSword said:You could use a custom compute shader from the present call and use a state buffer to keep track of whether you are on an odd or even frame, but the feature I'm working on at the moment will probably make it a lot easier... in the next version you should be able to do something like:

[Present]
x = (x + 1) % 2
if x == 0
; do something
else
; do something else
endif


I am knee deep in expression parsing code at the moment - left associative binary operators are working :)


I dont know whether to rejoice or cry right now after spending the past 3 weeks going round in circles on my Xcom 2 DLC fix, which this would/will greatly have benefitted. I'm sure I'll do both once that update is released (tears of joy, of course). Thanks for finally taking this task on.

3D Gaming Rig: CPU: i7 7700K @ 4.9Ghz | Mobo: Asus Maximus Hero VIII | RAM: Corsair Dominator 16GB | GPU: 2 x GTX 1080 Ti SLI | 3xSSDs for OS and Apps, 2 x HDD's for 11GB storage | PSU: Seasonic X-1250 M2| Case: Corsair C70 | Cooling: Corsair H115i Hydro cooler | Displays: Asus PG278QR, BenQ XL2420TX & BenQ HT1075 | OS: Windows 10 Pro + Windows 7 dual boot

Like my fixes? Dontations can be made to: www.paypal.me/DShanz or rshannonca@gmail.com
Like electronic music? Check out: www.soundcloud.com/dj-ryan-king

Posted 04/29/2018 04:36 PM   
Sounds great, DSS. I'll wait patiently for that update :). More (old ass) 3D games will be possible thanks to that!
Sounds great, DSS. I'll wait patiently for that update :). More (old ass) 3D games will be possible thanks to that!

CPU: Intel Core i7 7700K @ 4.9GHz
Motherboard: Gigabyte Aorus GA-Z270X-Gaming 5
RAM: GSKILL Ripjaws Z 16GB 3866MHz CL18
GPU: MSI GeForce RTX 2080Ti Gaming X Trio
Monitor: Asus PG278QR
Speakers: Logitech Z506
Donations account: masterotakusuko@gmail.com

Posted 04/29/2018 07:04 PM   
[center][color="orange"][size="XL"]3Dmigoto 1.3.11[/size] [/color][/center][center][color="green"][url]https://github.com/bo3b/3Dmigoto/releases[/url][/color][/center] [center][size="XL"][color="orange"]SLI Optimised 3DVision2SBS Shader[/color][/size][/center] The new version of this shader shipped with 3DMigoto 1.3.11 will automatically determine when SLI is enabled, and switch to a 2 pass downscaling version that performs better, particularly at resolutions above 1080p. [center][size="XL"][color="orange"]Conditional Logic and Expression Parser[/color][/size][/center] I've promised this for a long time, and it is finally here - 3DMigoto now has a full expression parser and if/else/endif conditional to enable flow control in the command lists. [size="L"][color="green"]if/else/endif conditional[/color][/size] Conditional logic is now possible via the new if/else/endif construct. e.g. the above mentioned 3DVision2SBS shader achieves the SLI optimisation by running different shaders when SLI is in use and depending on the selected output mode. It also now skips running the shaders altogether if 3D Vision is disabled (whereas previously the vertex shader would quickly abort in that case): [code] [Present] if stereo_active && x7 if sli && x7 >= 2 run = CustomShader3DVision2SBSDownscalePass1 run = CustomShader3DVision2SBSDownscalePass2 else run = CustomShader3DVision2SBS endif endif [Resource3DVision2SBSHalfHeight] height_multiply = 0.5 [Resource3DVision2SBSHalfWidth] width_multiply = 0.5 [CustomShader3DVision2SBSDownscalePass1] ... if x7 >= 4 Resource3DVision2SBSHalfHeight = copy_desc bb o0 = set_viewport Resource3DVision2SBSHalfHeight else Resource3DVision2SBSHalfWidth = copy_desc bb o0 = set_viewport Resource3DVision2SBSHalfWidth endif [CustomShader3DVision2SBSDownscalePass2] ... if x7 >= 4 ps-t100 = stereo2mono Resource3DVision2SBSHalfHeight else ps-t100 = stereo2mono Resource3DVision2SBSHalfWidth endif [/code] This should be fairly self explanatory - the syntax is roughly modelled on languages where lines are significant (not C or HLSL) since that is the case in the ini file. It may look similar to BASIC, but I left off the "then" keyword (because what is even the point of that?). The indentation in this example is for the readers benefit only and has no bearing on the meaning of this code. There is currently no "else if" or "elif" clauses, but you can always nest additional if statements inside the else clause, provided you don't nest them so deeply that you hit the command list recursion limit (currently 64). "elif" and switch statements may be added in the future as a convinience. There are no loop constructs or "goto" as yet - I'd be interested to know if anyone wants these, but I'm not super keen on adding something that could easily turn into an infinite loop or consume a large amount of CPU time in the middle of a draw call without a good use case. You can use recursion in the command lists as a possible alternative to loops, and functional programming techniques are useful here, but again the recursion limit is currently set to a modest 64 to catch accidental infinite recursion (we could raise this limit quite easily if needed). And of course, if you do need something more complicated you may consider pushing the work off to the GPU and using a shader instead. [size="L"][color="green"]Expressions[/color][/size] 3DMigoto now has a full expression parser, which can be used with the above "if" conditional, when setting an ini param, stereo or convergence and in Key/Preset's "condition=" option. Everything in the expression is a float type. When things are evaluated in a boolean context they are tested for zero/non-zero, and conditional operators will return 0.0 or 1.0. Everything that could previously be set to an ini param can be used as an operand in an expression, and ini params can now be used as operands (to enable constructs like "x = x + 1"). The expression parser has nice reporting of syntax errors, showing exactly where the syntax error was encountered on the line: [img]https://forums.geforce.com/cmd/default/download-comment-attachment/75005/[/img] While it can be used in the Key/Preset condition= option, it is not yet available for other options of the Key/Preset sections, but since these sections can call a command list with "run=CommandListXXX" you can use it via that method. If you desperately want this in combination with the Key/Preset transitions (which aren't available in the command lists yet), keep bugging me about it until I hook those up. [size="S"][color="green"]List of Expression Operands[/color][/size] [list] [.]Floating point values (Statically optimisable)[/.] [.]Ini params (x, y, z, w, x1, y1, ..., z7, w7)[/.] [.]Resource targets (ps-t0, vs-cb3, ib, vb0, oD, o0, etc), which will evaluate to the same meaning as for texture filtering (i.e. -0.0 if not bound, +0.0 if bound but no matching TextureOverride, +1.0 if matching TextureOverride with no filter_index, or the value of filter_index if it is set)[/.] [.]Any of the following keywords: [list] [.]rt_width - Active render target width[/.] [.]rt_height - Active render target height[/.] [.]res_width - Resolution width, as per get_resolution_from[/.] [.]res_height - Resolution height, as per get_resolution_from[/.] [.]window_width - Window width[/.] [.]window_height - Window height[/.] [.]vertex_count - Number of vertices being drawn, if applicable to the current draw call[/.] [.]index_count - Number of indices being drawn, if applicable to the current draw call[/.] [.]instance_count - Number of instances being drawn, if applicable to the current draw call[/.] [.]cursor_showing - Indicates whether the mouse cursor is currently visible[/.] [.]cursor_screen_x - Cursor position in absolute screen coordinates[/.] [.]cursor_screen_y - Cursor position in absolute screen coordinates[/.] [.]cursor_window_x - Cursor position relative to the window's client area in pixels[/.] [.]cursor_window_y - Cursor position relative to the window's client area in pixels[/.] [.]cursor_x - Cursor position relative to the window in the range 0 - 1 (recommended)[/.] [.]cursor_y - Cursor position relative to the window in the range 0 - 1 (recommended)[/.] [.]cursor_hotspot_x - hotspot coordinates in the cursor icon[/.] [.]cursor_hotspot_y - hotspot coordinates in the cursor icon[/.] [.]time - time since the application was launched in seconds[/.] [.]scissor_left, scissor1_left, scissor2_left, ...[/.] [.]scissor_top, ... - Coordinates of the scissor clipping rectangle[/.] [.]scissor_right, ...[/.] [.]scissor_bottom, ...[/.] [.]raw_separation - Separation value in percents (not the same as the pre-calculated separation from StereoParams) (statically optimisable)[/.] [.]eye_separation - IPD / screen width, as reported by the nvidia driver (statically optimisable)[/.] [.]convergence - Same meaning as everywhere (statically optimisable)[/.] [.]stereo_active - Indicates whether 3D Vision is currently enabled (statically optimisable)[/.] [.]sli - Indicates whether SLI is currently enabled (statically optimisable)[/.] [/list] [/.][/list]The values in this list that indicate they are statically optimisable may be optimised out by 3DMigoto in some cases, e.g. 3DMigoto may pre-calculate a constant part of an expression (with limitations), or determine that 3D Vision is disabled in the control panel or otherwise unavailable so the 3D Vision operands will always return 0, and SLI will always statically optimise to either 1 or 0. If these are used in an "if" conditional this may result in the entire if conditional being optimised out as well, so that this never has to be evaluated at run-time. The results of these optimisations will appear in the d3d11_log.txt. [size="S"][color="green"]List of Expression Operators[/color][/size] These are all the currently supported operators, in order of highest to lowest precedence. Operators in the same level of precedence are parsed left to right or right to left as indicated below: [olist][.]Unary operators have the highest level of precedence and are parsed from right to left, but will not bind if there is an operand immediately to their left (as those cases are for the lower precedence addition and subtraction operators). ! Unary not - Unary minus/negation + Unary plus [/.][.]Right to left, e.g. 2**3**4 would evaluate as 2**(3**4). Using negative numbers or fractions should have the expected mathematical outcomes. ** Exponentation [/.][.]Left to right. Dividing by zero will result in infinity (e.g. 1/0), negative infinity (e.g. 1/-0) or NaN (e.g. 0/0) - it will not result in an error. * Multiplication / Floating point division // Floor division (rounds towards negative infinity) % Floating point modulus [/.][.]Left to right + Addition - Subtraction [/.][.]Relational comparison operators. True evaluates to 1 and false evaluates to 0. These are parsed left to right and chaining these operators will follow C/HLSL style rules (e.g. (a < b < c) will evaluate as (1 < c) if a<b, or (0 < c) if a>=b, as opposed to the mathematical meaning of ((a<b) && (b<c)). < Less than <= Less than or equal to > Greater than >= Greater than or equal to [/.][.]Comparison operators. We have some unique operators in this category not found in other programming languages (and not to be confused with operators in other languages that may look the same) - equality operators will consider +0.0 as being equal to -0.0, while the identical operators will consider these to be different (likewise NaN is never equal to NaN, but may be identical to another NaN of the same type, though the usual way to test for NaN is to test if it is not equal to itself). This is useful in the context of texture filtering, where negative zero indicates that no texture is bound to the slot in question, while positive zero indicates that a texture was bound, but did not match any [TextureOverride] section, e.g. "if oD !== -0.0" can be used to determine if a depth buffer is bound. These are parsed left to right. == Equality != Inequality === Identical !== Not-identical [/.][.]These will evaluate to 1 for true or 0 for false and are parsed from left to right. Both sides of the expression will always be evaluated, though since expressions currently do not have side-effects this is inconsequential. && Logical and [/.][.]These will evaluate to 1 for true or 0 for false and are parsed from left to right. Both sides of the expression will always be evaluated, though since expressions currently do not have side-effects this is inconsequential. || Logical or [/.][/olist]There are no assignment operators in the expression evaluator - assignments are handled separately using the existing constructs. [center][size="XL"][color="orange"]Built in Performance Monitor[/color][/size][/center] 3DMigoto now has a built-in performance monitor that can be activated by pressing Ctrl+F9 (with the latest d3dx.ini template) to show 3DMigoto's performance overhead. There are three pages that can be cycled between - a summary page of key performance areas, a list of top command lists, and a list of top commands. The pages are updated every two seconds (by default), but can be frozen by pressing Shift+F9 to allow for closer examination. Freezing the display will also dump it to the d3d11_log.txt if you want to drill into it in more detail or copy & paste some of it for a bug report. Only 3DMigoto's CPU overhead is monitored at present - I would like to also monitor GPU performance (in particular to highlight expensive arbitrary resource copy operations), however doing so in and of itself actually costs an enormous amount of performance. The performance monitor will show the average time spent in each monitored area every frame, and an estimation of how many frames per second that could be costing. The estimation is based on the assumption that the game required a full 100% CPU time to only just manage to hit 60fps, and any CPU time we take will reduce that. This is only an estimation, and the actual cost may be more or less - if your system is fast enough that it had CPU time to spare you may not see any fps hit, but keep in mind that a system with a slower CPU could have higher costs than yours. [center][size="M"][color="green"]Summary Page:[/color][/size] [img]https://forums.geforce.com/cmd/default/download-comment-attachment/75002/[/img][/center] [list] [.]Present overhead: Shows the overhead that 3DMigoto is adding to every present call. This will include the time spent in the [Present] command list, processing key input, updating presets and transitions, but not the time spent in the overlay.[/.] [.]Overlay overhead: Shows the time 3DMigoto is spending to draw the overlay each frame, which will also include the profiling overlay itself, so you can pretty much ignore this as the overhead will drop to near zero when you aren't watching it.[/.] [.]Draw call overhead: Shows the total overhead that 3DMigoto is adding to the draw calls each frame. This will include the overhead of looking up the active shaders in the [ShaderOverride] sections and executing their command lists, as well as the legacy partner and depth filters, hunting mode skips and deferred ShaderRegex processing.[/.] [.]Command lists overhead: Shows the total time consumed by all currently active command lists each frame, which will typically add up to be the bulk of the cost in the present and draw calls.[/.] [.]Map/Unmap overhead: Shows the total overhead that 3DMigoto is adding to the Map/Unmap calls each frame. This includes part of the hash tracking & contamination overhead and deny_cpu_read (also, for Hellblade it would include the constant buffer detection overhead, but that functionality is not in the master branch as yet). There are typically a lot of map/unmap calls each frame, so this overhead can add up.[/.] [.]track_texture_updates: Shows overhead being paid for the hash tracking and contamination detection. In release mode this will be 0 if hash tracking is disabled, but in hunting mode there will always be a small overhead for the contamination detection, which is responsible for adding the !H! warnings in frame analysis filenames and hash_contaminated warnings in ShaderUsage.txt to indicate when hash tracking may be required. If you are certain that you don't need these warnings, you can now set track_texture_updates to 2 to disable this in hunting mode as well, but this practice is discouraged while developing a fix.[/.] [.]dump_usage overhead: Shows the overhead being paid collecting stats for the ShaderUsage.txt file. This overhead is only paid when the hunting overlay is actually being displayed (hunting=1), and can be eliminated by setting dump_usage=0 at the cost of losing the ShaderUsage.txt feature[/.] [/list] [center][size="M"][color="green"]Top Command Lists Page:[/color][/size] [img]https://forums.geforce.com/cmd/default/download-comment-attachment/75003/[/img][/center] This page shows all currently active command lists that are taking some CPU time, sorted so that the most expensive command lists are near the top. Command lists that contain both "pre" and "post" commands (explicitly or implicitly) will show up as two separate lists on this page. The count column indicates how many times that list executed per frame (on average, rounded up) during the last collection interval. Likewise the times show the average time each list is costing per frame. The difference between the inclusive and exclusive times, is that the inclusive times will include costs of other command lists that are called by this command list (e.g. by the run= and checktextureoverride= commands, if/else/endif flow control, etc), while the exclusive times shows only the time spent in that specific command list. e.g. In the above screenshot the [Present] section is taking 294.05 microseconds/frame with an estimated cost of 1fps, but only 40 microseconds are spent in the [Present] command list itself - the remainder of that time is spend in other command lists called from there, with the bulk of that coming from [CustomShaderAutoConvergenceIntermediateDownscale] which costs 0.4fps by itself. Note that the command lists for the [CustomShader] sections do not include some of the additional overhead that those sections cost to set up the render state and restore it again afterwards, though that will be included in the corresponding run= command in the top commands display. [ShaderRegex] sections that included command lists will show up multiple times - there will be a single [ShaderRegex] section for the actual command list, and every active matching Shader will also have a separate command list with a .Match=<hash> suffix that links to the main command list, and the time spent in each is reflected in the inclusive/exclusive columns. If the ShaderRegex section does not contain any commands these command lists will not be created. Only active command lists with at least one command are shown on this display - there may still be a small cost associated with looking up a command list only to find that it is empty and there is nothing to do that is not shown here, and most of that will come from the ShaderOverride lookups. [center][size="M"][color="green"]Top Commands Page:[/color][/size] [img]https://forums.geforce.com/cmd/default/download-comment-attachment/75004/[/img][/center] This page shows how much CPU time the individual commands in the command lists are costing and a breakdown of how much time was spent. There is no breakdown of inclusive vs exclusive time on this page - all times shown for commands that call other command lists will include the time spent in the called command list(s). The times are broken down into "pre" and "post" columns, showing whether that command was active in "pre" or "post" command lists, or both. Sometimes a command that appears in both lists may show as costing more in the "pre" section than it does in the "post" section even if it is performing the exact same work in each - this is typically due to CPU caching effects, and the "post" version had the benefit that the cache was still hot from the earlier execution of the "pre" version. If you see a command showing up with times in the "post" column that doesn't actually need to be post, you may consider explicitly marking it as a "pre" command, which may allow 3DMigoto to optimise out the entire post command list, and if that command was inside a [TextureOverride] section this may contribute to allowing 3DMigoto to optimise out every implicit "post checktextureoverride" command (which will only happen when every [TextureOverride] section is void of all post commands). Note that you may see frame analysis "dump" and "analyse_options" commands taking up a small amount of time - these are automatically optimised out in release mode (or when no analyse_frame key is bound) and are nothing to worry about. [size="XL"][color="orange"]Misc[/color][/size] [list] [.]At request of DJ-RK, marking mode can now be cycled between skip, original, pink and mono by holding the numpad . while pressing numpad 0 (next_marking_mode config option), and the current marking mode is displayed in the overlay. Zero marking mode is currently excluded, due to unresolved bugs (crashes) in that mode.[/.] [.]In the template d3dx.ini, compute, domain, geometry and hull shader hunting key bindings are now set to holding numpad dot and pressing the various other numpad buttons - we are effectively using numpad dot as a modifier key to do more with the keys available on the numpad[/.] [.]Preset sections are now always processed in a consistent order (case insensitive alphabetical) to ensure that we will get consistent results if multiple Preset sections affect the same parameter[/.] [.]Fixed incorrect instructions in mod conflict warning about duplicate ShaderOverride hashes[/.] [.]When copying an index or vertex buffer, 3DMigoto will no longer strip off the initial part of the data before the draw call's first vertex/index (the buffer offset part will still be stripped off if performing a full copy). This allows these buffers to be reliably backed up by reference and re-bound later, in much the same way that we often back up and rebind textures. [i]However, this could potentially break cases where these buffers have been copied into a shader resource and accessed from the shader if a first vertex/index was in use.[/i] I think in most cases we will be fine - there are only a few fixes that even access these buffers in this way, and it's unlikely that they were relying on this, and if we need it we can re-implement this in a different way (views) that will work for both cases.[/.] [.]reset_per_frame_limits is now correctly namespaced[/.] [.]clear command now correctly propagates final specified value to other channels (e.g. "clear = bb 1" will now clear the back buffer with white - before it would incorrectly clear it with red)[/.] [.]Command lists now automatically optimise out commands with no effect, such as calling run= on an empty command list (e.g. post lists), updating the separation or convergence when 3D Vision is disbled in the control panel or on AMD systems, frame analysis commands when in release mode, if conditionals where the expression could be statically evaluated to false (e.g. "if stereo_active" when 3D Vision is unavailable or "if sli" in single GPU mode), and will optimise out the implicit post checktextureoverride commands if no TextureOverride section has any post commands[/.] [.]Several small performance improvements[/.] [/list]
3Dmigoto 1.3.11


SLI Optimised 3DVision2SBS Shader

The new version of this shader shipped with 3DMigoto 1.3.11 will automatically determine when SLI is enabled, and switch to a 2 pass downscaling version that performs better, particularly at resolutions above 1080p.

Conditional Logic and Expression Parser

I've promised this for a long time, and it is finally here - 3DMigoto now has a full expression parser and if/else/endif conditional to enable flow control in the command lists.

if/else/endif conditional
Conditional logic is now possible via the new if/else/endif construct. e.g. the above mentioned 3DVision2SBS shader achieves the SLI optimisation by running different shaders when SLI is in use and depending on the selected output mode. It also now skips running the shaders altogether if 3D Vision is disabled (whereas previously the vertex shader would quickly abort in that case):

[Present]
if stereo_active && x7
if sli && x7 >= 2
run = CustomShader3DVision2SBSDownscalePass1
run = CustomShader3DVision2SBSDownscalePass2
else
run = CustomShader3DVision2SBS
endif
endif

[Resource3DVision2SBSHalfHeight]
height_multiply = 0.5
[Resource3DVision2SBSHalfWidth]
width_multiply = 0.5

[CustomShader3DVision2SBSDownscalePass1]
...
if x7 >= 4
Resource3DVision2SBSHalfHeight = copy_desc bb
o0 = set_viewport Resource3DVision2SBSHalfHeight
else
Resource3DVision2SBSHalfWidth = copy_desc bb
o0 = set_viewport Resource3DVision2SBSHalfWidth
endif

[CustomShader3DVision2SBSDownscalePass2]
...
if x7 >= 4
ps-t100 = stereo2mono Resource3DVision2SBSHalfHeight
else
ps-t100 = stereo2mono Resource3DVision2SBSHalfWidth
endif

This should be fairly self explanatory - the syntax is roughly modelled on languages where lines are significant (not C or HLSL) since that is the case in the ini file. It may look similar to BASIC, but I left off the "then" keyword (because what is even the point of that?). The indentation in this example is for the readers benefit only and has no bearing on the meaning of this code.

There is currently no "else if" or "elif" clauses, but you can always nest additional if statements inside the else clause, provided you don't nest them so deeply that you hit the command list recursion limit (currently 64). "elif" and switch statements may be added in the future as a convinience.

There are no loop constructs or "goto" as yet - I'd be interested to know if anyone wants these, but I'm not super keen on adding something that could easily turn into an infinite loop or consume a large amount of CPU time in the middle of a draw call without a good use case. You can use recursion in the command lists as a possible alternative to loops, and functional programming techniques are useful here, but again the recursion limit is currently set to a modest 64 to catch accidental infinite recursion (we could raise this limit quite easily if needed). And of course, if you do need something more complicated you may consider pushing the work off to the GPU and using a shader instead.

Expressions
3DMigoto now has a full expression parser, which can be used with the above "if" conditional, when setting an ini param, stereo or convergence and in Key/Preset's "condition=" option.

Everything in the expression is a float type. When things are evaluated in a boolean context they are tested for zero/non-zero, and conditional operators will return 0.0 or 1.0. Everything that could previously be set to an ini param can be used as an operand in an expression, and ini params can now be used as operands (to enable constructs like "x = x + 1").

The expression parser has nice reporting of syntax errors, showing exactly where the syntax error was encountered on the line:
Image

While it can be used in the Key/Preset condition= option, it is not yet available for other options of the Key/Preset sections, but since these sections can call a command list with "run=CommandListXXX" you can use it via that method. If you desperately want this in combination with the Key/Preset transitions (which aren't available in the command lists yet), keep bugging me about it until I hook those up.

List of Expression Operands
  • Floating point values (Statically optimisable)
  • Ini params (x, y, z, w, x1, y1, ..., z7, w7)
  • Resource targets (ps-t0, vs-cb3, ib, vb0, oD, o0, etc), which will evaluate to the same meaning as for texture filtering (i.e. -0.0 if not bound, +0.0 if bound but no matching TextureOverride, +1.0 if matching TextureOverride with no filter_index, or the value of filter_index if it is set)
  • Any of the following keywords:
    • rt_width - Active render target width
    • rt_height - Active render target height
    • res_width - Resolution width, as per get_resolution_from
    • res_height - Resolution height, as per get_resolution_from
    • window_width - Window width
    • window_height - Window height
    • vertex_count - Number of vertices being drawn, if applicable to the current draw call
    • index_count - Number of indices being drawn, if applicable to the current draw call
    • instance_count - Number of instances being drawn, if applicable to the current draw call
    • cursor_showing - Indicates whether the mouse cursor is currently visible
    • cursor_screen_x - Cursor position in absolute screen coordinates
    • cursor_screen_y - Cursor position in absolute screen coordinates
    • cursor_window_x - Cursor position relative to the window's client area in pixels
    • cursor_window_y - Cursor position relative to the window's client area in pixels
    • cursor_x - Cursor position relative to the window in the range 0 - 1 (recommended)
    • cursor_y - Cursor position relative to the window in the range 0 - 1 (recommended)
    • cursor_hotspot_x - hotspot coordinates in the cursor icon
    • cursor_hotspot_y - hotspot coordinates in the cursor icon
    • time - time since the application was launched in seconds
    • scissor_left, scissor1_left, scissor2_left, ...
    • scissor_top, ... - Coordinates of the scissor clipping rectangle
    • scissor_right, ...
    • scissor_bottom, ...
    • raw_separation - Separation value in percents (not the same as the pre-calculated separation from StereoParams) (statically optimisable)
    • eye_separation - IPD / screen width, as reported by the nvidia driver (statically optimisable)
    • convergence - Same meaning as everywhere (statically optimisable)
    • stereo_active - Indicates whether 3D Vision is currently enabled (statically optimisable)
    • sli - Indicates whether SLI is currently enabled (statically optimisable)

The values in this list that indicate they are statically optimisable may be optimised out by 3DMigoto in some cases, e.g. 3DMigoto may pre-calculate a constant part of an expression (with limitations), or determine that 3D Vision is disabled in the control panel or otherwise unavailable so the 3D Vision operands will always return 0, and SLI will always statically optimise to either 1 or 0. If these are used in an "if" conditional this may result in the entire if conditional being optimised out as well, so that this never has to be evaluated at run-time. The results of these optimisations will appear in the d3d11_log.txt.

List of Expression Operators
These are all the currently supported operators, in order of highest to lowest precedence. Operators in the same level of precedence are parsed left to right or right to left as indicated below:

  1. Unary operators have the highest level of precedence and are parsed from right to left, but will not bind if there is an operand immediately to their left (as those cases are for the lower precedence addition and subtraction operators).

    ! Unary not
    - Unary minus/negation
    + Unary plus

  2. Right to left, e.g. 2**3**4 would evaluate as 2**(3**4). Using negative numbers or fractions should have the expected mathematical outcomes.

    ** Exponentation

  3. Left to right. Dividing by zero will result in infinity (e.g. 1/0), negative infinity (e.g. 1/-0) or NaN (e.g. 0/0) - it will not result in an error.

    * Multiplication
    / Floating point division
    // Floor division (rounds towards negative infinity)
    % Floating point modulus

  4. Left to right

    + Addition
    - Subtraction

  5. Relational comparison operators. True evaluates to 1 and false evaluates to 0. These are parsed left to right and chaining these operators will follow C/HLSL style rules (e.g. (a < b < c) will evaluate as (1 < c) if a<b, or (0 < c) if a>=b, as opposed to the mathematical meaning of ((a<b) && (b<c)).

    < Less than
    <= Less than or equal to
    > Greater than
    >= Greater than or equal to

  6. Comparison operators. We have some unique operators in this category not found in other programming languages (and not to be confused with operators in other languages that may look the same) - equality operators will consider +0.0 as being equal to -0.0, while the identical operators will consider these to be different (likewise NaN is never equal to NaN, but may be identical to another NaN of the same type, though the usual way to test for NaN is to test if it is not equal to itself). This is useful in the context of texture filtering, where negative zero indicates that no texture is bound to the slot in question, while positive zero indicates that a texture was bound, but did not match any [TextureOverride] section, e.g. "if oD !== -0.0" can be used to determine if a depth buffer is bound. These are parsed left to right.

    == Equality
    != Inequality
    === Identical
    !== Not-identical

  7. These will evaluate to 1 for true or 0 for false and are parsed from left to right. Both sides of the expression will always be evaluated, though since expressions currently do not have side-effects this is inconsequential.

    && Logical and

  8. These will evaluate to 1 for true or 0 for false and are parsed from left to right. Both sides of the expression will always be evaluated, though since expressions currently do not have side-effects this is inconsequential.

    || Logical or

There are no assignment operators in the expression evaluator - assignments are handled separately using the existing constructs.

Built in Performance Monitor

3DMigoto now has a built-in performance monitor that can be activated by pressing Ctrl+F9 (with the latest d3dx.ini template) to show 3DMigoto's performance overhead. There are three pages that can be cycled between - a summary page of key performance areas, a list of top command lists, and a list of top commands.

The pages are updated every two seconds (by default), but can be frozen by pressing Shift+F9 to allow for closer examination. Freezing the display will also dump it to the d3d11_log.txt if you want to drill into it in more detail or copy & paste some of it for a bug report.

Only 3DMigoto's CPU overhead is monitored at present - I would like to also monitor GPU performance (in particular to highlight expensive arbitrary resource copy operations), however doing so in and of itself actually costs an enormous amount of performance.

The performance monitor will show the average time spent in each monitored area every frame, and an estimation of how many frames per second that could be costing. The estimation is based on the assumption that the game required a full 100% CPU time to only just manage to hit 60fps, and any CPU time we take will reduce that. This is only an estimation, and the actual cost may be more or less - if your system is fast enough that it had CPU time to spare you may not see any fps hit, but keep in mind that a system with a slower CPU could have higher costs than yours.

Summary Page:
Image

  • Present overhead: Shows the overhead that 3DMigoto is adding to every present call. This will include the time spent in the [Present] command list, processing key input, updating presets and transitions, but not the time spent in the overlay.

  • Overlay overhead: Shows the time 3DMigoto is spending to draw the overlay each frame, which will also include the profiling overlay itself, so you can pretty much ignore this as the overhead will drop to near zero when you aren't watching it.

  • Draw call overhead: Shows the total overhead that 3DMigoto is adding to the draw calls each frame. This will include the overhead of looking up the active shaders in the [ShaderOverride] sections and executing their command lists, as well as the legacy partner and depth filters, hunting mode skips and deferred ShaderRegex processing.

  • Command lists overhead: Shows the total time consumed by all currently active command lists each frame, which will typically add up to be the bulk of the cost in the present and draw calls.

  • Map/Unmap overhead: Shows the total overhead that 3DMigoto is adding to the Map/Unmap calls each frame. This includes part of the hash tracking & contamination overhead and deny_cpu_read (also, for Hellblade it would include the constant buffer detection overhead, but that functionality is not in the master branch as yet). There are typically a lot of map/unmap calls each frame, so this overhead can add up.

  • track_texture_updates: Shows overhead being paid for the hash tracking and contamination detection. In release mode this will be 0 if hash tracking is disabled, but in hunting mode there will always be a small overhead for the contamination detection, which is responsible for adding the !H! warnings in frame analysis filenames and hash_contaminated warnings in ShaderUsage.txt to indicate when hash tracking may be required. If you are certain that you don't need these warnings, you can now set track_texture_updates to 2 to disable this in hunting mode as well, but this practice is discouraged while developing a fix.

  • dump_usage overhead: Shows the overhead being paid collecting stats for the ShaderUsage.txt file. This overhead is only paid when the hunting overlay is actually being displayed (hunting=1), and can be eliminated by setting dump_usage=0 at the cost of losing the ShaderUsage.txt feature


Top Command Lists Page:
Image

This page shows all currently active command lists that are taking some CPU time, sorted so that the most expensive command lists are near the top. Command lists that contain both "pre" and "post" commands (explicitly or implicitly) will show up as two separate lists on this page.

The count column indicates how many times that list executed per frame (on average, rounded up) during the last collection interval. Likewise the times show the average time each list is costing per frame.

The difference between the inclusive and exclusive times, is that the inclusive times will include costs of other command lists that are called by this command list (e.g. by the run= and checktextureoverride= commands, if/else/endif flow control, etc), while the exclusive times shows only the time spent in that specific command list.

e.g. In the above screenshot the [Present] section is taking 294.05 microseconds/frame with an estimated cost of 1fps, but only 40 microseconds are spent in the [Present] command list itself - the remainder of that time is spend in other command lists called from there, with the bulk of that coming from [CustomShaderAutoConvergenceIntermediateDownscale] which costs 0.4fps by itself.

Note that the command lists for the [CustomShader] sections do not include some of the additional overhead that those sections cost to set up the render state and restore it again afterwards, though that will be included in the corresponding run= command in the top commands display.

[ShaderRegex] sections that included command lists will show up multiple times - there will be a single [ShaderRegex] section for the actual command list, and every active matching Shader will also have a separate command list with a .Match=<hash> suffix that links to the main command list, and the time spent in each is reflected in the inclusive/exclusive columns. If the ShaderRegex section does not contain any commands these command lists will not be created.

Only active command lists with at least one command are shown on this display - there may still be a small cost associated with looking up a command list only to find that it is empty and there is nothing to do that is not shown here, and most of that will come from the ShaderOverride lookups.

Top Commands Page:
Image

This page shows how much CPU time the individual commands in the command lists are costing and a breakdown of how much time was spent. There is no breakdown of inclusive vs exclusive time on this page - all times shown for commands that call other command lists will include the time spent in the called command list(s).

The times are broken down into "pre" and "post" columns, showing whether that command was active in "pre" or "post" command lists, or both. Sometimes a command that appears in both lists may show as costing more in the "pre" section than it does in the "post" section even if it is performing the exact same work in each - this is typically due to CPU caching effects, and the "post" version had the benefit that the cache was still hot from the earlier execution of the "pre" version.

If you see a command showing up with times in the "post" column that doesn't actually need to be post, you may consider explicitly marking it as a "pre" command, which may allow 3DMigoto to optimise out the entire post command list, and if that command was inside a [TextureOverride] section this may contribute to allowing 3DMigoto to optimise out every implicit "post checktextureoverride" command (which will only happen when every [TextureOverride] section is void of all post commands).

Note that you may see frame analysis "dump" and "analyse_options" commands taking up a small amount of time - these are automatically optimised out in release mode (or when no analyse_frame key is bound) and are nothing to worry about.

Misc
  • At request of DJ-RK, marking mode can now be cycled between skip, original, pink and mono by holding the numpad . while pressing numpad 0 (next_marking_mode config option), and the current marking mode is displayed in the overlay. Zero marking mode is currently excluded, due to unresolved bugs (crashes) in that mode.

  • In the template d3dx.ini, compute, domain, geometry and hull shader hunting key bindings are now set to holding numpad dot and pressing the various other numpad buttons - we are effectively using numpad dot as a modifier key to do more with the keys available on the numpad

  • Preset sections are now always processed in a consistent order (case insensitive alphabetical) to ensure that we will get consistent results if multiple Preset sections affect the same parameter

  • Fixed incorrect instructions in mod conflict warning about duplicate ShaderOverride hashes

  • When copying an index or vertex buffer, 3DMigoto will no longer strip off the initial part of the data before the draw call's first vertex/index (the buffer offset part will still be stripped off if performing a full copy). This allows these buffers to be reliably backed up by reference and re-bound later, in much the same way that we often back up and rebind textures. However, this could potentially break cases where these buffers have been copied into a shader resource and accessed from the shader if a first vertex/index was in use. I think in most cases we will be fine - there are only a few fixes that even access these buffers in this way, and it's unlikely that they were relying on this, and if we need it we can re-implement this in a different way (views) that will work for both cases.

  • reset_per_frame_limits is now correctly namespaced

  • clear command now correctly propagates final specified value to other channels (e.g. "clear = bb 1" will now clear the back buffer with white - before it would incorrectly clear it with red)

  • Command lists now automatically optimise out commands with no effect, such as calling run= on an empty command list (e.g. post lists), updating the separation or convergence when 3D Vision is disbled in the control panel or on AMD systems, frame analysis commands when in release mode, if conditionals where the expression could be statically evaluated to false (e.g. "if stereo_active" when 3D Vision is unavailable or "if sli" in single GPU mode), and will optimise out the implicit post checktextureoverride commands if no TextureOverride section has any post commands

  • Several small performance improvements

2x Geforce GTX 980 in SLI provided by NVIDIA, i7 6700K 4GHz CPU, Asus 27" VG278HE 144Hz 3D Monitor, BenQ W1070 3D Projector, 120" Elite Screens YardMaster 2, 32GB Corsair DDR4 3200MHz RAM, Samsung 850 EVO 500G SSD, 4x750GB HDD in RAID5, Gigabyte Z170X-Gaming 7 Motherboard, Corsair Obsidian 750D Airflow Edition Case, Corsair RM850i PSU, HTC Vive, Win 10 64bit

Alienware M17x R4 w/ built in 3D, Intel i7 3740QM, GTX 680m 2GB, 16GB DDR3 1600MHz RAM, Win7 64bit, 1TB SSD, 1TB HDD, 750GB HDD

Pre-release 3D fixes, shadertool.py and other goodies: http://github.com/DarkStarSword/3d-fixes
Support me on Patreon: https://www.patreon.com/DarkStarSword or PayPal: https://www.paypal.me/DarkStarSword

Posted 04/30/2018 05:38 PM   
Wow! This looks amazing, and the possibilities seem to be vastly extended! This must have took incredible effort DarkStarSword. We are all in your debt!
Wow!

This looks amazing, and the possibilities seem to be vastly extended! This must have took incredible effort DarkStarSword. We are all in your debt!

Windows 10 64-bit, Intel 7700K @ 5.1GHz, 16GB 3600MHz CL15 DDR4 RAM, 2x GTX 1080 SLI, Asus Maximus IX Hero, Sound Blaster ZxR, PCIe Quad SSD, Oculus Rift CV1, DLP Link PGD-150 glasses, ViewSonic PJD6531w 3D DLP Projector @ 1280x800 120Hz native / 2560x1600 120Hz DSR 3D Gaming.

Posted 04/30/2018 05:47 PM   
What an overhaul, Simply incredible work DSS !! You are so many levels above the crowd - THANK YOU so much for keeping our favorite tech alive !!
What an overhaul, Simply incredible work DSS !!

You are so many levels above the crowd - THANK YOU so much for keeping our favorite tech alive !!

Win7 64bit Pro
CPU: 4790K 4.8 GHZ
GPU: Asus Geforce RTX 2080 TI Rog Strix OC
Monitor: Asus PG278QR
And lots of ram and HD's ;)

Posted 04/30/2018 06:02 PM   
That's incredible DSS, thanks for all your efforts as usual. You should be very proud! I'm sure I remember reading a while back that you set yourself a goal of being the best at something and that happened to be this, but you continue to surpass yourself! No pressure :-) And thanks to all the other contributors on this amazing project.
That's incredible DSS, thanks for all your efforts as usual. You should be very proud! I'm sure I remember reading a while back that you set yourself a goal of being the best at something and that happened to be this, but you continue to surpass yourself! No pressure :-)

And thanks to all the other contributors on this amazing project.

Gigabyte RTX2080TI Gaming OC, I7-6700k ~ 4.4Ghz, 3x BenQ XL2420T, BenQ TK800, LG 55EG960V (3D OLED), Samsung 850 EVO SSD, Crucial M4 SSD, 3D vision kit, Xpand x104 glasses, Corsair HX1000i, Win 10 pro 64/Win 7 64https://www.3dmark.com/fs/9529310

Posted 04/30/2018 06:28 PM   
  133 / 143    
Scroll To Top