Mass Effect: Andromeda - 100% (plus 10%) - 3D VISION Ready Fix
4 / 22
Cool, found the correct pattern to remove the remaining tile light seams :)
[img]https://forums.geforce.com/cmd/default/download-comment-attachment/74405/[/img]
[quote="Helifax"]Again... Where is the damn tape... As I am very much speechless :) So, UpdateSubresource() actually runs only on the Left Eye Buffer, but not the duplicated Right Eye(stereo) one? [/quote]Yeah, that's right (well, other way around - 3D Vision treats the right eye as the primary for whatever reason).
It's kind of amazing to me that this bug has been missed for so long, but then again I suppose UpdateSubresource() is usually updating a mono 2D texture, or maybe a constant buffer that can't be stereo, and it is entirely possible that this bug is specific to buffers, not textures - they're certainly a lot harder to see that something is broken, since you can't just dump them out as a stereo image and look at them, and nvidia's reverse stereo blit doesn't work with them so you can't even dump them to a file to examine them like we can with stereo pairs of 2D textures. That's the beauty of using my buffer debug shaders though - since they render everything on the GPU they will show differences in the buffers between the eyes - it's really the only way to see stereo buffers.
Helifax said:Again... Where is the damn tape... As I am very much speechless :) So, UpdateSubresource() actually runs only on the Left Eye Buffer, but not the duplicated Right Eye(stereo) one?
Yeah, that's right (well, other way around - 3D Vision treats the right eye as the primary for whatever reason).
It's kind of amazing to me that this bug has been missed for so long, but then again I suppose UpdateSubresource() is usually updating a mono 2D texture, or maybe a constant buffer that can't be stereo, and it is entirely possible that this bug is specific to buffers, not textures - they're certainly a lot harder to see that something is broken, since you can't just dump them out as a stereo image and look at them, and nvidia's reverse stereo blit doesn't work with them so you can't even dump them to a file to examine them like we can with stereo pairs of 2D textures. That's the beauty of using my buffer debug shaders though - since they render everything on the GPU they will show differences in the buffers between the eyes - it's really the only way to see stereo buffers.
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
OMG!!!
It took me literally 2 hours to find this bug:)) Freaking annoying and frustrating DSS;)) (And I bet you didn't see it!)
Some of the Compute shaders you committed have a blank line in the header/top. The shaders would fail silently to compile (no audio/log warning) but they would simple fail! However, when I copied one shader at a time and press F10 to reload, I would get the BOP sound! Looking at the shader code I couldn't directly see it, as everything looked perfect!
However, the problem was here:
[code]
// Tile light tiles #2, fixed by DarkStarSword
NOTICE THIS LINE! No comment line and it would fail to compile here!
//
// Generated by Microsoft (R) D3D Shader Disassembler
//
// using 3Dmigoto v1.2.67 on Sun Jan 14 21:43:47 2018
//
//
[/code]
Resolution was simple as possible:
[code]
// Tile light tiles #2, fixed by DarkStarSword
//
// Generated by Microsoft (R) D3D Shader Disassembler
//
// using 3Dmigoto v1.2.67 on Sun Jan 14 21:43:47 2018
//
//
[/code]
There are a few of them like this! I bet is the "\n" at the end of the injector;))
FINALLY, I was able to get it working! Now for some testing Muhaha!:)
(I am using 3DMigoto 1.2.67. Don't know if this is a known bug, but from the github notifications, I don't think so;) )
OMG!!!
It took me literally 2 hours to find this bug:)) Freaking annoying and frustrating DSS;)) (And I bet you didn't see it!)
Some of the Compute shaders you committed have a blank line in the header/top. The shaders would fail silently to compile (no audio/log warning) but they would simple fail! However, when I copied one shader at a time and press F10 to reload, I would get the BOP sound! Looking at the shader code I couldn't directly see it, as everything looked perfect!
However, the problem was here:
// Tile light tiles #2, fixed by DarkStarSword
NOTICE THIS LINE! No comment line and it would fail to compile here!
//
// Generated by Microsoft (R) D3D Shader Disassembler
//
// using 3Dmigoto v1.2.67 on Sun Jan 14 21:43:47 2018
//
//
Resolution was simple as possible:
// Tile light tiles #2, fixed by DarkStarSword
//
// Generated by Microsoft (R) D3D Shader Disassembler
//
// using 3Dmigoto v1.2.67 on Sun Jan 14 21:43:47 2018
//
//
There are a few of them like this! I bet is the "\n" at the end of the injector;))
FINALLY, I was able to get it working! Now for some testing Muhaha!:)
(I am using 3DMigoto 1.2.67. Don't know if this is a known bug, but from the github notifications, I don't think so;) )
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
Unfortunately this doesn't work with my fix so:( It makes the tiles even worse:( It has to do with the DX10 Flag the game is using. If I use the default one, sure the tiles can be fixed, but a lot of other stuff is broken:(
Hmmm...
Unfortunately this doesn't work with my fix so:( It makes the tiles even worse:( It has to do with the DX10 Flag the game is using. If I use the default one, sure the tiles can be fixed, but a lot of other stuff is broken:(
Hmmm...
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"]OMG!!!
It took me literally 2 hours to find this bug:)) Freaking annoying and frustrating DSS;)) (And I bet you didn't see it!)
Some of the Compute shaders you committed have a blank line in the header/top. The shaders would fail silently to compile (no audio/log warning) but they would simple fail! However, when I copied one shader at a time and press F10 to reload, I would get the BOP sound! Looking at the shader code I couldn't directly see it, as everything looked perfect!
However, the problem was here:
[code]
// Tile light tiles #2, fixed by DarkStarSword
NOTICE THIS LINE! No comment line and it would fail to compile here!
//
// Generated by Microsoft (R) D3D Shader Disassembler
//
// using 3Dmigoto v1.2.67 on Sun Jan 14 21:43:47 2018
//
//
[/code]
There are a few of them like this! I bet is the "\n" at the end of the injector;))
FINALLY, I was able to get it working! Now for some testing Muhaha!:)
(I am using 3DMigoto 1.2.67. Don't know if this is a known bug, but from the github notifications, I don't think so;) )[/quote]
Nope, the blank line doesn't cause problems by itself, but I bet I know what is - I bet you somehow converted the file to DOS/Windows style newlines \r\n (how did you grab these files? They should have been Unix style newlines on github), but these files are supposed to use Unix style newlines \n - I can easily see this bug with cmd_Decompiler:
[code]
dss@Gideon ~/3d-fixes/Mass Effect Andromeda/ShaderFixes
$ cmd_Decompiler.exe -a 14f8f4febc50582f-cs.txt
Assembling 14f8f4febc50582f-cs.txt...
Parsing Input Signature section...
Parsing Output Signature section...
Manufacturing placeholder SHEX section...
-> 14f8f4febc50582f-cs.shdr
dss@Gideon ~/3d-fixes/Mass Effect Andromeda/ShaderFixes
$ cmd_Decompiler.exe -d -V 14f8f4febc50582f-cs.shdr
Disassembling (Flugan) 14f8f4febc50582f-cs.shdr...
Parsing Input Signature section...
Parsing Output Signature section...
Manufacturing placeholder SHEX section...
Assembly verification pass succeeded
-> 14f8f4febc50582f-cs.asm
[/code]
Works fine, but:
[code]
dss@Gideon ~/3d-fixes/Mass Effect Andromeda/ShaderFixes
$ unix2dos 14f8f4febc50582f-cs.txt
unix2dos: converting file 14f8f4febc50582f-cs.txt to DOS format...
dss@Gideon ~/3d-fixes/Mass Effect Andromeda/ShaderFixes
$ cmd_Decompiler.exe -a 14f8f4febc50582f-cs.txt
Assembling 14f8f4febc50582f-cs.txt...
Parsing Input Signature section...
Parsing Output Signature section...
Manufacturing placeholder SHEX section...
-> 14f8f4febc50582f-cs.shdr
dss@Gideon ~/3d-fixes/Mass Effect Andromeda/ShaderFixes
$ cmd_Decompiler.exe -d -V 14f8f4febc50582f-cs.shdr
Disassembling (Flugan) 14f8f4febc50582f-cs.shdr...
Parsing Input Signature section...
Parsing Output Signature section...
Did not find an assembly text section!
*** Assembly verification pass failed: Reassembly failed 0x80004005
*** At least one error occurred during run ***
[/code]
Created a corrupt shader.
I'll take a look at this in a little while - there's no reason we shouldn't be able to cope with DOS style newlines, and if it cost you time it will definitely bite someone else sooner or later.
[quote="Helifax"]Unfortunately this doesn't work with my fix so:( It makes the tiles even worse:( It has to do with the DX10 Flag the game is using. If I use the default one, sure the tiles can be fixed, but a lot of other stuff is broken:(
Hmmm...[/quote]OK, I'll take a look at that as well. I was working off your 0.61 version with StereoFlagsDX10=0x00004000. If you're using StereoFlagsDX10=0x0000C000 then it means some UAVs won't have been automatically stereoised, so we will need to identify them and use [TextureOverrides] to force them to stereo (assuming the info nvidia gave us about the 0x00008000 flag is accurate). Alternatively we could identify why 0x00004000 isn't enough and work from that direction - if it turns out to be more manifestations of the UpdateSubresource bug we can add a workaround directly in 3DMigoto.
Helifax said:OMG!!!
It took me literally 2 hours to find this bug:)) Freaking annoying and frustrating DSS;)) (And I bet you didn't see it!)
Some of the Compute shaders you committed have a blank line in the header/top. The shaders would fail silently to compile (no audio/log warning) but they would simple fail! However, when I copied one shader at a time and press F10 to reload, I would get the BOP sound! Looking at the shader code I couldn't directly see it, as everything looked perfect!
However, the problem was here:
// Tile light tiles #2, fixed by DarkStarSword
NOTICE THIS LINE! No comment line and it would fail to compile here!
//
// Generated by Microsoft (R) D3D Shader Disassembler
//
// using 3Dmigoto v1.2.67 on Sun Jan 14 21:43:47 2018
//
//
There are a few of them like this! I bet is the "\n" at the end of the injector;))
FINALLY, I was able to get it working! Now for some testing Muhaha!:)
(I am using 3DMigoto 1.2.67. Don't know if this is a known bug, but from the github notifications, I don't think so;) )
Nope, the blank line doesn't cause problems by itself, but I bet I know what is - I bet you somehow converted the file to DOS/Windows style newlines \r\n (how did you grab these files? They should have been Unix style newlines on github), but these files are supposed to use Unix style newlines \n - I can easily see this bug with cmd_Decompiler:
dss@Gideon ~/3d-fixes/Mass Effect Andromeda/ShaderFixes
$ cmd_Decompiler.exe -d -V 14f8f4febc50582f-cs.shdr
Disassembling (Flugan) 14f8f4febc50582f-cs.shdr...
Parsing Input Signature section...
Parsing Output Signature section...
Did not find an assembly text section!
*** Assembly verification pass failed: Reassembly failed 0x80004005
*** At least one error occurred during run ***
Created a corrupt shader.
I'll take a look at this in a little while - there's no reason we shouldn't be able to cope with DOS style newlines, and if it cost you time it will definitely bite someone else sooner or later.
Helifax said:Unfortunately this doesn't work with my fix so:( It makes the tiles even worse:( It has to do with the DX10 Flag the game is using. If I use the default one, sure the tiles can be fixed, but a lot of other stuff is broken:(
Hmmm...
OK, I'll take a look at that as well. I was working off your 0.61 version with StereoFlagsDX10=0x00004000. If you're using StereoFlagsDX10=0x0000C000 then it means some UAVs won't have been automatically stereoised, so we will need to identify them and use [TextureOverrides] to force them to stereo (assuming the info nvidia gave us about the 0x00008000 flag is accurate). Alternatively we could identify why 0x00004000 isn't enough and work from that direction - if it turns out to be more manifestations of the UpdateSubresource bug we can add a workaround directly in 3DMigoto.
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
The 0x4000 flag is so bustec in the game. I randomly loaded a few zones and a lot of one eye effects are present. Even with the UpdateSubresource fix tk correct one broken effect it still dint look right! Which makes sense if the Uavs are stereorised but in 0x8000 arent. With 0xc000 I fixed everything except those lights. I think identifying the Uavs and making them stereo for the lights shaders is the best way to go!
The 0x4000 flag is so bustec in the game. I randomly loaded a few zones and a lot of one eye effects are present. Even with the UpdateSubresource fix tk correct one broken effect it still dint look right! Which makes sense if the Uavs are stereorised but in 0x8000 arent. With 0xc000 I fixed everything except those lights. I think identifying the Uavs and making them stereo for the lights shaders is the best way to go!
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"]OMG!!!
It took me literally 2 hours to find this bug:)) Freaking annoying and frustrating DSS;)) (And I bet you didn't see it!)
...
There are a few of them like this! I bet is the "\n" at the end of the injector;))
[/quote]
Really sorry that this cost you time - it was an off by one error in Flugan's assembler that didn't properly strip carriage returns from blank lines and mistook the blank line for the shader model - it will be fixed in the next release of 3DMigoto and cmd_Decompiler:
https://github.com/bo3b/3Dmigoto/commit/1113fdd955ea1cfa56a8124cab5d450093810ded
Helifax said:OMG!!!
It took me literally 2 hours to find this bug:)) Freaking annoying and frustrating DSS;)) (And I bet you didn't see it!)
...
There are a few of them like this! I bet is the "\n" at the end of the injector;))
Really sorry that this cost you time - it was an off by one error in Flugan's assembler that didn't properly strip carriage returns from blank lines and mistook the blank line for the shader model - it will be fixed in the next release of 3DMigoto and cmd_Decompiler:
[quote="DarkStarSword"][quote="Helifax"]OMG!!!
It took me literally 2 hours to find this bug:)) Freaking annoying and frustrating DSS;)) (And I bet you didn't see it!)
...
There are a few of them like this! I bet is the "\n" at the end of the injector;))
[/quote]
Really sorry that this cost you time - it was an off by one error in Flugan's assembler that didn't properly strip carriage returns from blank lines and mistook the blank line for the shader model - it will be fixed in the next release of 3DMigoto and cmd_Decompiler:
https://github.com/bo3b/3Dmigoto/commit/1113fdd955ea1cfa56a8124cab5d450093810ded
[/quote]
Hehe nothing to worry about, now at least I know about it;) and where to look! I knew about TABS not being liked inside ASM shaders;) Had no idea before, that empty new lines weren't working. Is also my fault, as I modified some of them using Windows Notepad instead of Notepad++ so... :D
Played a bit more with the 0x4000 flag, and even if we add the UpdateSubresource() fix in 3DMigoto we will need to find some UVS to make them mono as they are stereo which is wrong.
This is why I think doing the other thing, starting from 0xC000 and finding the UAVs that need stereorization will be easier:) 0x8000 addresses the UpdateSubresource() problem it seems;)
Helifax said:OMG!!!
It took me literally 2 hours to find this bug:)) Freaking annoying and frustrating DSS;)) (And I bet you didn't see it!)
...
There are a few of them like this! I bet is the "\n" at the end of the injector;))
Really sorry that this cost you time - it was an off by one error in Flugan's assembler that didn't properly strip carriage returns from blank lines and mistook the blank line for the shader model - it will be fixed in the next release of 3DMigoto and cmd_Decompiler:
Hehe nothing to worry about, now at least I know about it;) and where to look! I knew about TABS not being liked inside ASM shaders;) Had no idea before, that empty new lines weren't working. Is also my fault, as I modified some of them using Windows Notepad instead of Notepad++ so... :D
Played a bit more with the 0x4000 flag, and even if we add the UpdateSubresource() fix in 3DMigoto we will need to find some UVS to make them mono as they are stereo which is wrong.
This is why I think doing the other thing, starting from 0xC000 and finding the UAVs that need stereorization will be easier:) 0x8000 addresses the UpdateSubresource() problem it seems;)
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"]Hehe nothing to worry about, now at least I know about it;) and where to look! I knew about TABS not being liked inside ASM shaders;) Had no idea before, that empty new lines weren't working. Is also my fault, as I modified some of them using Windows Notepad instead of Notepad++ so... :D[/quote]I fixed that issue with tabs a while back when I overhauled the assembler for 1.2.52, but the blank line issue was new to me - it only hit if the blank line is before the shader model and uses DOS style newlines. Assembler issues are tracked here:
https://github.com/bo3b/3Dmigoto/issues/36
[quote]This is why I think doing the other thing, starting from 0xC000 and finding the UAVs that need stereorization will be easier:) 0x8000 addresses the UpdateSubresource() problem it seems;)[/quote]I'll take a look at this shortly.
Helifax said:Hehe nothing to worry about, now at least I know about it;) and where to look! I knew about TABS not being liked inside ASM shaders;) Had no idea before, that empty new lines weren't working. Is also my fault, as I modified some of them using Windows Notepad instead of Notepad++ so... :D
I fixed that issue with tabs a while back when I overhauled the assembler for 1.2.52, but the blank line issue was new to me - it only hit if the blank line is before the shader model and uses DOS style newlines. Assembler issues are tracked here:
This is why I think doing the other thing, starting from 0xC000 and finding the UAVs that need stereorization will be easier:) 0x8000 addresses the UpdateSubresource() problem it seems;)
I'll take a look at this shortly.
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
StereoFlagsDX10 = 0x0000C000 might be a deal breaker if we want working tile lighting. For tile lighting we need StructuredBuffer UAVs in particular to be stereoised (as opposed to regular buffers). We cannot use the surface creation mode to force buffers to stereo like we can for textures (we CAN use it to force them to mono however), which leaves us with only the bind flags to affect this.
Now, if we use StereoFlagsDX10 = 0x00004000 this is easy because all UAVs are stereoised, as you can see here (explanation of the lines in this image below):
[color="green"][size="XL"]StereoFlagsDX10 = 0x00004000:[/size][/color]
[img]https://forums.geforce.com/cmd/default/download-comment-attachment/74411/[/img]
But if we use StereoFlagsDX10 = 0x0000C000 then the rules change so that buffers must have the RTV bind flag to be stereoised, but there's a problem - structured buffers cannot have the RTV flag - they only support UAV and SRV bind flags, so attempting to use RTV causes the resource creation to fail and the debug shader marks them as INVALID:
[color="green"][size="XL"]StereoFlagsDX10 = 0x0000C000:[/size][/color]
[img]https://forums.geforce.com/cmd/default/download-comment-attachment/74412/[/img]
For completeness, this is how it behaves with StereoFlagsDX10 = 0x00000000. In this case the compute shaders only run for the right eye and UAVs are not automatically stereoised, so most of this is mono. One surprise to me here is that setting the creation mode to stereo actually DID have an effect on regular buffer UAVs, but only those that also had the RTV bind flag, so again this could not stereoise structured buffer UAVs:
[color="green"][size="XL"]StereoFlagsDX10 = 0x00000000:[/size][/color]
[img]https://forums.geforce.com/cmd/default/download-comment-attachment/74410/[/img]
Explanation of the lines in those images:
Buffer/Struct: Indicates whether the buffer written to was a regular buffer or a structured buffer
PS/CS: Indicates what type of shader was used to write to this buffer
(UAV/RTV) in brackets: Indicates how the pixel shader wrote to the UAV. Not applicable to non-UAVs or compute shaders. I didn't bother trying all permutations here, mostly because 3DMigoto has issues trying to bind more than one UAV to a pixel shader at a time (the DirectX API to do this sucks, and I haven't gone to enough heroics to make this work regardless).
RTV+UAV+SRV: Indicates the bind flags used to create the buffer. RTV = Render Target View, UAV = Unordered Access View, SRV = Shader Resource View
If a line contains "xxx -> yyy" it means the buffer or structured buffer was copied from one resource to another to get it into the debug shader. To read it from the debug shader I had to have the SRV bind flag, so if that wasn't in the resource I wrote to I had to make a copy with SRV. I also copied all StructuredBuffer UAVs into a regular buffer with bind flags known to be stereoisable regardless of StereoFlagsDX10 to make sure that they could be shown in stereo, if the source resource was stereo.
LEFT/RIGHT: Indicates which eye the shader was running in that wrote that value. If the resource is stereo you will see alternate values on each side, if the resource was mono you will see both sides indicate RIGHT.
INVALID: Indicates that the buffer hasn't been written to - either it wasn't created, or the shader that wrote it didn't run in the that eye.
Creation Mode: Indicates what the 3D Vision surface creation mode was set to when the resources were created. You will notice that the driver respects mono creation mode for both regular and structured buffers, but only respects stereo creation mode for UAVs if they are also RTVs, which discounts structured buffers.
This testcase is available here (requires 3DMigoto 1.2.69):
https://github.com/DarkStarSword/3d-fixes/tree/master/stereo_buffer_tests
StereoFlagsDX10 = 0x0000C000 might be a deal breaker if we want working tile lighting. For tile lighting we need StructuredBuffer UAVs in particular to be stereoised (as opposed to regular buffers). We cannot use the surface creation mode to force buffers to stereo like we can for textures (we CAN use it to force them to mono however), which leaves us with only the bind flags to affect this.
Now, if we use StereoFlagsDX10 = 0x00004000 this is easy because all UAVs are stereoised, as you can see here (explanation of the lines in this image below):
StereoFlagsDX10 = 0x00004000:
But if we use StereoFlagsDX10 = 0x0000C000 then the rules change so that buffers must have the RTV bind flag to be stereoised, but there's a problem - structured buffers cannot have the RTV flag - they only support UAV and SRV bind flags, so attempting to use RTV causes the resource creation to fail and the debug shader marks them as INVALID:
StereoFlagsDX10 = 0x0000C000:
For completeness, this is how it behaves with StereoFlagsDX10 = 0x00000000. In this case the compute shaders only run for the right eye and UAVs are not automatically stereoised, so most of this is mono. One surprise to me here is that setting the creation mode to stereo actually DID have an effect on regular buffer UAVs, but only those that also had the RTV bind flag, so again this could not stereoise structured buffer UAVs:
StereoFlagsDX10 = 0x00000000:
Explanation of the lines in those images:
Buffer/Struct: Indicates whether the buffer written to was a regular buffer or a structured buffer
PS/CS: Indicates what type of shader was used to write to this buffer
(UAV/RTV) in brackets: Indicates how the pixel shader wrote to the UAV. Not applicable to non-UAVs or compute shaders. I didn't bother trying all permutations here, mostly because 3DMigoto has issues trying to bind more than one UAV to a pixel shader at a time (the DirectX API to do this sucks, and I haven't gone to enough heroics to make this work regardless).
RTV+UAV+SRV: Indicates the bind flags used to create the buffer. RTV = Render Target View, UAV = Unordered Access View, SRV = Shader Resource View
If a line contains "xxx -> yyy" it means the buffer or structured buffer was copied from one resource to another to get it into the debug shader. To read it from the debug shader I had to have the SRV bind flag, so if that wasn't in the resource I wrote to I had to make a copy with SRV. I also copied all StructuredBuffer UAVs into a regular buffer with bind flags known to be stereoisable regardless of StereoFlagsDX10 to make sure that they could be shown in stereo, if the source resource was stereo.
LEFT/RIGHT: Indicates which eye the shader was running in that wrote that value. If the resource is stereo you will see alternate values on each side, if the resource was mono you will see both sides indicate RIGHT.
INVALID: Indicates that the buffer hasn't been written to - either it wasn't created, or the shader that wrote it didn't run in the that eye.
Creation Mode: Indicates what the 3D Vision surface creation mode was set to when the resources were created. You will notice that the driver respects mono creation mode for both regular and structured buffers, but only respects stereo creation mode for UAVs if they are also RTVs, which discounts structured buffers.
@DarkStarSword: Quick thought here- is this worth sending an email to Dave to ask about? There might be other profile bits he can share that might make this easier*. And/or he probably would want to know that the driver is doing this wrong.
* not super likely, because profile switches don't seem to help.
@DarkStarSword: Quick thought here- is this worth sending an email to Dave to ask about? There might be other profile bits he can share that might make this easier*. And/or he probably would want to know that the driver is doing this wrong.
* not super likely, because profile switches don't seem to help.
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
@DarkStarSword:
Reading all that makes sense (once I actually had to the time to sit down and read it). Indeed there is no Stereo Structured Buffer or it doesn't make sense.
And yet! This flag makes this game (and other Frosbite 3 game that I tested with the 0xC000 flag) almost perfect (you still need to fix the normal stuff, shadows, reflections, etc, but a lot of stuff, is at the "right location, in both eyes").
I wouldn't discard this flag just yet;)
@bo3b:
If you believe this might be helpful for everyone, or if Nvidia can give us some more info, I don't see why not:) And I am +1 for that!
Reading all that makes sense (once I actually had to the time to sit down and read it). Indeed there is no Stereo Structured Buffer or it doesn't make sense.
And yet! This flag makes this game (and other Frosbite 3 game that I tested with the 0xC000 flag) almost perfect (you still need to fix the normal stuff, shadows, reflections, etc, but a lot of stuff, is at the "right location, in both eyes").
I wouldn't discard this flag just yet;)
@bo3b:
If you believe this might be helpful for everyone, or if Nvidia can give us some more info, I don't see why not:) And I am +1 for that!
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
An "ungrateful wretch" checking in! ;-D
Just wanted to say that you guys are geniuses (genii?) :D
The lengths you guys go to to get things to work is absolutely astonishing!
[quote="bo3b"]@DarkStarSword: Quick thought here- is this worth sending an email to Dave to ask about? There might be other profile bits he can share that might make this easier*. And/or he probably would want to know that the driver is doing this wrong.
* not super likely, because profile switches don't seem to help.[/quote]Yeah, I'll send him a note on both of these bugs after I've got some sleep.
[quote="Helifax"]And yet! This flag makes this game (and other Frosbite 3 game that I tested with the 0xC000 flag) almost perfect (you still need to fix the normal stuff, shadows, reflections, etc, but a lot of stuff, is at the "right location, in both eyes").
I wouldn't discard this flag just yet;)[/quote]Well, we pretty much know exactly what this flag does, so why don't we just replicate it in 3DMigoto instead? We can use StereoFlagsDX10=0x00004000 and have 3DMigoto force the default creation mode of any buffers that don't have the RTV bind flag to mono, and that should have the same effect as StereoFlagsDX10=0x0000C000, but gives us the ability to selectively force buffers to stereo as we need them. We can already do this with [TextureOverride] sections if we identify the hashes we want mono, but I've been wanting to add a fuzzy matching ability to 3DMigoto for ages so you can just match on some characteristics of a resource instead of being exact.
The one addition to the driver that would *really* be useful is some ability to defer the decision, because sometimes the resource description may not be enough to determine if we need to force the buffer stereo or mono at creation time, and if we could defer that until we see what shader it is used with it would help tremendously (I had to jump through all sorts of hoops to work around this limitation in Dreamfall Chapters - my resource copying code is awesome enough that I could, but it wasn't easy).
bo3b said:@DarkStarSword: Quick thought here- is this worth sending an email to Dave to ask about? There might be other profile bits he can share that might make this easier*. And/or he probably would want to know that the driver is doing this wrong.
* not super likely, because profile switches don't seem to help.
Yeah, I'll send him a note on both of these bugs after I've got some sleep.
Helifax said:And yet! This flag makes this game (and other Frosbite 3 game that I tested with the 0xC000 flag) almost perfect (you still need to fix the normal stuff, shadows, reflections, etc, but a lot of stuff, is at the "right location, in both eyes").
I wouldn't discard this flag just yet;)
Well, we pretty much know exactly what this flag does, so why don't we just replicate it in 3DMigoto instead? We can use StereoFlagsDX10=0x00004000 and have 3DMigoto force the default creation mode of any buffers that don't have the RTV bind flag to mono, and that should have the same effect as StereoFlagsDX10=0x0000C000, but gives us the ability to selectively force buffers to stereo as we need them. We can already do this with [TextureOverride] sections if we identify the hashes we want mono, but I've been wanting to add a fuzzy matching ability to 3DMigoto for ages so you can just match on some characteristics of a resource instead of being exact.
The one addition to the driver that would *really* be useful is some ability to defer the decision, because sometimes the resource description may not be enough to determine if we need to force the buffer stereo or mono at creation time, and if we could defer that until we see what shader it is used with it would help tremendously (I had to jump through all sorts of hoops to work around this limitation in Dreamfall Chapters - my resource copying code is awesome enough that I could, but it wasn't easy).
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"]
Well, we pretty much know exactly what this flag does, so why don't we just replicate it in 3DMigoto instead? We can use StereoFlagsDX10=0x00004000 and have 3DMigoto force the default creation mode of any buffers that don't have the RTV bind flag to mono, and that should have the same effect as StereoFlagsDX10=0x0000C000, but gives us the ability to selectively force buffers to stereo as we need them. We can already do this with [TextureOverride] sections if we identify the hashes we want mono, but I've been wanting to add a fuzzy matching ability to 3DMigoto for ages so you can just match on some characteristics of a resource instead of being exact.
[/quote]
I totally understand the logic behind it! But sadly I had enough of fixing this game:) I actually do want to enjoy it for once ;)) And my current fix, allows me to do just that, almost flawless, except well for those pesky tiny lights ;))
But, now I am very curios:
What does finding all the buffers that don't have the RTV mean exactly - fixing wise? Just trial & error on all compute shaders in this game? The one eye bug is related to lots of shaders and locations and that needs the UpdateSubResource fix as well. This would definitely require another full playthrough to find all of them...
I agree! That if we would have a way to start with 0x4000 and use a wildcard "all that have RTV = mono", then it would be easier to find the ones that need to be stereo, instead of finding hundreds of them that need to be mono! At least this is how I see it. (I haven't looked into it, but just looking in the ShaderCache at the number of Compute Shaders makes my skin ...)
DarkStarSword said:
Well, we pretty much know exactly what this flag does, so why don't we just replicate it in 3DMigoto instead? We can use StereoFlagsDX10=0x00004000 and have 3DMigoto force the default creation mode of any buffers that don't have the RTV bind flag to mono, and that should have the same effect as StereoFlagsDX10=0x0000C000, but gives us the ability to selectively force buffers to stereo as we need them. We can already do this with [TextureOverride] sections if we identify the hashes we want mono, but I've been wanting to add a fuzzy matching ability to 3DMigoto for ages so you can just match on some characteristics of a resource instead of being exact.
I totally understand the logic behind it! But sadly I had enough of fixing this game:) I actually do want to enjoy it for once ;)) And my current fix, allows me to do just that, almost flawless, except well for those pesky tiny lights ;))
But, now I am very curios:
What does finding all the buffers that don't have the RTV mean exactly - fixing wise? Just trial & error on all compute shaders in this game? The one eye bug is related to lots of shaders and locations and that needs the UpdateSubResource fix as well. This would definitely require another full playthrough to find all of them...
I agree! That if we would have a way to start with 0x4000 and use a wildcard "all that have RTV = mono", then it would be easier to find the ones that need to be stereo, instead of finding hundreds of them that need to be mono! At least this is how I see it. (I haven't looked into it, but just looking in the ShaderCache at the number of Compute Shaders makes my skin ...)
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
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
It's kind of amazing to me that this bug has been missed for so long, but then again I suppose UpdateSubresource() is usually updating a mono 2D texture, or maybe a constant buffer that can't be stereo, and it is entirely possible that this bug is specific to buffers, not textures - they're certainly a lot harder to see that something is broken, since you can't just dump them out as a stereo image and look at them, and nvidia's reverse stereo blit doesn't work with them so you can't even dump them to a file to examine them like we can with stereo pairs of 2D textures. That's the beauty of using my buffer debug shaders though - since they render everything on the GPU they will show differences in the buffers between the eyes - it's really the only way to see stereo buffers.
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
It took me literally 2 hours to find this bug:)) Freaking annoying and frustrating DSS;)) (And I bet you didn't see it!)
Some of the Compute shaders you committed have a blank line in the header/top. The shaders would fail silently to compile (no audio/log warning) but they would simple fail! However, when I copied one shader at a time and press F10 to reload, I would get the BOP sound! Looking at the shader code I couldn't directly see it, as everything looked perfect!
However, the problem was here:
Resolution was simple as possible:
There are a few of them like this! I bet is the "\n" at the end of the injector;))
FINALLY, I was able to get it working! Now for some testing Muhaha!:)
(I am using 3DMigoto 1.2.67. Don't know if this is a known bug, but from the github notifications, I don't think so;) )
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)
Hmmm...
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)
Nope, the blank line doesn't cause problems by itself, but I bet I know what is - I bet you somehow converted the file to DOS/Windows style newlines \r\n (how did you grab these files? They should have been Unix style newlines on github), but these files are supposed to use Unix style newlines \n - I can easily see this bug with cmd_Decompiler:
Works fine, but:
Created a corrupt shader.
I'll take a look at this in a little while - there's no reason we shouldn't be able to cope with DOS style newlines, and if it cost you time it will definitely bite someone else sooner or later.
OK, I'll take a look at that as well. I was working off your 0.61 version with StereoFlagsDX10=0x00004000. If you're using StereoFlagsDX10=0x0000C000 then it means some UAVs won't have been automatically stereoised, so we will need to identify them and use [TextureOverrides] to force them to stereo (assuming the info nvidia gave us about the 0x00008000 flag is accurate). Alternatively we could identify why 0x00004000 isn't enough and work from that direction - if it turns out to be more manifestations of the UpdateSubresource bug we can add a workaround directly in 3DMigoto.
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
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)
Really sorry that this cost you time - it was an off by one error in Flugan's assembler that didn't properly strip carriage returns from blank lines and mistook the blank line for the shader model - it will be fixed in the next release of 3DMigoto and cmd_Decompiler:
https://github.com/bo3b/3Dmigoto/commit/1113fdd955ea1cfa56a8124cab5d450093810ded
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
Hehe nothing to worry about, now at least I know about it;) and where to look! I knew about TABS not being liked inside ASM shaders;) Had no idea before, that empty new lines weren't working. Is also my fault, as I modified some of them using Windows Notepad instead of Notepad++ so... :D
Played a bit more with the 0x4000 flag, and even if we add the UpdateSubresource() fix in 3DMigoto we will need to find some UVS to make them mono as they are stereo which is wrong.
This is why I think doing the other thing, starting from 0xC000 and finding the UAVs that need stereorization will be easier:) 0x8000 addresses the UpdateSubresource() problem it seems;)
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)
https://github.com/bo3b/3Dmigoto/issues/36
I'll take a look at this shortly.
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
Now, if we use StereoFlagsDX10 = 0x00004000 this is easy because all UAVs are stereoised, as you can see here (explanation of the lines in this image below):
StereoFlagsDX10 = 0x00004000:
But if we use StereoFlagsDX10 = 0x0000C000 then the rules change so that buffers must have the RTV bind flag to be stereoised, but there's a problem - structured buffers cannot have the RTV flag - they only support UAV and SRV bind flags, so attempting to use RTV causes the resource creation to fail and the debug shader marks them as INVALID:
StereoFlagsDX10 = 0x0000C000:
For completeness, this is how it behaves with StereoFlagsDX10 = 0x00000000. In this case the compute shaders only run for the right eye and UAVs are not automatically stereoised, so most of this is mono. One surprise to me here is that setting the creation mode to stereo actually DID have an effect on regular buffer UAVs, but only those that also had the RTV bind flag, so again this could not stereoise structured buffer UAVs:
StereoFlagsDX10 = 0x00000000:
Explanation of the lines in those images:
Buffer/Struct: Indicates whether the buffer written to was a regular buffer or a structured buffer
PS/CS: Indicates what type of shader was used to write to this buffer
(UAV/RTV) in brackets: Indicates how the pixel shader wrote to the UAV. Not applicable to non-UAVs or compute shaders. I didn't bother trying all permutations here, mostly because 3DMigoto has issues trying to bind more than one UAV to a pixel shader at a time (the DirectX API to do this sucks, and I haven't gone to enough heroics to make this work regardless).
RTV+UAV+SRV: Indicates the bind flags used to create the buffer. RTV = Render Target View, UAV = Unordered Access View, SRV = Shader Resource View
If a line contains "xxx -> yyy" it means the buffer or structured buffer was copied from one resource to another to get it into the debug shader. To read it from the debug shader I had to have the SRV bind flag, so if that wasn't in the resource I wrote to I had to make a copy with SRV. I also copied all StructuredBuffer UAVs into a regular buffer with bind flags known to be stereoisable regardless of StereoFlagsDX10 to make sure that they could be shown in stereo, if the source resource was stereo.
LEFT/RIGHT: Indicates which eye the shader was running in that wrote that value. If the resource is stereo you will see alternate values on each side, if the resource was mono you will see both sides indicate RIGHT.
INVALID: Indicates that the buffer hasn't been written to - either it wasn't created, or the shader that wrote it didn't run in the that eye.
Creation Mode: Indicates what the 3D Vision surface creation mode was set to when the resources were created. You will notice that the driver respects mono creation mode for both regular and structured buffers, but only respects stereo creation mode for UAVs if they are also RTVs, which discounts structured buffers.
This testcase is available here (requires 3DMigoto 1.2.69):
https://github.com/DarkStarSword/3d-fixes/tree/master/stereo_buffer_tests
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
* not super likely, because profile switches don't seem to help.
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
Reading all that makes sense (once I actually had to the time to sit down and read it). Indeed there is no Stereo Structured Buffer or it doesn't make sense.
And yet! This flag makes this game (and other Frosbite 3 game that I tested with the 0xC000 flag) almost perfect (you still need to fix the normal stuff, shadows, reflections, etc, but a lot of stuff, is at the "right location, in both eyes").
I wouldn't discard this flag just yet;)
@bo3b:
If you believe this might be helpful for everyone, or if Nvidia can give us some more info, I don't see why not:) And I am +1 for that!
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)
Just wanted to say that you guys are geniuses (genii?) :D
The lengths you guys go to to get things to work is absolutely astonishing!
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.
Well, we pretty much know exactly what this flag does, so why don't we just replicate it in 3DMigoto instead? We can use StereoFlagsDX10=0x00004000 and have 3DMigoto force the default creation mode of any buffers that don't have the RTV bind flag to mono, and that should have the same effect as StereoFlagsDX10=0x0000C000, but gives us the ability to selectively force buffers to stereo as we need them. We can already do this with [TextureOverride] sections if we identify the hashes we want mono, but I've been wanting to add a fuzzy matching ability to 3DMigoto for ages so you can just match on some characteristics of a resource instead of being exact.
The one addition to the driver that would *really* be useful is some ability to defer the decision, because sometimes the resource description may not be enough to determine if we need to force the buffer stereo or mono at creation time, and if we could defer that until we see what shader it is used with it would help tremendously (I had to jump through all sorts of hoops to work around this limitation in Dreamfall Chapters - my resource copying code is awesome enough that I could, but it wasn't easy).
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
I totally understand the logic behind it! But sadly I had enough of fixing this game:) I actually do want to enjoy it for once ;)) And my current fix, allows me to do just that, almost flawless, except well for those pesky tiny lights ;))
But, now I am very curios:
What does finding all the buffers that don't have the RTV mean exactly - fixing wise? Just trial & error on all compute shaders in this game? The one eye bug is related to lots of shaders and locations and that needs the UpdateSubResource fix as well. This would definitely require another full playthrough to find all of them...
I agree! That if we would have a way to start with 0x4000 and use a wildcard "all that have RTV = mono", then it would be easier to find the ones that need to be stereo, instead of finding hundreds of them that need to be mono! At least this is how I see it. (I haven't looked into it, but just looking in the ShaderCache at the number of Compute Shaders makes my skin ...)
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)