[quote="Andyy"]Hey Guys,
I have a short question. Is there a problem with 3D Migoto and SLI scaling? Because I had a few Games after applying the 3D fixes using 3D Migoto my SLI scaling went down from 90-99% to 50-60%.
Is there any way to fix this?
Thank you in advance![/quote]
There isn't any problem. What you are experiencing is called SLI-SYNC and you always want that one ON.
You should see the exact same behavior, when you remove the fix and just play the game using 3D Vision.
If with 3D Vision on you have 99% usage across gpus, but when you copy the 3d fix and using 3D Vision you get 50-60% gpu usage, then there is a problem.
But somehow, those numbers looks like you compared 2D vs 3D.
I have a short question. Is there a problem with 3D Migoto and SLI scaling? Because I had a few Games after applying the 3D fixes using 3D Migoto my SLI scaling went down from 90-99% to 50-60%.
Is there any way to fix this?
Thank you in advance!
There isn't any problem. What you are experiencing is called SLI-SYNC and you always want that one ON.
You should see the exact same behavior, when you remove the fix and just play the game using 3D Vision.
If with 3D Vision on you have 99% usage across gpus, but when you copy the 3d fix and using 3D Vision you get 50-60% gpu usage, then there is a problem.
But somehow, those numbers looks like you compared 2D vs 3D.
1x Palit RTX 2080Ti Pro Gaming OC(watercooled and overclocked to hell)
3x 3D Vision Ready Asus VG278HE monitors (5760x1080).
Intel i9 9900K (overclocked to 5.3 and watercooled ofc).
Asus Maximus XI Hero Mobo.
16 GB Team Group T-Force Dark Pro DDR4 @ 3600.
Lots of Disks:
- Raid 0 - 256GB Sandisk Extreme SSD.
- Raid 0 - WD Black - 2TB.
- SanDisk SSD PLUS 480 GB.
- Intel 760p 256GB M.2 PCIe NVMe SSD.
Creative Sound Blaster Z.
Windows 10 x64 Pro.
etc
[quote="Helifax"][quote="Andyy"]Hey Guys,
I have a short question. Is there a problem with 3D Migoto and SLI scaling? Because I had a few Games after applying the 3D fixes using 3D Migoto my SLI scaling went down from 90-99% to 50-60%.
Is there any way to fix this?
Thank you in advance![/quote]
There isn't any problem. What you are experiencing is called SLI-SYNC and you always want that one ON.
You should see the exact same behavior, when you remove the fix and just play the game using 3D Vision.
If with 3D Vision on you have 99% usage across gpus, but when you copy the 3d fix and using 3D Vision you get 50-60% gpu usage, then there is a problem.
But somehow, those numbers looks like you compared 2D vs 3D.[/quote]
No I compared 3D and 3D with fix.
For Example Middle-Earth: Shadow of Mordor:
3D (without fix) Ultra Settings 6000x1080 (Surround Resolution with bezel correction)=
90-99% SLI Scaling = Average ~60fps
3D with fix Ultra Settings 6000x1080 (Surround Resolution with bezel correction)=
50-60% SLI Scaling = Average ~28fps
Without fix it looks horrible...
With fix version 1.1.16_v2 I get 90-99% SLI Scaling and Average ~60fps but after 2 Minutes Game Crashes. Currently I am playing in 2D Surround with 90-99% Scaling and 100-115 fps.
It really seems to be a 3D Migoto problem...
Any solution?
I have a short question. Is there a problem with 3D Migoto and SLI scaling? Because I had a few Games after applying the 3D fixes using 3D Migoto my SLI scaling went down from 90-99% to 50-60%.
Is there any way to fix this?
Thank you in advance!
There isn't any problem. What you are experiencing is called SLI-SYNC and you always want that one ON.
You should see the exact same behavior, when you remove the fix and just play the game using 3D Vision.
If with 3D Vision on you have 99% usage across gpus, but when you copy the 3d fix and using 3D Vision you get 50-60% gpu usage, then there is a problem.
But somehow, those numbers looks like you compared 2D vs 3D.
No I compared 3D and 3D with fix.
For Example Middle-Earth: Shadow of Mordor:
3D (without fix) Ultra Settings 6000x1080 (Surround Resolution with bezel correction)=
90-99% SLI Scaling = Average ~60fps
3D with fix Ultra Settings 6000x1080 (Surround Resolution with bezel correction)=
50-60% SLI Scaling = Average ~28fps
Without fix it looks horrible...
With fix version 1.1.16_v2 I get 90-99% SLI Scaling and Average ~60fps but after 2 Minutes Game Crashes. Currently I am playing in 2D Surround with 90-99% Scaling and 100-115 fps.
Comment out this line in the d3dx.ini:
[code]run = CustomShader3DVision2SBS[/code]
@All Shaderhackers, please don't ship any fixes with this enabled - leave that to users to enable it if they want it. The SBS output modes rely on using the reverse stereo blit (stereo2mono), which doesn't scale well in SLI at resolutions above 1920x1080 because we hit the bandwidth limit on the SLI bus, and this performance hit will be incurred if the shader is enabled, even if the output mode is set to normal.
A future version of 3DMigoto will improve this so the performance hit is only incurred when an alternate output mode is enabled, and the performance hit will be halved (eliminating it entirely is not possible), but for now keep the option off when shipping fixes.
@All Shaderhackers, please don't ship any fixes with this enabled - leave that to users to enable it if they want it. The SBS output modes rely on using the reverse stereo blit (stereo2mono), which doesn't scale well in SLI at resolutions above 1920x1080 because we hit the bandwidth limit on the SLI bus, and this performance hit will be incurred if the shader is enabled, even if the output mode is set to normal.
A future version of 3DMigoto will improve this so the performance hit is only incurred when an alternate output mode is enabled, and the performance hit will be halved (eliminating it entirely is not possible), but for now keep the option off when shipping fixes.
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
Hunting doesn't work with 3DMigoto in the Elex game (see steam).
After doing some binary chopping, last working 3DMigoto version for this game is 1.1.14:
https://github.com/bo3b/3Dmigoto/releases?after=1.1.27
Version 1.1.16 is the first one from the Releases to be broken;) It dumps shaders as seen in log and in the actual ShaderCache but we cannot cycle them:(
Maybe this will help in the future;) ?
Version 1.1.16 is the first one from the Releases to be broken;) It dumps shaders as seen in log and in the actual ShaderCache but we cannot cycle them:(
Maybe this will help in the future;) ?
1x Palit RTX 2080Ti Pro Gaming OC(watercooled and overclocked to hell)
3x 3D Vision Ready Asus VG278HE monitors (5760x1080).
Intel i9 9900K (overclocked to 5.3 and watercooled ofc).
Asus Maximus XI Hero Mobo.
16 GB Team Group T-Force Dark Pro DDR4 @ 3600.
Lots of Disks:
- Raid 0 - 256GB Sandisk Extreme SSD.
- Raid 0 - WD Black - 2TB.
- SanDisk SSD PLUS 480 GB.
- Intel 760p 256GB M.2 PCIe NVMe SSD.
Creative Sound Blaster Z.
Windows 10 x64 Pro.
etc
[quote="bo3b"][quote="Helifax"]Thank you Bo3b.
I did try with the default initially. However, if I don't have allow_platform_update, I get an error, that It requires Windows & with SP1 patch installed. This seems to go away if I use allow_platform_update :(
I think I tried all of the combinations and neither worked:) All of them failed on CreatedDevice:)
I will retry it again this evening just to be sure:)
[/quote]
OK, that would not be platform_update though, that would be SP1, which is the default on Win7 today. That means it was mad about us returning an error, and/or the wrong DX11 class.
Since allow_create_device=2 is now default, that suggests trying allow_create_device=1 would be most likely to work. If that fails, then it's worth trying =2, but then add hook=recommended.
Always possible it genuinely requires platform update, but the error message does not imply that.
[/quote]
Unfortunately is not the SP1 is complaining about, but the platform update:( Sorry, if I wasn't correct initially :(
[img]https://forums.geforce.com/cmd/default/download-comment-attachment/73889/[/img]
Is basically the damn 11.1 feature set:)
Funny enough, all the Frostbite 3 games require DX 11.1 to work (MEA, BF1, DAO, and so on. I know this for a fact).
I am not sure what is wrong here though... Except that 3DMigoto doesn't support DXGIFactory2 properly?
Sorry, I don't want to be ignorant or anything, but I didn't look in the source code to see it exactly and hence the moronic question ^_^
I did try with the default initially. However, if I don't have allow_platform_update, I get an error, that It requires Windows & with SP1 patch installed. This seems to go away if I use allow_platform_update :(
I think I tried all of the combinations and neither worked:) All of them failed on CreatedDevice:)
I will retry it again this evening just to be sure:)
OK, that would not be platform_update though, that would be SP1, which is the default on Win7 today. That means it was mad about us returning an error, and/or the wrong DX11 class.
Since allow_create_device=2 is now default, that suggests trying allow_create_device=1 would be most likely to work. If that fails, then it's worth trying =2, but then add hook=recommended.
Always possible it genuinely requires platform update, but the error message does not imply that.
Unfortunately is not the SP1 is complaining about, but the platform update:( Sorry, if I wasn't correct initially :(
Is basically the damn 11.1 feature set:)
Funny enough, all the Frostbite 3 games require DX 11.1 to work (MEA, BF1, DAO, and so on. I know this for a fact).
I am not sure what is wrong here though... Except that 3DMigoto doesn't support DXGIFactory2 properly?
Sorry, I don't want to be ignorant or anything, but I didn't look in the source code to see it exactly and hence the moronic question ^_^
1x Palit RTX 2080Ti Pro Gaming OC(watercooled and overclocked to hell)
3x 3D Vision Ready Asus VG278HE monitors (5760x1080).
Intel i9 9900K (overclocked to 5.3 and watercooled ofc).
Asus Maximus XI Hero Mobo.
16 GB Team Group T-Force Dark Pro DDR4 @ 3600.
Lots of Disks:
- Raid 0 - 256GB Sandisk Extreme SSD.
- Raid 0 - WD Black - 2TB.
- SanDisk SSD PLUS 480 GB.
- Intel 760p 256GB M.2 PCIe NVMe SSD.
Creative Sound Blaster Z.
Windows 10 x64 Pro.
etc
[quote="Helifax"]Hunting doesn't work with 3DMigoto in the Elex game (see steam).
After doing some binary chopping, last working 3DMigoto version for this game is 1.1.14:
https://github.com/bo3b/3Dmigoto/releases?after=1.1.27
Version 1.1.16 is the first one from the Releases to be broken;) It dumps shaders as seen in log and in the actual ShaderCache but we cannot cycle them:(
Maybe this will help in the future;) ?[/quote]
That release suggests we aren't getting into DXGI in that game and can't get access to the present call (prior to that our "once per frame" actions including hunting were run from the clear render target call, which was a hack so we could work without DXGI). We'll need a log file to work out what this game is doing that is special.
Helifax said:Hunting doesn't work with 3DMigoto in the Elex game (see steam).
After doing some binary chopping, last working 3DMigoto version for this game is 1.1.14:
https://github.com/bo3b/3Dmigoto/releases?after=1.1.27
Version 1.1.16 is the first one from the Releases to be broken;) It dumps shaders as seen in log and in the actual ShaderCache but we cannot cycle them:(
Maybe this will help in the future;) ?
That release suggests we aren't getting into DXGI in that game and can't get access to the present call (prior to that our "once per frame" actions including hunting were run from the clear render target call, which was a hack so we could work without DXGI). We'll need a log file to work out what this game is doing that is special.
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
[quote="DarkStarSword"]Comment out this line in the d3dx.ini:
[code]run = CustomShader3DVision2SBS[/code]
@All Shaderhackers, please don't ship any fixes with this enabled - leave that to users to enable it if they want it. The SBS output modes rely on using the reverse stereo blit (stereo2mono), which doesn't scale well in SLI at resolutions above 1920x1080 because we hit the bandwidth limit on the SLI bus, and this performance hit will be incurred if the shader is enabled, even if the output mode is set to normal.
A future version of 3DMigoto will improve this so the performance hit is only incurred when an alternate output mode is enabled, and the performance hit will be halved (eliminating it entirely is not possible), but for now keep the option off when shipping fixes.[/quote]
This works! Thank you very much. Now running in 3D Surround 6000x1080 with 3D fix and Ultra settings with 45-60 fps and SLI Scaling 90-99%. Thank you "DarkStarSword".
DarkStarSword said:Comment out this line in the d3dx.ini:
run = CustomShader3DVision2SBS
@All Shaderhackers, please don't ship any fixes with this enabled - leave that to users to enable it if they want it. The SBS output modes rely on using the reverse stereo blit (stereo2mono), which doesn't scale well in SLI at resolutions above 1920x1080 because we hit the bandwidth limit on the SLI bus, and this performance hit will be incurred if the shader is enabled, even if the output mode is set to normal.
A future version of 3DMigoto will improve this so the performance hit is only incurred when an alternate output mode is enabled, and the performance hit will be halved (eliminating it entirely is not possible), but for now keep the option off when shipping fixes.
This works! Thank you very much. Now running in 3D Surround 6000x1080 with 3D fix and Ultra settings with 45-60 fps and SLI Scaling 90-99%. Thank you "DarkStarSword".
[quote="DarkStarSword"]Comment out this line in the d3dx.ini:
[code]run = CustomShader3DVision2SBS[/code]
@All Shaderhackers, please don't ship any fixes with this enabled - leave that to users to enable it if they want it. The SBS output modes rely on using the reverse stereo blit (stereo2mono), which doesn't scale well in SLI at resolutions above 1920x1080 because we hit the bandwidth limit on the SLI bus, and this performance hit will be incurred if the shader is enabled, even if the output mode is set to normal.
A future version of 3DMigoto will improve this so the performance hit is only incurred when an alternate output mode is enabled, and the performance hit will be halved (eliminating it entirely is not possible), but for now keep the option off when shipping fixes.[/quote]
Just FYI !!
With that setting enabled in ROTTR with the community fix, the whole game world rendered in 2D, while the emitter was lit and depht / convergence was working !
DarkStarSword said:Comment out this line in the d3dx.ini:
run = CustomShader3DVision2SBS
@All Shaderhackers, please don't ship any fixes with this enabled - leave that to users to enable it if they want it. The SBS output modes rely on using the reverse stereo blit (stereo2mono), which doesn't scale well in SLI at resolutions above 1920x1080 because we hit the bandwidth limit on the SLI bus, and this performance hit will be incurred if the shader is enabled, even if the output mode is set to normal.
A future version of 3DMigoto will improve this so the performance hit is only incurred when an alternate output mode is enabled, and the performance hit will be halved (eliminating it entirely is not possible), but for now keep the option off when shipping fixes.
Just FYI !!
With that setting enabled in ROTTR with the community fix, the whole game world rendered in 2D, while the emitter was lit and depht / convergence was working !
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 ;)
bo3b said:The problem here is that DXGI is not being hooked, probably because the game is loading DXGI earlier than we are, and thus we are locked out of the chain of hooks. Would be worth trying the DXGI loader that DarkStarSword posted about recently.
I tried out DarkStarSwords DXGI loader but it didn't changed anything.
Since you mentioned that the game may load DXGI earlier that 3Dmigoto, I checked the load order with process monitor. The 3Dmigoto dll is correctly loaded before any real d3d11 or DXGI dlls even without the DXGI loader.
bo3b said:Then run 1.0.1 to hunt the shaders you need. You won't want the fixed file, just the shader hash. You can then use the corresponding file from the 1.2.65 dump to work on it.
Unfortunately, this is not possible because version 1.0.1 didn't catch the broken shaders during hunting. I would need frame analysis here which is first available in experimental build 1.1.17 that does not work in ELEX.
DarkStarSword said:That release suggests we aren't getting into DXGI in that game and can't get access to the present call (prior to that our "once per frame" actions including hunting were run from the clear render target call, which was a hack so we could work without DXGI). We'll need a log file to work out what this game is doing that is special.
I did some debugging and can confirm that HackerDXGISwapChain::Present does not get called from ELEX.
If you can tell me what to look for, I can do some more debugging on this.
Here is the 3Dmigoto log from the ELEX topic again:
D3D11 DLL starting init - v 1.2.65 - Wed Oct 18 17:10:52 2017
Hooked_LoadLibraryExW switching to original dll: original_nvapi64.dll to C:\Windows\system32\nvapi64.dll.
NVIDIA driver version 358.87 (branch r358_00)
Looking up profiles related to D:\ELEX\system\ELEX.exe
----------- Driver profile settings -----------
BaseProfile "Base Profile"
SelectedGlobalProfile "Base Profile"
----------- End driver profile settings -----------
No profile update required
*** D3D11 DLL successfully initialized. ***
Trying to load original_d3d11.dll
Hooked_LoadLibraryExW switching to original dll: original_d3d11.dll to C:\Windows\system32\d3d11.dll.
Hooked_CreateDXGIFactory1 called with riid: IDXGIFactory1
calling original CreateDXGIFactory1 API
CreateDXGIFactory1 returned factory = 00000000004A92B0, result = 0
new HackerDXGIFactory1(class HackerDXGIFactory1@0000000004E63F60) wrapped 00000000004A92B0
HackerDXGIFactory1::EnumAdapters1(class HackerDXGIFactory1@0000000004E63F60) adapter 0 requested
created HackerDXGIAdapter1 wrapper = 0000000004E63F00 of 000000000045BD00
returns result = 0
HackerUnknown::AddRef(class HackerDXGIAdapter1@0000000004E63F00), counter=2, this=0000000004E63F00
HackerUnknown::Release(class HackerDXGIAdapter1@0000000004E63F00), counter=1, this=0000000004E63F00
@mx-2: That's interesting that it does look like d3d11.dll is loaded properly from the game directory, and then dxgi is loaded from system like we'd expect.
Please run it again with full debugging enabled, and we'll take a look:
calls=1
input=1
debug=1
unbuffered=1
@mx-2: That's interesting that it does look like d3d11.dll is loaded properly from the game directory, and then dxgi is loaded from system like we'd expect.
Please run it again with full debugging enabled, and we'll take a look:
calls=1
input=1
debug=1
unbuffered=1
Acer H5360 (1280x720@120Hz) - ASUS VG248QE with GSync mod - 3D Vision 1&2 - Driver 372.54
GTX 970 - i5-4670K@4.2GHz - 12GB RAM - Win7x64+evilKB2670838 - 4 Disk X25 RAID
SAGER NP9870-S - GTX 980 - i7-6700K - Win10 Pro 1607 Latest 3Dmigoto Release Bo3b's School for ShaderHackers
3Dmigoto is making a performance difference in Grim Dawn when I'm CPU limited. In the starting town (after it has been populated a lot and I summon all my minions, being a necromancer), without 3Dmigoto I get 56fps in a specific location. With 3Dmigoto, 46fps. That's a ~20% difference.
I tried disabling all logging, hunting, tried both scissor clipping options, disabled the mouse cursor shader, removed all my shaders, removed the render target stereoization... and fps remained the same.
I guess that will be the price of having a game with correct 3D :(.
The lowest fps I saw during big fights was 33fps, with my 7700K at 4.9GHz (the game mostly uses 1 core). I didn't compare it with 3Dmigoto disabled.
3Dmigoto is making a performance difference in Grim Dawn when I'm CPU limited. In the starting town (after it has been populated a lot and I summon all my minions, being a necromancer), without 3Dmigoto I get 56fps in a specific location. With 3Dmigoto, 46fps. That's a ~20% difference.
I tried disabling all logging, hunting, tried both scissor clipping options, disabled the mouse cursor shader, removed all my shaders, removed the render target stereoization... and fps remained the same.
I guess that will be the price of having a game with correct 3D :(.
The lowest fps I saw during big fights was 33fps, with my 7700K at 4.9GHz (the game mostly uses 1 core). I didn't compare it with 3Dmigoto disabled.
I have to add that with my first WIP fix (3Dmigoto 1.2.57 instead of the 1.2.65 my newer fix uses), I get 49-50 fps there. Still lower than without 3Dmigoto, but somehow performance got worse since then.
I have to add that with my first WIP fix (3Dmigoto 1.2.57 instead of the 1.2.65 my newer fix uses), I get 49-50 fps there. Still lower than without 3Dmigoto, but somehow performance got worse since then.
I have a suspicion as to what may have caused that (buffer hashes) - can you test 1.2.62 and 1.2.63 with hunting disabled? If I'm right you will see a performance difference between them, and if not comparing it with 1.2.57 and 1.2.65 will at least help narrow down where it was introduced.
Also, see if you get any performance difference while holding the show_original key (hunting must be enabled) - that's the trick I was using to track down some of the performance problems in Dreamfall Chapters. If you do see a difference here, it would point to either something in the shaders or command lists (such as excessive full resource copies or inefficiencies in decompiled & recompiled shaders), which is not necessarily 3DMigoto's fault.
I have a suspicion as to what may have caused that (buffer hashes) - can you test 1.2.62 and 1.2.63 with hunting disabled? If I'm right you will see a performance difference between them, and if not comparing it with 1.2.57 and 1.2.65 will at least help narrow down where it was introduced.
Also, see if you get any performance difference while holding the show_original key (hunting must be enabled) - that's the trick I was using to track down some of the performance problems in Dreamfall Chapters. If you do see a difference here, it would point to either something in the shaders or command lists (such as excessive full resource copies or inefficiencies in decompiled & recompiled shaders), which is not necessarily 3DMigoto's fault.
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
Yes, those two versions show a difference.
1.2.62: 49fps
1.2.63: 45-46fps
When the hunting OSD is there, fps drops to 37fps. If I hold F9 with my latest fix (1.2.65), they increase to 39fps (the fps I get with a fresh 3Dmigoto in both .62 and .63 versions with hunting enabled). With older versions of 3Dmigoto, where I don't have custom shaders, pressing F9 doesn't make any difference, after getting the big drop of enabling the OSD.
When the hunting OSD is there, fps drops to 37fps. If I hold F9 with my latest fix (1.2.65), they increase to 39fps (the fps I get with a fresh 3Dmigoto in both .62 and .63 versions with hunting enabled). With older versions of 3Dmigoto, where I don't have custom shaders, pressing F9 doesn't make any difference, after getting the big drop of enabling the OSD.
Ok, thanks for that. I'm pretty sure it's the [index] buffer hash, which was re-enabled in that release - I was concerned when I saw that had gone in, because the hashes can be expensive, and while most games tend to restrict most texture creation to loading times so we get away with that, they can be a bit more liberal on creating buffers whenever they feel like. The buffer hash is still broken anyway, because it's not hooked up to anything that can make use of it - I'll try to fix that up so it works for 1.2.66 and probably add an option or something to restrict it to specific types of buffers that we actually want, which in 99% of cases will be none.
The fps drop you see when the OSD is enabled will be due to the statistics collection (the info that ends up in shader_usage.txt when you dump something), which is known to be expensive (some games are worse than others - this sounds like a particularly bad case) so we limit it to only happen when hunting is fully enabled with the OSD shown. I've thought about adding an option for this specific thing, but turning off the OSD has usually been good enough, so unless you want one I'd rather leave that as is. Edit: I forgot that I had already done this - turning off the export_usage option will recover most of this.
The 2fps difference you see while holding F9 is likely to be something in the fix itself - that might be something you just accept as the cost of having working 3D, or you could try to narrow down if there is something specific contributing to it, like custom shaders as you mentioned, or using HLSL instead of assembly, or resource copies, or something else, and then work out if there is some way to improve it. FWIW in Dreamfall Chapters I managed to recover about 20fps by switching to assembly and eliminating excessive resource copies, but I was still about 1-2fps lower than show_original (a little more if there were light shafts in the current scene), which I decided was good enough. Worth keeping in mind that some optimisations won't make any noticeable difference so make sure you have identified where the performance hit is coming from before you try to optimise, e.g. in Dreamfall Chapters I wondered whether eliminating a matrix multiply in a few thousand shaders might make a difference, but I couldn't see any difference - if there was one it was less than 1fps.
Ok, thanks for that. I'm pretty sure it's the [index] buffer hash, which was re-enabled in that release - I was concerned when I saw that had gone in, because the hashes can be expensive, and while most games tend to restrict most texture creation to loading times so we get away with that, they can be a bit more liberal on creating buffers whenever they feel like. The buffer hash is still broken anyway, because it's not hooked up to anything that can make use of it - I'll try to fix that up so it works for 1.2.66 and probably add an option or something to restrict it to specific types of buffers that we actually want, which in 99% of cases will be none.
The fps drop you see when the OSD is enabled will be due to the statistics collection (the info that ends up in shader_usage.txt when you dump something), which is known to be expensive (some games are worse than others - this sounds like a particularly bad case) so we limit it to only happen when hunting is fully enabled with the OSD shown. I've thought about adding an option for this specific thing, but turning off the OSD has usually been good enough, so unless you want one I'd rather leave that as is. Edit: I forgot that I had already done this - turning off the export_usage option will recover most of this.
The 2fps difference you see while holding F9 is likely to be something in the fix itself - that might be something you just accept as the cost of having working 3D, or you could try to narrow down if there is something specific contributing to it, like custom shaders as you mentioned, or using HLSL instead of assembly, or resource copies, or something else, and then work out if there is some way to improve it. FWIW in Dreamfall Chapters I managed to recover about 20fps by switching to assembly and eliminating excessive resource copies, but I was still about 1-2fps lower than show_original (a little more if there were light shafts in the current scene), which I decided was good enough. Worth keeping in mind that some optimisations won't make any noticeable difference so make sure you have identified where the performance hit is coming from before you try to optimise, e.g. in Dreamfall Chapters I wondered whether eliminating a matrix multiply in a few thousand shaders might make a difference, but I couldn't see any difference - if there was one it was less than 1fps.
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
There isn't any problem. What you are experiencing is called SLI-SYNC and you always want that one ON.
You should see the exact same behavior, when you remove the fix and just play the game using 3D Vision.
If with 3D Vision on you have 99% usage across gpus, but when you copy the 3d fix and using 3D Vision you get 50-60% gpu usage, then there is a problem.
But somehow, those numbers looks like you compared 2D vs 3D.
1x Palit RTX 2080Ti Pro Gaming OC(watercooled and overclocked to hell)
3x 3D Vision Ready Asus VG278HE monitors (5760x1080).
Intel i9 9900K (overclocked to 5.3 and watercooled ofc).
Asus Maximus XI Hero Mobo.
16 GB Team Group T-Force Dark Pro DDR4 @ 3600.
Lots of Disks:
- Raid 0 - 256GB Sandisk Extreme SSD.
- Raid 0 - WD Black - 2TB.
- SanDisk SSD PLUS 480 GB.
- Intel 760p 256GB M.2 PCIe NVMe SSD.
Creative Sound Blaster Z.
Windows 10 x64 Pro.
etc
My website with my fixes and OpenGL to 3D Vision wrapper:
http://3dsurroundgaming.com
(If you like some of the stuff that I've done and want to donate something, you can do it with PayPal at tavyhome@gmail.com)
No I compared 3D and 3D with fix.
For Example Middle-Earth: Shadow of Mordor:
3D (without fix) Ultra Settings 6000x1080 (Surround Resolution with bezel correction)=
90-99% SLI Scaling = Average ~60fps
3D with fix Ultra Settings 6000x1080 (Surround Resolution with bezel correction)=
50-60% SLI Scaling = Average ~28fps
Without fix it looks horrible...
With fix version 1.1.16_v2 I get 90-99% SLI Scaling and Average ~60fps but after 2 Minutes Game Crashes. Currently I am playing in 2D Surround with 90-99% Scaling and 100-115 fps.
It really seems to be a 3D Migoto problem...
Any solution?
@All Shaderhackers, please don't ship any fixes with this enabled - leave that to users to enable it if they want it. The SBS output modes rely on using the reverse stereo blit (stereo2mono), which doesn't scale well in SLI at resolutions above 1920x1080 because we hit the bandwidth limit on the SLI bus, and this performance hit will be incurred if the shader is enabled, even if the output mode is set to normal.
A future version of 3DMigoto will improve this so the performance hit is only incurred when an alternate output mode is enabled, and the performance hit will be halved (eliminating it entirely is not possible), but for now keep the option off when shipping fixes.
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
After doing some binary chopping, last working 3DMigoto version for this game is 1.1.14:
https://github.com/bo3b/3Dmigoto/releases?after=1.1.27
Version 1.1.16 is the first one from the Releases to be broken;) It dumps shaders as seen in log and in the actual ShaderCache but we cannot cycle them:(
Maybe this will help in the future;) ?
1x Palit RTX 2080Ti Pro Gaming OC(watercooled and overclocked to hell)
3x 3D Vision Ready Asus VG278HE monitors (5760x1080).
Intel i9 9900K (overclocked to 5.3 and watercooled ofc).
Asus Maximus XI Hero Mobo.
16 GB Team Group T-Force Dark Pro DDR4 @ 3600.
Lots of Disks:
- Raid 0 - 256GB Sandisk Extreme SSD.
- Raid 0 - WD Black - 2TB.
- SanDisk SSD PLUS 480 GB.
- Intel 760p 256GB M.2 PCIe NVMe SSD.
Creative Sound Blaster Z.
Windows 10 x64 Pro.
etc
My website with my fixes and OpenGL to 3D Vision wrapper:
http://3dsurroundgaming.com
(If you like some of the stuff that I've done and want to donate something, you can do it with PayPal at tavyhome@gmail.com)
Unfortunately is not the SP1 is complaining about, but the platform update:( Sorry, if I wasn't correct initially :(
Is basically the damn 11.1 feature set:)
Funny enough, all the Frostbite 3 games require DX 11.1 to work (MEA, BF1, DAO, and so on. I know this for a fact).
I am not sure what is wrong here though... Except that 3DMigoto doesn't support DXGIFactory2 properly?
Sorry, I don't want to be ignorant or anything, but I didn't look in the source code to see it exactly and hence the moronic question ^_^
1x Palit RTX 2080Ti Pro Gaming OC(watercooled and overclocked to hell)
3x 3D Vision Ready Asus VG278HE monitors (5760x1080).
Intel i9 9900K (overclocked to 5.3 and watercooled ofc).
Asus Maximus XI Hero Mobo.
16 GB Team Group T-Force Dark Pro DDR4 @ 3600.
Lots of Disks:
- Raid 0 - 256GB Sandisk Extreme SSD.
- Raid 0 - WD Black - 2TB.
- SanDisk SSD PLUS 480 GB.
- Intel 760p 256GB M.2 PCIe NVMe SSD.
Creative Sound Blaster Z.
Windows 10 x64 Pro.
etc
My website with my fixes and OpenGL to 3D Vision wrapper:
http://3dsurroundgaming.com
(If you like some of the stuff that I've done and want to donate something, you can do it with PayPal at tavyhome@gmail.com)
That release suggests we aren't getting into DXGI in that game and can't get access to the present call (prior to that our "once per frame" actions including hunting were run from the clear render target call, which was a hack so we could work without DXGI). We'll need a log file to work out what this game is doing that is special.
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
This works! Thank you very much. Now running in 3D Surround 6000x1080 with 3D fix and Ultra settings with 45-60 fps and SLI Scaling 90-99%. Thank you "DarkStarSword".
Just FYI !!
With that setting enabled in ROTTR with the community fix, the whole game world rendered in 2D, while the emitter was lit and depht / convergence was working !
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 ;)
I tried out DarkStarSwords DXGI loader but it didn't changed anything.
Since you mentioned that the game may load DXGI earlier that 3Dmigoto, I checked the load order with process monitor. The 3Dmigoto dll is correctly loaded before any real d3d11 or DXGI dlls even without the DXGI loader.
Unfortunately, this is not possible because version 1.0.1 didn't catch the broken shaders during hunting. I would need frame analysis here which is first available in experimental build 1.1.17 that does not work in ELEX.
I did some debugging and can confirm that HackerDXGISwapChain::Present does not get called from ELEX.
If you can tell me what to look for, I can do some more debugging on this.
Here is the 3Dmigoto log from the ELEX topic again:
My 3D fixes with Helixmod for the Risen series on GitHub
Bo3b's School for Shaderhackers - starting point for your first 3D fix
Please run it again with full debugging enabled, and we'll take a look:
calls=1
input=1
debug=1
unbuffered=1
Acer H5360 (1280x720@120Hz) - ASUS VG248QE with GSync mod - 3D Vision 1&2 - Driver 372.54
GTX 970 - i5-4670K@4.2GHz - 12GB RAM - Win7x64+evilKB2670838 - 4 Disk X25 RAID
SAGER NP9870-S - GTX 980 - i7-6700K - Win10 Pro 1607
Latest 3Dmigoto Release
Bo3b's School for ShaderHackers
I tried disabling all logging, hunting, tried both scissor clipping options, disabled the mouse cursor shader, removed all my shaders, removed the render target stereoization... and fps remained the same.
I guess that will be the price of having a game with correct 3D :(.
The lowest fps I saw during big fights was 33fps, with my 7700K at 4.9GHz (the game mostly uses 1 core). I didn't compare it with 3Dmigoto disabled.
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
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
Also, see if you get any performance difference while holding the show_original key (hunting must be enabled) - that's the trick I was using to track down some of the performance problems in Dreamfall Chapters. If you do see a difference here, it would point to either something in the shaders or command lists (such as excessive full resource copies or inefficiencies in decompiled & recompiled shaders), which is not necessarily 3DMigoto's fault.
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
1.2.62: 49fps
1.2.63: 45-46fps
When the hunting OSD is there, fps drops to 37fps. If I hold F9 with my latest fix (1.2.65), they increase to 39fps (the fps I get with a fresh 3Dmigoto in both .62 and .63 versions with hunting enabled). With older versions of 3Dmigoto, where I don't have custom shaders, pressing F9 doesn't make any difference, after getting the big drop of enabling the OSD.
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
The fps drop you see when the OSD is enabled will be due to the statistics collection (the info that ends up in shader_usage.txt when you dump something), which is known to be expensive (some games are worse than others - this sounds like a particularly bad case) so we limit it to only happen when hunting is fully enabled with the OSD shown. I've thought about adding an option for this specific thing, but turning off the OSD has usually been good enough, so unless you want one I'd rather leave that as is. Edit: I forgot that I had already done this - turning off the export_usage option will recover most of this.
The 2fps difference you see while holding F9 is likely to be something in the fix itself - that might be something you just accept as the cost of having working 3D, or you could try to narrow down if there is something specific contributing to it, like custom shaders as you mentioned, or using HLSL instead of assembly, or resource copies, or something else, and then work out if there is some way to improve it. FWIW in Dreamfall Chapters I managed to recover about 20fps by switching to assembly and eliminating excessive resource copies, but I was still about 1-2fps lower than show_original (a little more if there were light shafts in the current scene), which I decided was good enough. Worth keeping in mind that some optimisations won't make any noticeable difference so make sure you have identified where the performance hit is coming from before you try to optimise, e.g. in Dreamfall Chapters I wondered whether eliminating a matrix multiply in a few thousand shaders might make a difference, but I couldn't see any difference - if there was one it was less than 1fps.
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