Far Cry 4 {3D Screenshots}
  27 / 28    
Hi guys;) Just updated to the latest version of the FIX and the HUD is broken is mostly 2D with some minor elements in 3D... The version from 2015 still works though...:) Just wanted to let you know:)
Hi guys;) Just updated to the latest version of the FIX and the HUD is broken is mostly 2D with some minor elements in 3D...

The version from 2015 still works though...:) Just wanted to let you know:)

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)

Posted 03/08/2016 09:50 PM   
I read that this game had stuttering issues when it first came out. Did ubisoft fix a lot of the performance issues that people complained about?
I read that this game had stuttering issues when it first came out. Did ubisoft fix a lot of the performance issues that people complained about?

Posted 03/08/2016 11:52 PM   
[quote="helifax"]Hi guys;) Just updated to the latest version of the FIX and the HUD is broken is mostly 2D with some minor elements in 3D... The version from 2015 still works though...:) Just wanted to let you know:)[/quote] Response is here for this issue: [url]https://forums.geforce.com/default/topic/883059/3d-vision/far-cry-primal/post/4829686/#4829686[/url]
helifax said:Hi guys;) Just updated to the latest version of the FIX and the HUD is broken is mostly 2D with some minor elements in 3D...

The version from 2015 still works though...:) Just wanted to let you know:)


Response is here for this issue:
https://forums.geforce.com/default/topic/883059/3d-vision/far-cry-primal/post/4829686/#4829686

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)

Posted 03/08/2016 11:59 PM   
[quote="tygeezy"]I read that this game had stuttering issues when it first came out. Did ubisoft fix a lot of the performance issues that people complained about?[/quote] And this is related to 3D Vision HOW exactly???
tygeezy said:I read that this game had stuttering issues when it first came out. Did ubisoft fix a lot of the performance issues that people complained about?


And this is related to 3D Vision HOW exactly???

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)

Posted 03/09/2016 12:00 AM   
[quote="helifax"][quote="tygeezy"]I read that this game had stuttering issues when it first came out. Did ubisoft fix a lot of the performance issues that people complained about?[/quote] And this is related to 3D Vision HOW exactly???[/quote]I'm getting a 3d vision kit. If the game exhibits poor performance in 2d mode; then you can be sure that it will have an issue in 3d mode as well.
helifax said:
tygeezy said:I read that this game had stuttering issues when it first came out. Did ubisoft fix a lot of the performance issues that people complained about?


And this is related to 3D Vision HOW exactly???
I'm getting a 3d vision kit. If the game exhibits poor performance in 2d mode; then you can be sure that it will have an issue in 3d mode as well.

Posted 03/09/2016 01:51 AM   
[quote="tygeezy"][quote="helifax"][quote="tygeezy"]I read that this game had stuttering issues when it first came out. Did ubisoft fix a lot of the performance issues that people complained about?[/quote] And this is related to 3D Vision HOW exactly???[/quote]I'm getting a 3d vision kit. If the game exhibits poor performance in 2d mode; then you can be sure that it will have an issue in 3d mode as well.[/quote] Ah right;) Well from what I've seen while testing (more than playing) the game behaves ok(-ish). I didn't see any stutters or so...but I might have been mistaken as I didn't pay attention to this..but it would have been something I would have picked on;)
tygeezy said:
helifax said:
tygeezy said:I read that this game had stuttering issues when it first came out. Did ubisoft fix a lot of the performance issues that people complained about?


And this is related to 3D Vision HOW exactly???
I'm getting a 3d vision kit. If the game exhibits poor performance in 2d mode; then you can be sure that it will have an issue in 3d mode as well.


Ah right;) Well from what I've seen while testing (more than playing) the game behaves ok(-ish). I didn't see any stutters or so...but I might have been mistaken as I didn't pay attention to this..but it would have been something I would have picked on;)

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)

Posted 03/09/2016 02:13 AM   
I think the performance issues got patched, but don't quote me on that. When it first came out everyone had to run it with textures set to medium or lower, but I don't think that is the case anymore. Right now it probably has more performance impact coming from 3DMigoto's texture hash tracking (which can be disabled in the d3dx.ini, but some HUD elements like the camera, clouds/vignette on the map, etc will break randomly - nothing too serious, the crosshair and main HUD icons seem to work without it). I have plans to address this, but it's ... complicated.
I think the performance issues got patched, but don't quote me on that. When it first came out everyone had to run it with textures set to medium or lower, but I don't think that is the case anymore.

Right now it probably has more performance impact coming from 3DMigoto's texture hash tracking (which can be disabled in the d3dx.ini, but some HUD elements like the camera, clouds/vignette on the map, etc will break randomly - nothing too serious, the crosshair and main HUD icons seem to work without it). I have plans to address this, but it's ... complicated.

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 03/09/2016 02:18 AM   
[quote="DarkStarSword"]I think the performance issues got patched, but don't quote me on that. When it first came out everyone had to run it with textures set to medium or lower, but I don't think that is the case anymore. Right now it probably has more performance impact coming from 3DMigoto's texture hash tracking (which can be disabled in the d3dx.ini, but some HUD elements like the camera, clouds/vignette on the map, etc will break randomly - nothing too serious, the crosshair and main HUD icons seem to work without it). I have plans to address this, but it's ... complicated.[/quote] If you need me to run some performance profiles, let me know. Unless they changed it, the free versions of Visual Studio did not include the performance profiler.
DarkStarSword said:I think the performance issues got patched, but don't quote me on that. When it first came out everyone had to run it with textures set to medium or lower, but I don't think that is the case anymore.

Right now it probably has more performance impact coming from 3DMigoto's texture hash tracking (which can be disabled in the d3dx.ini, but some HUD elements like the camera, clouds/vignette on the map, etc will break randomly - nothing too serious, the crosshair and main HUD icons seem to work without it). I have plans to address this, but it's ... complicated.

If you need me to run some performance profiles, let me know. Unless they changed it, the free versions of Visual Studio did not include the performance profiler.

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

Posted 03/09/2016 10:05 AM   
I'd appreciate that Bo3b. I'm expecting to see a significant amount of time spent in UpdateResourceHashFromCPU, either hashing the textures or perhaps entering the critical section (hmm, might be some low hanging fruit there as we could skip entering the critical section for buffers since we don't need to track them and they tend to be updated hundreds of time per frame), that can be entirely eliminated by setting track_texture_updates=0. Since I'm GPU bound I don't notice a significant impact, but a few people have reported a difference so I expect it will matter more for CPU bound players. It's also the type of thing that might cause stutter since it will have the most impact when the game actually updates a texture, which it does sporadically while running around the map. I've pushed a 'texture_hash_rework' topic branch with code that I started working on a couple of months back aiming to address that. The idea was to separate out the description and data hashes, and then in release mode we would only calculate a data hash if the description hash was present in the d3dx.ini, which could easily cut down on the number of hashes we need to calculate by 90% or more at a guess. While testing it I ran into an unrelated problem that was significant enough to put the rework on hold - at the moment the hashes are only calculated for the first mip-map level or subresource, and we only track updates to that subresource and copies between two resources that target that subresource on both source and destination, but it turns out that in some situations FC4 would copy e.g. mip-map level 1 of a 1024x1024 texture to mip-map level 0 of a 512x512 texture (or other variations thereof) which would mean that the texture hash we had calculated was no longer correct for the top level mip-map - this was causing problems for the climbing rope and repair tool detection (and will do so with or without the rework). My thinking at the moment is to do away with using a description hash, and replace it with a text string containing each of the fields of the description - if we want to keep it concise and easy to copy & paste from ShaderUsage / frame analysis it could be something like 2d-512-512-1-1-28-0-0-0-8-0-0 followed by the texture hash, or we could make it more verbose with separate fields like Helix Mod does. That could then allow 3DMigoto to check if a description in the d3dx.ini might match a mip-map level of a resource from the game and track that mip-map. We could also potentially allow a match on any mip-map level so that only a single hash needs to be found with texture quality set low (or maybe we could dump the hashes for all mip-map levels and match on any of them). That style could also allow us to use wildcards for some of the fields, which is something that has been handy in Helix Mod in a number of cases, but not super important. There is still an open question as to what to do with games that don't populate the mip-maps and ask DirectX to generate them instead (FC4 does not do this fortunately) - in that case we will have nothing to hash at texture creation time, and I don't even know if there is any guarantee that the data in the mip-map would always be consistent. Hopefully any games that do this won't ever copy data between different mip-map levels and we can just ignore this case. There is an alternative that I've started thinking about more and more - we could potentially calculate the hashes on demand. We would still track when the game updates each texture, but would only flag it's hash as invalid rather than recalculating it at the time. Then, in the texture filtering & checktextureoverride handlers we would have to go through a slow path and calculate the hash for any resources with an invalid hash. That wouldn't be great for performance when we need to do that since we would stall the pipeline while we fetch the data from the GPU, but this code is already optimised so that it only checks textures that it actually needs to, and most of the time their hashes would be valid, so the cost of hashing on demand might end up being better overall, but it's hard to say without actually trying it. Or, we could try calculating the hashes on the GPU - we can't exclusively switch to that because we still need the hashes on the CPU at texture creation time for the creation mode, width, height & format overrides, but we might be able to make it work for texture filtering (and perhaps even scene detection combined with writing to a custom resource), which could eliminate the need to track the hashes from the CPU.
I'd appreciate that Bo3b. I'm expecting to see a significant amount of time spent in UpdateResourceHashFromCPU, either hashing the textures or perhaps entering the critical section (hmm, might be some low hanging fruit there as we could skip entering the critical section for buffers since we don't need to track them and they tend to be updated hundreds of time per frame), that can be entirely eliminated by setting track_texture_updates=0.

Since I'm GPU bound I don't notice a significant impact, but a few people have reported a difference so I expect it will matter more for CPU bound players. It's also the type of thing that might cause stutter since it will have the most impact when the game actually updates a texture, which it does sporadically while running around the map.

I've pushed a 'texture_hash_rework' topic branch with code that I started working on a couple of months back aiming to address that. The idea was to separate out the description and data hashes, and then in release mode we would only calculate a data hash if the description hash was present in the d3dx.ini, which could easily cut down on the number of hashes we need to calculate by 90% or more at a guess.

While testing it I ran into an unrelated problem that was significant enough to put the rework on hold - at the moment the hashes are only calculated for the first mip-map level or subresource, and we only track updates to that subresource and copies between two resources that target that subresource on both source and destination, but it turns out that in some situations FC4 would copy e.g. mip-map level 1 of a 1024x1024 texture to mip-map level 0 of a 512x512 texture (or other variations thereof) which would mean that the texture hash we had calculated was no longer correct for the top level mip-map - this was causing problems for the climbing rope and repair tool detection (and will do so with or without the rework).

My thinking at the moment is to do away with using a description hash, and replace it with a text string containing each of the fields of the description - if we want to keep it concise and easy to copy & paste from ShaderUsage / frame analysis it could be something like 2d-512-512-1-1-28-0-0-0-8-0-0 followed by the texture hash, or we could make it more verbose with separate fields like Helix Mod does.

That could then allow 3DMigoto to check if a description in the d3dx.ini might match a mip-map level of a resource from the game and track that mip-map. We could also potentially allow a match on any mip-map level so that only a single hash needs to be found with texture quality set low (or maybe we could dump the hashes for all mip-map levels and match on any of them).

That style could also allow us to use wildcards for some of the fields, which is something that has been handy in Helix Mod in a number of cases, but not super important.

There is still an open question as to what to do with games that don't populate the mip-maps and ask DirectX to generate them instead (FC4 does not do this fortunately) - in that case we will have nothing to hash at texture creation time, and I don't even know if there is any guarantee that the data in the mip-map would always be consistent. Hopefully any games that do this won't ever copy data between different mip-map levels and we can just ignore this case.


There is an alternative that I've started thinking about more and more - we could potentially calculate the hashes on demand. We would still track when the game updates each texture, but would only flag it's hash as invalid rather than recalculating it at the time. Then, in the texture filtering & checktextureoverride handlers we would have to go through a slow path and calculate the hash for any resources with an invalid hash. That wouldn't be great for performance when we need to do that since we would stall the pipeline while we fetch the data from the GPU, but this code is already optimised so that it only checks textures that it actually needs to, and most of the time their hashes would be valid, so the cost of hashing on demand might end up being better overall, but it's hard to say without actually trying it.


Or, we could try calculating the hashes on the GPU - we can't exclusively switch to that because we still need the hashes on the CPU at texture creation time for the creation mode, width, height & format overrides, but we might be able to make it work for texture filtering (and perhaps even scene detection combined with writing to a custom resource), which could eliminate the need to track the hashes from the CPU.

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 03/09/2016 11:07 AM   
[quote="DarkStarSword"]I'd appreciate that Bo3b. I'm expecting to see a significant amount of time spent in UpdateResourceHashFromCPU, either hashing the textures or perhaps entering the critical section (hmm, might be some low hanging fruit there as we could skip entering the critical section for buffers since we don't need to track them and they tend to be updated hundreds of time per frame), that can be entirely eliminated by setting track_texture_updates=0.[/quote]OK, I'll be happy to do that. I'll use top of tree 3Dmigoto and top of tree FC4 fix to check. Let me know if there is a specific location or item that it uniquely interesting. I should be able to do this in the next couple of days. [quote="DarkStarSword"]I've pushed a 'texture_hash_rework' topic branch with code that I started working on a couple of months back aiming to address that. The idea was to separate out the description and data hashes, and then in release mode we would only calculate a data hash if the description hash was present in the d3dx.ini, which could easily cut down on the number of hashes we need to calculate by 90% or more at a guess.[/quote]If you want me to run against your experimental branch, I can do that too. [quote="DarkStarSword"]There is an alternative that I've started thinking about more and more - we could potentially calculate the hashes on demand. We would still track when the game updates each texture, but would only flag it's hash as invalid rather than recalculating it at the time. Then, in the texture filtering & checktextureoverride handlers we would have to go through a slow path and calculate the hash for any resources with an invalid hash. That wouldn't be great for performance when we need to do that since we would stall the pipeline while we fetch the data from the GPU, but this code is already optimised so that it only checks textures that it actually needs to, and most of the time their hashes would be valid, so the cost of hashing on demand might end up being better overall, but it's hard to say without actually trying it. Or, we could try calculating the hashes on the GPU - we can't exclusively switch to that because we still need the hashes on the CPU at texture creation time for the creation mode, width, height & format overrides, but we might be able to make it work for texture filtering (and perhaps even scene detection combined with writing to a custom resource), which could eliminate the need to track the hashes from the CPU.[/quote] Two other related ideas, not sure these will work, but figure it's worth mentioning. What about if we wrap all ID3D11Resource objects and return a wrapped descendant like HackerResource. That would allow us to add fields and methods to any texture to let us know whether to replace it, and what to replace it with. Without having to use maps or any other storage outside of the declarations from d3dx.ini. When they are created, we'd store the replacement and tag them. The reason this would also be valuable is that it would free up the time spent driving maps looking for matches. We'd always have the handle the ID3D11Resource** to key off of, and no longer need to do any searches. I've wanted to do this for our shader objects, as that last 0.8% of CPU usage is spent driving maps. If we had them fully wrapped as their own objects, we no longer have to do searches. Second idea. The ID3D11Resource descends from ID3D11DeviceChild and DeviceChild objects already have an arbitrary use mechanism via the Get/SetPrivateData. For any given Texture object, we could add a SetPrivateData with appropriate GUID, and then later when being mapped we could just GetPrivateData to see if it's supposed to be replaced/remapped/altered/stereoized. This approach would also eliminate the need to do searching outside of the startup or creation case where we are trying to map to something specified in d3dx.ini. This would mean lowering the hash cost to just when they are created. If profiling shows that creation is the problem, this won't help, but if searching is the cost, these would be a good win. If profiling shows that creation is a problem, we can probably make that routine smarter with early exits before we do the hash. If the rectangle doesn't match for example, the hash won't, so there is no point in calculating it. This would also require your idea for renaming the matches outside of strictly hashes.
DarkStarSword said:I'd appreciate that Bo3b. I'm expecting to see a significant amount of time spent in UpdateResourceHashFromCPU, either hashing the textures or perhaps entering the critical section (hmm, might be some low hanging fruit there as we could skip entering the critical section for buffers since we don't need to track them and they tend to be updated hundreds of time per frame), that can be entirely eliminated by setting track_texture_updates=0.
OK, I'll be happy to do that. I'll use top of tree 3Dmigoto and top of tree FC4 fix to check. Let me know if there is a specific location or item that it uniquely interesting. I should be able to do this in the next couple of days.


DarkStarSword said:I've pushed a 'texture_hash_rework' topic branch with code that I started working on a couple of months back aiming to address that. The idea was to separate out the description and data hashes, and then in release mode we would only calculate a data hash if the description hash was present in the d3dx.ini, which could easily cut down on the number of hashes we need to calculate by 90% or more at a guess.
If you want me to run against your experimental branch, I can do that too.


DarkStarSword said:There is an alternative that I've started thinking about more and more - we could potentially calculate the hashes on demand. We would still track when the game updates each texture, but would only flag it's hash as invalid rather than recalculating it at the time. Then, in the texture filtering & checktextureoverride handlers we would have to go through a slow path and calculate the hash for any resources with an invalid hash. That wouldn't be great for performance when we need to do that since we would stall the pipeline while we fetch the data from the GPU, but this code is already optimised so that it only checks textures that it actually needs to, and most of the time their hashes would be valid, so the cost of hashing on demand might end up being better overall, but it's hard to say without actually trying it.


Or, we could try calculating the hashes on the GPU - we can't exclusively switch to that because we still need the hashes on the CPU at texture creation time for the creation mode, width, height & format overrides, but we might be able to make it work for texture filtering (and perhaps even scene detection combined with writing to a custom resource), which could eliminate the need to track the hashes from the CPU.

Two other related ideas, not sure these will work, but figure it's worth mentioning.

What about if we wrap all ID3D11Resource objects and return a wrapped descendant like HackerResource. That would allow us to add fields and methods to any texture to let us know whether to replace it, and what to replace it with. Without having to use maps or any other storage outside of the declarations from d3dx.ini. When they are created, we'd store the replacement and tag them.

The reason this would also be valuable is that it would free up the time spent driving maps looking for matches. We'd always have the handle the ID3D11Resource** to key off of, and no longer need to do any searches. I've wanted to do this for our shader objects, as that last 0.8% of CPU usage is spent driving maps. If we had them fully wrapped as their own objects, we no longer have to do searches.


Second idea. The ID3D11Resource descends from ID3D11DeviceChild and DeviceChild objects already have an arbitrary use mechanism via the Get/SetPrivateData. For any given Texture object, we could add a SetPrivateData with appropriate GUID, and then later when being mapped we could just GetPrivateData to see if it's supposed to be replaced/remapped/altered/stereoized.

This approach would also eliminate the need to do searching outside of the startup or creation case where we are trying to map to something specified in d3dx.ini. This would mean lowering the hash cost to just when they are created.


If profiling shows that creation is the problem, this won't help, but if searching is the cost, these would be a good win.

If profiling shows that creation is a problem, we can probably make that routine smarter with early exits before we do the hash. If the rectangle doesn't match for example, the hash won't, so there is no point in calculating it. This would also require your idea for renaming the matches outside of strictly hashes.

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

Posted 03/09/2016 12:05 PM   
[quote="bo3b"]OK, I'll be happy to do that. I'll use top of tree 3Dmigoto and top of tree FC4 fix to check. Let me know if there is a specific location or item that it uniquely interesting. I should be able to do this in the next couple of days.[/quote]As I mentioned before, I'm not really seeing this myself since I'm GPU bound and have CPU cycles to spare - I feel like there is more stutter with tracking enabled, but when I've checked the framerate I can't see any evidence of that actually being the case. These are the numbers from one of the comments on the blog - as you can see track_texture_updates was costing this user 13fps which is quite significant: [quote="Anonymous"] Ok here's what I got (all numbers are with 3d enabled): No fix, as said earlier: 58 Old fix: 57 New fix: 41 New fix, track_texture_updates = 0: 54 New fix, track_texture_updates = 0, resourcezbuffer lines commented: 54 New fix, track_texture_updates = 1, resourcezbuffer lines commented: 41 So it seems that track_texture_updates = 0 helps a lot. Does it have some negative effects? This is pretty much the worst fps I get anywhere, so with that disabled I should have 60 fps 95% of the time. Btw. with or without the fix I have 1 core at 100% utilization. And that's even with the cpu running @ 4.7 Ghz. [/quote] [quote][quote="DarkStarSword"]I've pushed a 'texture_hash_rework' topic branch with code that I started working on a couple of months back aiming to address that. The idea was to separate out the description and data hashes, and then in release mode we would only calculate a data hash if the description hash was present in the d3dx.ini, which could easily cut down on the number of hashes we need to calculate by 90% or more at a guess.[/quote]If you want me to run against your experimental branch, I can do that too.[/quote]That would be good. I can't quite recall what state it was in when I put it on hold (the last commit says untested for instance), but it should be good enough to see if the rework is worthwhile or not. Note that I only expect to see a performance difference with hunting=0 - if hunting is set to 1 or 2 it will track all texture updates regardless of whether their description hash appears in the d3dx.ini or not (although the 2nd last commit disabled that for debugging an issues which turned out to be the mip-map problem). [quote="bo3b"]Two other related ideas, not sure these will work, but figure it's worth mentioning. What about if we wrap all ID3D11Resource objects and return a wrapped descendant like HackerResource. That would allow us to add fields and methods to any texture to let us know whether to replace it, and what to replace it with. Without having to use maps or any other storage outside of the declarations from d3dx.ini. When they are created, we'd store the replacement and tag them. The reason this would also be valuable is that it would free up the time spent driving maps looking for matches. We'd always have the handle the ID3D11Resource** to key off of, and no longer need to do any searches. I've wanted to do this for our shader objects, as that last 0.8% of CPU usage is spent driving maps. If we had them fully wrapped as their own objects, we no longer have to do searches. [/quote] The main performance issue I'm expecting to see is that when tracking is enabled we recalculate the crc32 hash on the UpdateSubresource() and Unamp() calls when the CPU might have overwritten the contents of the texture with a different texture, but you are right that we do have some lookups of our own resource maps in the tracking code so it is worth measuring to see how significant each is. The tracking code also does some processing on CopyResource() and CopySubresourceRegion(), which does not recalculate the crc32 but does look up maps for both source and destination resources, so it might save us a little there as well. This does give me an idea - I could easily check the resource description before looking it up in the mResources map and bail out early if it is a buffer. From what I've seen in frame analysis log buffers are updated using these calls way more often than textures (because there is almost always several constant buffers and maybe a vertex buffer updated before every draw call) and they aren't interesting to track, so bailing early for them could add up to a significant amount of time saved, but without the numbers I can't say how much. [quote]Second idea. The ID3D11Resource descends from ID3D11DeviceChild and DeviceChild objects already have an arbitrary use mechanism via the Get/SetPrivateData. For any given Texture object, we could add a SetPrivateData with appropriate GUID, and then later when being mapped we could just GetPrivateData to see if it's supposed to be replaced/remapped/altered/stereoized. [/quote]That's not a bad idea, though by the looks of it it takes a guid so I assume it must have some lookup of it's own internally and if that turns out to be a map it might not save us anything. It would be interesting to benchmark it though - if it is faster it would be a fairly simple way to save some cycles without as much of an invasive change as wrapping resource objects would be. [quote]This approach would also eliminate the need to do searching outside of the startup or creation case where we are trying to map to something specified in d3dx.ini. This would mean lowering the hash cost to just when they are created.[/quote]We would still need to recalculate the crc32 on the two calls I mentioned above - the only way I can see around that is either doing it lazilly and costing more later (but hopefully with the trade off of only spending that cost occasionally), or shifting the calculation to the GPU, which would be a more significant rework and end up more complicated to do things we can currently do fairly easily in the d3dx.ini. [quote]If profiling shows that creation is the problem, this won't help, but if searching is the cost, these would be a good win. If profiling shows that creation is a problem, we can probably make that routine smarter with early exits before we do the hash. If the rectangle doesn't match for example, the hash won't, so there is no point in calculating it. This would also require your idea for renaming the matches outside of strictly hashes.[/quote] Agreed - we need the numbers to make the best decision here. On a sligthly different topic, it occurred to me that it would be possible for us to use the MD5-like hash embedded inside the shader binaries instead of calculating an FNV hash. I know we don't spend many cycles on these relative to everything else, but it's an idea.
bo3b said:OK, I'll be happy to do that. I'll use top of tree 3Dmigoto and top of tree FC4 fix to check. Let me know if there is a specific location or item that it uniquely interesting. I should be able to do this in the next couple of days.
As I mentioned before, I'm not really seeing this myself since I'm GPU bound and have CPU cycles to spare - I feel like there is more stutter with tracking enabled, but when I've checked the framerate I can't see any evidence of that actually being the case.

These are the numbers from one of the comments on the blog - as you can see track_texture_updates was costing this user 13fps which is quite significant:

Anonymous said:
Ok here's what I got (all numbers are with 3d enabled):

No fix, as said earlier: 58
Old fix: 57
New fix: 41
New fix, track_texture_updates = 0: 54
New fix, track_texture_updates = 0, resourcezbuffer lines commented: 54
New fix, track_texture_updates = 1, resourcezbuffer lines commented: 41

So it seems that track_texture_updates = 0 helps a lot. Does it have some negative effects? This is pretty much the worst fps I get anywhere, so with that disabled I should have 60 fps 95% of the time.

Btw. with or without the fix I have 1 core at 100% utilization. And that's even with the cpu running @ 4.7 Ghz.


DarkStarSword said:I've pushed a 'texture_hash_rework' topic branch with code that I started working on a couple of months back aiming to address that. The idea was to separate out the description and data hashes, and then in release mode we would only calculate a data hash if the description hash was present in the d3dx.ini, which could easily cut down on the number of hashes we need to calculate by 90% or more at a guess.
If you want me to run against your experimental branch, I can do that too.
That would be good. I can't quite recall what state it was in when I put it on hold (the last commit says untested for instance), but it should be good enough to see if the rework is worthwhile or not. Note that I only expect to see a performance difference with hunting=0 - if hunting is set to 1 or 2 it will track all texture updates regardless of whether their description hash appears in the d3dx.ini or not (although the 2nd last commit disabled that for debugging an issues which turned out to be the mip-map problem).

bo3b said:Two other related ideas, not sure these will work, but figure it's worth mentioning.

What about if we wrap all ID3D11Resource objects and return a wrapped descendant like HackerResource. That would allow us to add fields and methods to any texture to let us know whether to replace it, and what to replace it with. Without having to use maps or any other storage outside of the declarations from d3dx.ini. When they are created, we'd store the replacement and tag them.

The reason this would also be valuable is that it would free up the time spent driving maps looking for matches. We'd always have the handle the ID3D11Resource** to key off of, and no longer need to do any searches. I've wanted to do this for our shader objects, as that last 0.8% of CPU usage is spent driving maps. If we had them fully wrapped as their own objects, we no longer have to do searches.

The main performance issue I'm expecting to see is that when tracking is enabled we recalculate the crc32 hash on the UpdateSubresource() and Unamp() calls when the CPU might have overwritten the contents of the texture with a different texture, but you are right that we do have some lookups of our own resource maps in the tracking code so it is worth measuring to see how significant each is. The tracking code also does some processing on CopyResource() and CopySubresourceRegion(), which does not recalculate the crc32 but does look up maps for both source and destination resources, so it might save us a little there as well.

This does give me an idea - I could easily check the resource description before looking it up in the mResources map and bail out early if it is a buffer. From what I've seen in frame analysis log buffers are updated using these calls way more often than textures (because there is almost always several constant buffers and maybe a vertex buffer updated before every draw call) and they aren't interesting to track, so bailing early for them could add up to a significant amount of time saved, but without the numbers I can't say how much.

Second idea. The ID3D11Resource descends from ID3D11DeviceChild and DeviceChild objects already have an arbitrary use mechanism via the Get/SetPrivateData. For any given Texture object, we could add a SetPrivateData with appropriate GUID, and then later when being mapped we could just GetPrivateData to see if it's supposed to be replaced/remapped/altered/stereoized.
That's not a bad idea, though by the looks of it it takes a guid so I assume it must have some lookup of it's own internally and if that turns out to be a map it might not save us anything. It would be interesting to benchmark it though - if it is faster it would be a fairly simple way to save some cycles without as much of an invasive change as wrapping resource objects would be.

This approach would also eliminate the need to do searching outside of the startup or creation case where we are trying to map to something specified in d3dx.ini. This would mean lowering the hash cost to just when they are created.
We would still need to recalculate the crc32 on the two calls I mentioned above - the only way I can see around that is either doing it lazilly and costing more later (but hopefully with the trade off of only spending that cost occasionally), or shifting the calculation to the GPU, which would be a more significant rework and end up more complicated to do things we can currently do fairly easily in the d3dx.ini.

If profiling shows that creation is the problem, this won't help, but if searching is the cost, these would be a good win.

If profiling shows that creation is a problem, we can probably make that routine smarter with early exits before we do the hash. If the rectangle doesn't match for example, the hash won't, so there is no point in calculating it. This would also require your idea for renaming the matches outside of strictly hashes.

Agreed - we need the numbers to make the best decision here.



On a sligthly different topic, it occurred to me that it would be possible for us to use the MD5-like hash embedded inside the shader binaries instead of calculating an FNV hash. I know we don't spend many cycles on these relative to everything else, but it's an idea.

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 03/09/2016 02:21 PM   
I've just updated the fix on the blog to fix the crosshair on the Steam version. 3DMigoto 1.2.35 now allows #include directives to be relative to the shader's path, so including other files in the same directory should work regardless of the game's current working directory. This also re-fixes hairworks (Thanks to Bo3b for some work on the decompiler and hand-fixing a couple of problems on that shader), another problem I spotted with MSAA enabled (boy am I glad FCPrimal only has FXAA and SMAA) and added the SBS shaders.
I've just updated the fix on the blog to fix the crosshair on the Steam version. 3DMigoto 1.2.35 now allows #include directives to be relative to the shader's path, so including other files in the same directory should work regardless of the game's current working directory.

This also re-fixes hairworks (Thanks to Bo3b for some work on the decompiler and hand-fixing a couple of problems on that shader), another problem I spotted with MSAA enabled (boy am I glad FCPrimal only has FXAA and SMAA) and added the SBS shaders.

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 03/09/2016 02:26 PM   
Just did an update to 1.2.35 version, and did a peformance profile. Test case was to run across grass field for 5 seconds, jumped on hangglider, then shot up a camp with grenades. Not sure the best way to share this info, but I know that you and I both prefer open sharing for stuff like this, so I put it as a new Issue on GitHub. The forum software here is too hard to use, and too unreliable. [url]https://github.com/bo3b/3Dmigoto/issues/44[/url] Basic peformance table sorted by highest use case: [img]https://cloud.githubusercontent.com/assets/6544511/13726986/c3a1cd0e-e894-11e5-87db-b2addcf6ec0b.png[/img]
Just did an update to 1.2.35 version, and did a peformance profile. Test case was to run across grass field for 5 seconds, jumped on hangglider, then shot up a camp with grenades.

Not sure the best way to share this info, but I know that you and I both prefer open sharing for stuff like this, so I put it as a new Issue on GitHub. The forum software here is too hard to use, and too unreliable.

https://github.com/bo3b/3Dmigoto/issues/44


Basic peformance table sorted by highest use case:

Image

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

Posted 03/13/2016 05:16 AM   
Can't get the Helix mod to work, game just launches in 3d compatibility mode no matter what. Downgraded to 358.87 drivers and it's still not launching in real 3d mode.
Can't get the Helix mod to work, game just launches in 3d compatibility mode no matter what. Downgraded to 358.87 drivers and it's still not launching in real 3d mode.

Posted 03/30/2016 02:29 PM   
Enable advanced keys in control panel, Ctrl+Alt+F11 to switch.
Enable advanced keys in control panel, Ctrl+Alt+F11 to switch.

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 03/30/2016 02:48 PM   
  27 / 28    
Scroll To Top