[quote="Oomek"]Seems like only photoshop is smart enough to take advantage of those orphaned bits :)[/quote]
Hehe;) Yeah;) That's why everything I produce with Photoshop I open in Ms Paint after to see if it still works right...lol:)))
Oomek said:Seems like only photoshop is smart enough to take advantage of those orphaned bits :)
Hehe;) Yeah;) That's why everything I produce with Photoshop I open in Ms Paint after to see if it still works right...lol:)))
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
3DMigoto 1.2.33 is out. It doesn't have any of the improvements people have been asking for recently, but it does fix a regression in the arbitrary resource copying where the least detailed mip-map would be used instead of the most detailed (this was required to fix reflections in Far Cry Primal). This regression was introduced in 1.2.28 when the views were reworked.
3DMigoto 1.2.33 is out. It doesn't have any of the improvements people have been asking for recently, but it does fix a regression in the arbitrary resource copying where the least detailed mip-map would be used instead of the most detailed (this was required to fix reflections in Far Cry Primal). This regression was introduced in 1.2.28 when the views were reworked.
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
3DMigoto 1.2.32 and later versions are now supporting SBS output, right? Could this routine also be used to convert SBS output from games into 3DVision output? This would us allow to use the stereoscopic SBS output from Unreal Engine 4 games for 3Dvision...
3DMigoto 1.2.32 and later versions are now supporting SBS output, right? Could this routine also be used to convert SBS output from games into 3DVision output? This would us allow to use the stereoscopic SBS output from Unreal Engine 4 games for 3Dvision...
My original display name is 3d4dd - for some reason Nvidia changed it..?!
Yes - I already have a proof of concept of converting SBS to 3D Vision:
[url]https://forums.geforce.com/default/topic/685657/3d-vision/3dmigoto-now-open-source-/post/4810934/#4810934[/url]
[url]https://forums.geforce.com/default/topic/908302/3d-vision/how-to-play-vr-images-and-videos-in-3dvision-using-the-whirligig-vr-player/post/4810984/#4810984[/url]
Had some issues trying to get it working with ARK, but they were more related to getting ARK working in side by side mode with 3D vision enabled at all.
Had some issues trying to get it working with ARK, but they were more related to getting ARK working in side by side mode with 3D vision enabled at all.
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
I'm really struggling with using the resource copying function of 3DMigoto. I'm finding the documentation for this functionality a little bit lacking on the wiki, there's a few things that aren't really explained entirely, so I'll ask a few questions later to clear up some of the issues I have.
The shader I'm working on is for the fog of war effect in Xcom 2, which renders in 2D. I'm trying to fix it in the PS, which receives a texcoord in world space, so I'm trying to a) copy a constant buffer from a VS that contains a VPM, and b) use DSS's matrix.hlsl to calculate the inverse (although I could potentially also copy another buffer from the same VS, but thought this would be cleaner) in order to attempt to do the fix, however when I follow the examples for this functionality it breaks the shader. So, if someone could take a look and see if I'm using this wrong, and provide any corrections it would be appreciated.
Some questions I have regarding this functionality are:
-What exactly are the requirements for the declaration in the shader where you are using the copied resource? ie. Does it matter what name comes after 'cbuffer'? Here I have 'VPM', but in the original VS that buffer is called 'VSOffsetConstants' (which I've tried, and also tried PSOffsetConstants). In the Mad Max example, I believe there was some modifying of the naming, but it's not clear at all what is allowed/required.
-If there are any naming requirements, for example if it's necessary to use PSOffsetConstants, what happens if a shader already has a buffer using the same name in another buffer slot? Does that conflict at all?
-Are there any restrictions regarding using a constant buffer copied from a VS and using it in another type of shader (PS/CS/etc)?
-Are you allowed to copy more than one resource into a shader? I would assume so, but nothing specifically says so either way.
And here's an unrelated question: in some shaders, there is a matrix called ScreenToWorldMatrix, and others there are InvViewProjectionMatrix. Would they potentially be the same, or are they likely different?
3D Gaming Rig: CPU: i7 7700K @ 4.9Ghz | Mobo: Asus Maximus Hero VIII | RAM: Corsair Dominator 16GB | GPU: 2 x GTX 1080 Ti SLI | 3xSSDs for OS and Apps, 2 x HDD's for 11GB storage | PSU: Seasonic X-1250 M2| Case: Corsair C70 | Cooling: Corsair H115i Hydro cooler | Displays: Asus PG278QR, BenQ XL2420TX & BenQ HT1075 | OS: Windows 10 Pro + Windows 7 dual boot
[quote="DJ-RK"]I'm finding the documentation for this functionality a little bit lacking on the wiki, there's a few things that aren't really explained entirely, so I'll ask a few questions later to clear up some of the issues I have.[/quote]Please feel free to expand the wiki with anything you learn, add examples, copy my answers to it, etc.
[quote]I'm trying to fix it in the PS, which receives a texcoord in world space, so I'm trying to a) copy a constant buffer from a VS that contains a VPM, and b) use DSS's matrix.hlsl to calculate the inverse (although I could potentially also copy another buffer from the same VS, but thought this would be cleaner) in order to attempt to do the fix, however when I follow the examples for this functionality it breaks the shader[/quote]Do you mean the shader gets broken by just doing the copy without otherwise modifying it?
[quote]So, if someone could take a look and see if I'm using this wrong, and provide any corrections it would be appreciated.
In my d3dx.ini file I have the following:
[code][ResourceVPM]
[ShaderOverrideVSwithVPM]
Hash = ea2719f505532258
ResourceVPM = vs-cb1
[ShaderOverrideFogofwar]
Hash = 5ae139574f8ab8eb
ps-cb13 = ResourceVPM
[/code][/quote]
This looks fine to me. It will do a fully copy since you are using an intermediate resource and haven't specified otherwise, but that should be ok (you can either specify the 'ref' keyword in the copy *to* the custom resource, or you might add 'max_copies_per_frame=1' to the resource section to make sure that it doesn't perform excessive amounts of full copies). If the vertex + pixel shader are used in the same draw call you could alternatively just match on either one and do:
[code]
ps-cb13 = vs-cb1
[/code]
But your above code should work. Notably if you do match two separate shaders for the same draw call it is important to keep in mind that 3DMigoto processes their command lists in the same order as the rendering pipeline (Vertex -> Hull -> Domain -> Geometry -> Pixel), so if you were trying to copy something from the pixel shader to the vertex shader it would be best done with a single section (like I did in Mad Max to fix the lens flares), but copying forwards in the pipeline should work either way. Also note that when copying forwards in the pipeline if working in HLSL it is possible to add additional texcoord outputs & inputs and use them to pass values through.
[quote]-What exactly are the requirements for the declaration in the shader where you are using the copied resource?[/quote]The only requirement is they start with 'Resource' to disambiguate them from other sections in the ini file, and that their name be unique (and 3DMigoto warns if the name is not unique). It does not need to be related to the name used in the shader (I will usually name them consistently with the game if it makes sense, but that's just for my own benefit).
[quote]-If there are any naming requirements, for example if it's necessary to use PSOffsetConstants, what happens if a shader already has a buffer using the same name in another buffer slot? Does that conflict at all?[/quote]As above, the name in the ini file does not matter, but if you were to copy the definition in the HLSL file and that had a naming conflict you would need to rename it (hopefully it would fail to compile if there was a conflict, but I can't say I have tested this).
[quote]-Are there any restrictions regarding using a constant buffer copied from a VS and using it in another type of shader (PS/CS/etc)?[/quote]There are no restrictions for constant buffers. There are other cases where a copy may fail, but these are largely down to restrictions in DirectX (and in the case of using a stereo2mono copy, the driver), and those are really poorly documented and for the most part I've found them out the hard way, and am still finding new ones. Some of these I'm able to hide in 3DMigoto (e.g. copying a depth buffer to a texture slot works because 3DMigoto handles the format conversion, likewise copying a vertex buffer to a texture slot works because 3DMigoto converts it into a structured buffer and to a constant buffer slot works because 3DMigoto cuts it down to size if it was too large), but others I am not able to hide completely, or may be able to but don't do so yet (see below).
[quote]-Are you allowed to copy more than one resource into a shader? I would assume so, but nothing specifically says so either way.[/quote]Yes, it was important for me that I did not place any arbitrary restrictions on this that might get in someone's way later on. You can have as many resources and copy operations as you like :)
If you are having issues copying a resource, there are a few things worth trying:
- Check the d3d11_log.txt to make sure that the copy directives show up in the ini parsing and that there are no warnings or errors.
- Check the d3d11_log.txt for any errors about creating resources or views. If this is happening it will likely be repeated... a lot. Please report any of these you find - I am trying to understand all the combinations that don't work so I can try to solve them, but these combinations are not documented anywhere and the only way I find out is from these messages (or the DX debug layer).
- Try explicitly doing a full copy with the 'copy' keyword
- Try explicitly doing a copy by reference with the 'reference' keyword
- If using an intermediate resource, try different combinations of the above on the copy to the intermediate resource, and the copy from the intermediate resource.
- If you leave the resource bound to the pipeline after the draw call frame analysis can be used to dump it out (if you unbind it with 'post ps-cb13 = null' it will not be seen in frame analysis)
Off the top of my head, here are some of the nitty gritty details - as I said above, most of these restrictions come from DX, not from us:
- Try to avoid binding a resource as both an input and output simultaneously (it's good practice to unbind a resource after the draw call with the something like 'post vs-cb13 = null' in case the game tries to bind it elsewhere later).
- Copying by reference may not work if copying between different slot types, unless the game created the resource with the required bind flags.
- Constant buffers can be copied by reference to other constant buffer slots, and as they can never be bound as an output there is no need to worry about IO conflicts. To copy these to any other slot type, a full copy must be used. Likewise, copying anything else to a constant buffer slot must use a full copy, and 3DMigoto will limit it to the maximum supported size of a constant buffer, which is 64K.
- Avoid vs-cb12, which is used by the 3D Vision driver
- If a constant buffer slot is not working, try a different constant buffer slot (I fully expect that there is a profile setting to change the slot that the driver uses, so suspect any that aren't working).
- If you are trying to opportunistically copy a resource that you aren't certain will be bound, use the 'unless_null' keyword.
- To avoid using stale data from a previous frame, use the Present call to NULL out the intermediate resource (this is fast - it does not throw it away, only marks it as invalid until it is next set). If you do this you will need to be certain that you set the resource from something in the frame prior to using it.
- If you are doing any full copies (keeping in mind that if you don't specify to do a full copy 3DMigoto will decide for itself whether it should or not, and errs on the side of using a full copy in situations where there isn't a clear answer), use 'max_copies_per_frame=1' in the resource section to limit the number of times the copy operation might be performed to avoid adverse performance impacts. If you really need the result after the last draw call instead of the first, try to use a copy by reference if possible.
- Copying from one intermediate resource to another should work in theory, but there seem to be a number of edge cases that 3DMigoto is not yet handling (mostly related to certain options/formats requiring bind flags to be set which will not be in this case), so in many situations this may fail.
- The copy operations are logged in the frame analysis log.txt, so you can check if they are being executed by checking that.
- Be SURE to define the resource in the target shader. HLSL shaders will fail to compile if you don't, but it turns out that assembly shaders will assemble and kind of work, except for when they don't (e.g. the sample_l_indexable instruction may or may not ignore the mip-map level and behave like a regular sample instruction if the texture was not defined... found this out the hard way).
- If you are copying a stereo (or mono) resource and it is not working correctly, try explicitly adding the 'stereo' or 'mono' keywords. Note that in some cases the copy still seems to occur in mono regardless for a reason I don't fully understand (driver heuristics) and in that case you may need to copy by reference (or use a custom shader to copy it instead).
- MSAA resources have additional restrictions, and should be resolved using a custom shader first (there is a 'resolve_msaa' keyword to do this in 3DMigoto, but it currently lacks any fallback if the hardware does not support the format being resolved, and there is no documentation anywhere for what formats are supported on what hardware). These do not work with stereo2mono, and there might be issues with copying them to certain other slots as well. They can be injected into a vertex shader, but 'model=vs_5_0' may be required in the ShaderOverride section to allow Texture2DMS.
- I discovered the other day that stereo2mono does not work correctly for mip-maps - 3DMigoto attempts the copy for all mip-maps and subresources, but the driver only performs the reverse stereo blit on the most detailed mip-map level (I may be able to work around this with even more intermediate copies, but stereo2mono is already performing two copies per mip-map level as it is, plus will need an additional copy for MSAA resources when that's added).
DJ-RK said:I'm finding the documentation for this functionality a little bit lacking on the wiki, there's a few things that aren't really explained entirely, so I'll ask a few questions later to clear up some of the issues I have.
Please feel free to expand the wiki with anything you learn, add examples, copy my answers to it, etc.
I'm trying to fix it in the PS, which receives a texcoord in world space, so I'm trying to a) copy a constant buffer from a VS that contains a VPM, and b) use DSS's matrix.hlsl to calculate the inverse (although I could potentially also copy another buffer from the same VS, but thought this would be cleaner) in order to attempt to do the fix, however when I follow the examples for this functionality it breaks the shader
Do you mean the shader gets broken by just doing the copy without otherwise modifying it?
So, if someone could take a look and see if I'm using this wrong, and provide any corrections it would be appreciated.
This looks fine to me. It will do a fully copy since you are using an intermediate resource and haven't specified otherwise, but that should be ok (you can either specify the 'ref' keyword in the copy *to* the custom resource, or you might add 'max_copies_per_frame=1' to the resource section to make sure that it doesn't perform excessive amounts of full copies). If the vertex + pixel shader are used in the same draw call you could alternatively just match on either one and do:
ps-cb13 = vs-cb1
But your above code should work. Notably if you do match two separate shaders for the same draw call it is important to keep in mind that 3DMigoto processes their command lists in the same order as the rendering pipeline (Vertex -> Hull -> Domain -> Geometry -> Pixel), so if you were trying to copy something from the pixel shader to the vertex shader it would be best done with a single section (like I did in Mad Max to fix the lens flares), but copying forwards in the pipeline should work either way. Also note that when copying forwards in the pipeline if working in HLSL it is possible to add additional texcoord outputs & inputs and use them to pass values through.
-What exactly are the requirements for the declaration in the shader where you are using the copied resource?
The only requirement is they start with 'Resource' to disambiguate them from other sections in the ini file, and that their name be unique (and 3DMigoto warns if the name is not unique). It does not need to be related to the name used in the shader (I will usually name them consistently with the game if it makes sense, but that's just for my own benefit).
-If there are any naming requirements, for example if it's necessary to use PSOffsetConstants, what happens if a shader already has a buffer using the same name in another buffer slot? Does that conflict at all?
As above, the name in the ini file does not matter, but if you were to copy the definition in the HLSL file and that had a naming conflict you would need to rename it (hopefully it would fail to compile if there was a conflict, but I can't say I have tested this).
-Are there any restrictions regarding using a constant buffer copied from a VS and using it in another type of shader (PS/CS/etc)?
There are no restrictions for constant buffers. There are other cases where a copy may fail, but these are largely down to restrictions in DirectX (and in the case of using a stereo2mono copy, the driver), and those are really poorly documented and for the most part I've found them out the hard way, and am still finding new ones. Some of these I'm able to hide in 3DMigoto (e.g. copying a depth buffer to a texture slot works because 3DMigoto handles the format conversion, likewise copying a vertex buffer to a texture slot works because 3DMigoto converts it into a structured buffer and to a constant buffer slot works because 3DMigoto cuts it down to size if it was too large), but others I am not able to hide completely, or may be able to but don't do so yet (see below).
-Are you allowed to copy more than one resource into a shader? I would assume so, but nothing specifically says so either way.
Yes, it was important for me that I did not place any arbitrary restrictions on this that might get in someone's way later on. You can have as many resources and copy operations as you like :)
If you are having issues copying a resource, there are a few things worth trying:
- Check the d3d11_log.txt to make sure that the copy directives show up in the ini parsing and that there are no warnings or errors.
- Check the d3d11_log.txt for any errors about creating resources or views. If this is happening it will likely be repeated... a lot. Please report any of these you find - I am trying to understand all the combinations that don't work so I can try to solve them, but these combinations are not documented anywhere and the only way I find out is from these messages (or the DX debug layer).
- Try explicitly doing a full copy with the 'copy' keyword
- Try explicitly doing a copy by reference with the 'reference' keyword
- If using an intermediate resource, try different combinations of the above on the copy to the intermediate resource, and the copy from the intermediate resource.
- If you leave the resource bound to the pipeline after the draw call frame analysis can be used to dump it out (if you unbind it with 'post ps-cb13 = null' it will not be seen in frame analysis)
Off the top of my head, here are some of the nitty gritty details - as I said above, most of these restrictions come from DX, not from us:
- Try to avoid binding a resource as both an input and output simultaneously (it's good practice to unbind a resource after the draw call with the something like 'post vs-cb13 = null' in case the game tries to bind it elsewhere later).
- Copying by reference may not work if copying between different slot types, unless the game created the resource with the required bind flags.
- Constant buffers can be copied by reference to other constant buffer slots, and as they can never be bound as an output there is no need to worry about IO conflicts. To copy these to any other slot type, a full copy must be used. Likewise, copying anything else to a constant buffer slot must use a full copy, and 3DMigoto will limit it to the maximum supported size of a constant buffer, which is 64K.
- Avoid vs-cb12, which is used by the 3D Vision driver
- If a constant buffer slot is not working, try a different constant buffer slot (I fully expect that there is a profile setting to change the slot that the driver uses, so suspect any that aren't working).
- If you are trying to opportunistically copy a resource that you aren't certain will be bound, use the 'unless_null' keyword.
- To avoid using stale data from a previous frame, use the Present call to NULL out the intermediate resource (this is fast - it does not throw it away, only marks it as invalid until it is next set). If you do this you will need to be certain that you set the resource from something in the frame prior to using it.
- If you are doing any full copies (keeping in mind that if you don't specify to do a full copy 3DMigoto will decide for itself whether it should or not, and errs on the side of using a full copy in situations where there isn't a clear answer), use 'max_copies_per_frame=1' in the resource section to limit the number of times the copy operation might be performed to avoid adverse performance impacts. If you really need the result after the last draw call instead of the first, try to use a copy by reference if possible.
- Copying from one intermediate resource to another should work in theory, but there seem to be a number of edge cases that 3DMigoto is not yet handling (mostly related to certain options/formats requiring bind flags to be set which will not be in this case), so in many situations this may fail.
- The copy operations are logged in the frame analysis log.txt, so you can check if they are being executed by checking that.
- Be SURE to define the resource in the target shader. HLSL shaders will fail to compile if you don't, but it turns out that assembly shaders will assemble and kind of work, except for when they don't (e.g. the sample_l_indexable instruction may or may not ignore the mip-map level and behave like a regular sample instruction if the texture was not defined... found this out the hard way).
- If you are copying a stereo (or mono) resource and it is not working correctly, try explicitly adding the 'stereo' or 'mono' keywords. Note that in some cases the copy still seems to occur in mono regardless for a reason I don't fully understand (driver heuristics) and in that case you may need to copy by reference (or use a custom shader to copy it instead).
- MSAA resources have additional restrictions, and should be resolved using a custom shader first (there is a 'resolve_msaa' keyword to do this in 3DMigoto, but it currently lacks any fallback if the hardware does not support the format being resolved, and there is no documentation anywhere for what formats are supported on what hardware). These do not work with stereo2mono, and there might be issues with copying them to certain other slots as well. They can be injected into a vertex shader, but 'model=vs_5_0' may be required in the ShaderOverride section to allow Texture2DMS.
- I discovered the other day that stereo2mono does not work correctly for mip-maps - 3DMigoto attempts the copy for all mip-maps and subresources, but the driver only performs the reverse stereo blit on the most detailed mip-map level (I may be able to work around this with even more intermediate copies, but stereo2mono is already performing two copies per mip-map level as it is, plus will need an additional copy for MSAA resources when that's added).
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="DJ-RK"]And here's an unrelated question: in some shaders, there is a matrix called ScreenToWorldMatrix, and others there are InvViewProjectionMatrix. Would they potentially be the same, or are they likely different?[/quote]I would recommend dumping out both from a single frame with frame analysis and comparing them to be sure. In some games the same thing is used by different names, but in others there can be slight differences (e.g. FC4/Primal has distinctions between the view-projection and view-rotation-projection matrices and they cannot be used interchangeably, and has three or four different names for the depth buffer, some of which seem equivalent and some are scaled differently).
DJ-RK said:And here's an unrelated question: in some shaders, there is a matrix called ScreenToWorldMatrix, and others there are InvViewProjectionMatrix. Would they potentially be the same, or are they likely different?
I would recommend dumping out both from a single frame with frame analysis and comparing them to be sure. In some games the same thing is used by different names, but in others there can be slight differences (e.g. FC4/Primal has distinctions between the view-projection and view-rotation-projection matrices and they cannot be used interchangeably, and has three or four different names for the depth buffer, some of which seem equivalent and some are scaled differently).
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
[size="M"][center][color="orange"]3DMigoto 1.2.34 is out:[/color]
[url]https://github.com/bo3b/3Dmigoto/releases[/url][/center][/size]
This release is to fix bugs with ASM shader handling. This version should properly handle ASM text files, properly generate the corresponding .bin files with cache_shaders=1, and properly reload the .bin first and not reassemble.
In particular this removes all references to the *_reasm.txt files. Those were for assembler validation and are no longer necessary.
There should only be four files now, with a sensible naming convention, e.g.:
[i]e706a624b9fe754a-ps_replace.txt[/i] - HLSL decompiled shader
[i]e706a624b9fe754a-ps_replace.bin[/i] - binary cached version of HLSL shader
[i]e706a624b9fe754a-ps.txt[/i] - ASM text file shader
[i]e706a624b9fe754a-ps.bin[/i] - binary cached version of ASM shader.
If you have any fixes with _reasm.txt files, you should delete all of those, or reinstall so that caching regenerates the .bin files. They will cause problems, as I removed the workarounds for those files when hunting.
Let me know if you see any new bugs, I refactored some big chunks of code, and it's always possible to have missed something. Tested only in Witcher 3.
This release is to fix bugs with ASM shader handling. This version should properly handle ASM text files, properly generate the corresponding .bin files with cache_shaders=1, and properly reload the .bin first and not reassemble.
In particular this removes all references to the *_reasm.txt files. Those were for assembler validation and are no longer necessary.
There should only be four files now, with a sensible naming convention, e.g.:
e706a624b9fe754a-ps_replace.txt - HLSL decompiled shader e706a624b9fe754a-ps_replace.bin - binary cached version of HLSL shader e706a624b9fe754a-ps.txt - ASM text file shader e706a624b9fe754a-ps.bin - binary cached version of ASM shader.
If you have any fixes with _reasm.txt files, you should delete all of those, or reinstall so that caching regenerates the .bin files. They will cause problems, as I removed the workarounds for those files when hunting.
Let me know if you see any new bugs, I refactored some big chunks of code, and it's always possible to have missed something. Tested only in Witcher 3.
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
Awesome news bo3b! AND BIG THANKS FOR IT!
One question though;) Will the shaders be recompiled when the game encounters them? or will it compile all the txt files that are in the Shaders Folder?:)
One question though;) Will the shaders be recompiled when the game encounters them? or will it compile all the txt files that are in the Shaders Folder?:)
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
Same behavior as HLSL files, they'll get reassembled on demand. If cache_shaders is set, it will then generate a .bin file which will be used from then on.
In principle we could make it generate the .bin for every file at launch, but it hasn't proven to be a problem in the past to do load on demand.
Same behavior as HLSL files, they'll get reassembled on demand. If cache_shaders is set, it will then generate a .bin file which will be used from then on.
In principle we could make it generate the .bin for every file at launch, but it hasn't proven to be a problem in the past to do load on demand.
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
BTW, you could also generate all the .bin files using the command line assembler now, and send them along with the fix as a pre-assembled set of shaders. They'll be loaded now, whereas before the .bin were ignored for ASM files.
If you go that route, please still include the .txt files as reference for other ShaderHackers. I really, really don't want to get into a mode where we only ship binaries.
As a side note, I used 7zip on maximum compression, and the archive was 13.5M with just text files. As a general idea, I think that .zip is what we should ship, because it's more universal, no one will have trouble with a .zip file, whereas a few people will get snagged by .7z or .rar files. Just thought it was weird that text files didn't compress better for .rar.
If you include the presumably not compressible .bin files, that will make the archive 80% bigger, but that's still OK in today's world. Tradeoff of having a slow download versus a slow first launch.
BTW, you could also generate all the .bin files using the command line assembler now, and send them along with the fix as a pre-assembled set of shaders. They'll be loaded now, whereas before the .bin were ignored for ASM files.
If you go that route, please still include the .txt files as reference for other ShaderHackers. I really, really don't want to get into a mode where we only ship binaries.
As a side note, I used 7zip on maximum compression, and the archive was 13.5M with just text files. As a general idea, I think that .zip is what we should ship, because it's more universal, no one will have trouble with a .zip file, whereas a few people will get snagged by .7z or .rar files. Just thought it was weird that text files didn't compress better for .rar.
If you include the presumably not compressible .bin files, that will make the archive 80% bigger, but that's still OK in today's world. Tradeoff of having a slow download versus a slow first launch.
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
[quote="bo3b"]BTW, you could also generate all the .bin files using the command line assembler now, and send them along with the fix as a pre-assembled set of shaders. They'll be loaded now, whereas before the .bin were ignored for ASM files.
If you go that route, please still include the .txt files as reference for other ShaderHackers. I really, really don't want to get into a mode where we only ship binaries.
As a side note, I used 7zip on maximum compression, and the archive was 13.5M with just text files. As a general idea, I think that .zip is what we should ship, because it's more universal, no one will have trouble with a .zip file, whereas a few people will get snagged by .7z or .rar files. Just thought it was weird that text files didn't compress better for .rar.
If you include the presumably not compressible .bin files, that will make the archive 80% bigger, but that's still OK in today's world. Tradeoff of having a slow download versus a slow first launch.
[/quote]
Yeah! Big thanks bo3b! I was thinking of making the following:
- Use cmd_compiler to get the .bin for all the asm shaders. + add the HLSL shaders as text files (which are around 10 I believe in the whole fix)
- All the txt and source code I will zip-up and put it next to the shaders. (so we still have the reference and the actual ASM shader code) and place it inside the fix (in a folder called ASMSourceCode or similar)
This will make the archive smaller as well, we still have the source code (inside the zip) and the .bins that are actually used.
What do you think?:)
bo3b said:BTW, you could also generate all the .bin files using the command line assembler now, and send them along with the fix as a pre-assembled set of shaders. They'll be loaded now, whereas before the .bin were ignored for ASM files.
If you go that route, please still include the .txt files as reference for other ShaderHackers. I really, really don't want to get into a mode where we only ship binaries.
As a side note, I used 7zip on maximum compression, and the archive was 13.5M with just text files. As a general idea, I think that .zip is what we should ship, because it's more universal, no one will have trouble with a .zip file, whereas a few people will get snagged by .7z or .rar files. Just thought it was weird that text files didn't compress better for .rar.
If you include the presumably not compressible .bin files, that will make the archive 80% bigger, but that's still OK in today's world. Tradeoff of having a slow download versus a slow first launch.
Yeah! Big thanks bo3b! I was thinking of making the following:
- Use cmd_compiler to get the .bin for all the asm shaders. + add the HLSL shaders as text files (which are around 10 I believe in the whole fix)
- All the txt and source code I will zip-up and put it next to the shaders. (so we still have the reference and the actual ASM shader code) and place it inside the fix (in a folder called ASMSourceCode or similar)
This will make the archive smaller as well, we still have the source code (inside the zip) and the .bins that are actually used.
What do you think?:)
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
Hi guys;)
Well Using 3DMigoto 1.2.34 and I think I found a bug related to HLSL shaders...
[s]So, I have my shader in question in ROTTR with filename "33586be9d6e9bae3-vs_replace.txt" (This is the BLOOD on screen and it doesn't appear until you are injured).
The wrapper doesn't seem to pick it up or SWAP IT!!!
BUT! If I manually find it (hunting=2) and dump it again it seems to load the .bin file associated with it and then it starts working.
Also, when I am going through the shaders I can't see the description I have in the TXT file at the top. This clearly shows that the HLSL shader is not swapped or the .bin is not used but instead the original shader is used.
This didn't happen in 1.2.32 but then again 1.2.34 has major changes in this part... I think this is a bug:)
Other HLSL shaders seem to work just fine;) (I wonder IF, the wrapper changes the shader, BUT then the engine OVERWRITES it with it's own version...HMMM)[/s]
NVM! I actually found what the problem was... I was having both a HLSL and ASM variant and the ASM variant took precedence over the HLSL one. I was thinking if you can add a beep or some type of sound when this happens? (both an ASM and HLSL shader exist with the same CRC to tell there is a duplicate and we must chose one of them (like the silly me ^_^)). Is this possible?
Well Using 3DMigoto 1.2.34 and I think I found a bug related to HLSL shaders...
So, I have my shader in question in ROTTR with filename "33586be9d6e9bae3-vs_replace.txt" (This is the BLOOD on screen and it doesn't appear until you are injured).
The wrapper doesn't seem to pick it up or SWAP IT!!!
BUT! If I manually find it (hunting=2) and dump it again it seems to load the .bin file associated with it and then it starts working.
Also, when I am going through the shaders I can't see the description I have in the TXT file at the top. This clearly shows that the HLSL shader is not swapped or the .bin is not used but instead the original shader is used.
This didn't happen in 1.2.32 but then again 1.2.34 has major changes in this part... I think this is a bug:)
Other HLSL shaders seem to work just fine;) (I wonder IF, the wrapper changes the shader, BUT then the engine OVERWRITES it with it's own version...HMMM)
NVM! I actually found what the problem was... I was having both a HLSL and ASM variant and the ASM variant took precedence over the HLSL one. I was thinking if you can add a beep or some type of sound when this happens? (both an ASM and HLSL shader exist with the same CRC to tell there is a duplicate and we must chose one of them (like the silly me ^_^)). Is this possible?
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
Wow, that's a lot of information! Definitely appreciate the detailed write up. I'll see if I can contribute to the wiki where I can as a sign of gratitude for all the help you've given.
I read it over last night before going to bed, and my brain was a little too fried to process most of it. I'll read it over a few times when I get the time and try a few of the suggestions, and hopefully something will stick. For now I'll just make a few responses to your post where I can.
[quote="DarkStarSword"]Do you mean the shader gets broken by just doing the copy without otherwise modifying it?[/quote]
No, just doing the copy function alone doesn't cause any errors. If I just comment out the one line in the PS above: r2=mul(ivp,tmp); then the shader remains functional as nothing gets modified. With that code in place, the fog of war covers the entire screen, which I believe is the same result as having the shader output set to 0.
[quote]Also note that when copying forwards in the pipeline if working in HLSL it is possible to add additional texcoord outputs & inputs and use them to pass values through.[/quote]
Yeah, unfortunately the VS for this PS does not use the VPM, so I'm copying from a completely unrelated VS.
[quote][quote]-What exactly are the requirements for the declaration in the shader where you are using the copied resource?[/quote]The only requirement is they start with 'Resource' to disambiguate them from other sections in the ini file, and that their name be unique (and 3DMigoto warns if the name is not unique). It does not need to be related to the name used in the shader (I will usually name them consistently with the game if it makes sense, but that's just for my own benefit).[/quote]
I was actually referring to the declaration in the PS where I'm copying the shader to, not the declaration in the d3dx.ini file. You kinda mention this later on in your response, but I'm still not 100% clear on this, whether there's a specific naming convention I need to use here, or if I'm free to use anything I choose.
[quote]- Try to avoid binding a resource as both an input and output simultaneously (it's good practice to unbind a resource after the draw call with the something like 'post vs-cb13 = null' in case the game tries to bind it elsewhere later).[/quote]
Sorry, but could you elaborate a little bit more about binding resources? What does this entail, and how do you bind, or avoid binding a resource? If it's not too much to ask, could you also elaborate a bit more on copying vs copying by reference?
(sorry if it's a bit elementary for me to be asking you to spell some of this out)
Wow, that's a lot of information! Definitely appreciate the detailed write up. I'll see if I can contribute to the wiki where I can as a sign of gratitude for all the help you've given.
I read it over last night before going to bed, and my brain was a little too fried to process most of it. I'll read it over a few times when I get the time and try a few of the suggestions, and hopefully something will stick. For now I'll just make a few responses to your post where I can.
DarkStarSword said:Do you mean the shader gets broken by just doing the copy without otherwise modifying it?
No, just doing the copy function alone doesn't cause any errors. If I just comment out the one line in the PS above: r2=mul(ivp,tmp); then the shader remains functional as nothing gets modified. With that code in place, the fog of war covers the entire screen, which I believe is the same result as having the shader output set to 0.
Also note that when copying forwards in the pipeline if working in HLSL it is possible to add additional texcoord outputs & inputs and use them to pass values through.
Yeah, unfortunately the VS for this PS does not use the VPM, so I'm copying from a completely unrelated VS.
-What exactly are the requirements for the declaration in the shader where you are using the copied resource?
The only requirement is they start with 'Resource' to disambiguate them from other sections in the ini file, and that their name be unique (and 3DMigoto warns if the name is not unique). It does not need to be related to the name used in the shader (I will usually name them consistently with the game if it makes sense, but that's just for my own benefit).
I was actually referring to the declaration in the PS where I'm copying the shader to, not the declaration in the d3dx.ini file. You kinda mention this later on in your response, but I'm still not 100% clear on this, whether there's a specific naming convention I need to use here, or if I'm free to use anything I choose.
- Try to avoid binding a resource as both an input and output simultaneously (it's good practice to unbind a resource after the draw call with the something like 'post vs-cb13 = null' in case the game tries to bind it elsewhere later).
Sorry, but could you elaborate a little bit more about binding resources? What does this entail, and how do you bind, or avoid binding a resource? If it's not too much to ask, could you also elaborate a bit more on copying vs copying by reference?
(sorry if it's a bit elementary for me to be asking you to spell some of this out)
3D Gaming Rig: CPU: i7 7700K @ 4.9Ghz | Mobo: Asus Maximus Hero VIII | RAM: Corsair Dominator 16GB | GPU: 2 x GTX 1080 Ti SLI | 3xSSDs for OS and Apps, 2 x HDD's for 11GB storage | PSU: Seasonic X-1250 M2| Case: Corsair C70 | Cooling: Corsair H115i Hydro cooler | Displays: Asus PG278QR, BenQ XL2420TX & BenQ HT1075 | OS: Windows 10 Pro + Windows 7 dual boot
[quote="DJ-RK"]Wow, that's a lot of information![/quote]For the most part I've tried to make the resource copying fairly simple to use for the common cases and 3DMigoto will try to do sensible things, but at the same time I did not want it to end up as an 'almost' useful feature that was limited by my imagination, so it has the flexibility to allow you to outsmart it if needed. Since you are just copying a constant buffer at the moment, that should fit into one of the easier use cases as there is not much that can go wrong in that scenario.
[quote][quote="DarkStarSword"]Do you mean the shader gets broken by just doing the copy without otherwise modifying it?[/quote]
No, just doing the copy function alone doesn't cause any errors. If I just comment out the one line in the PS above: r2=mul(ivp,tmp); then the shader remains functional as nothing gets modified. With that code in place, the fog of war covers the entire screen, which I believe is the same result as having the shader output set to 0.[/quote]
In that case it is worth using frame analysis with analyse_options=dump_cb_txt and check that the constant buffer was definitely copied and that the matrix in the dump looks sane. Also be sure that the shader you copied it from was drawing something in the world from the POV of the camera (and not a HUD element or shadow caster).
[quote]Yeah, unfortunately the VS for this PS does not use the VPM, so I'm copying from a completely unrelated VS.[/quote]In that case forget my suggestion of changing it to a copy by reference (you can and should still use max_copies_per_frame=1), as something copied by reference can be changed by the game after the call it was copied from, so performing a full copy is the safest way to make sure you get the same values as the call you copied it from. This is one of the main reasons that 3DMigoto defaults to a full copy when using an intermediate resource.
[quote][quote][quote]-What exactly are the requirements for the declaration in the shader where you are using the copied resource?[/quote]The only requirement is they start with 'Resource' to disambiguate them from other sections in the ini file, and that their name be unique (and 3DMigoto warns if the name is not unique). It does not need to be related to the name used in the shader (I will usually name them consistently with the game if it makes sense, but that's just for my own benefit).[/quote]
I was actually referring to the declaration in the PS where I'm copying the shader to, not the declaration in the d3dx.ini file. You kinda mention this later on in your response, but I'm still not 100% clear on this, whether there's a specific naming convention I need to use here, or if I'm free to use anything I choose.[/quote]You can choose anything you like in the HLSL as well. The only important part is that the register matches the slot you copied it into, and that the packoffset matches.
[quote][quote]- Try to avoid binding a resource as both an input and output simultaneously (it's good practice to unbind a resource after the draw call with the something like 'post vs-cb13 = null' in case the game tries to bind it elsewhere later).[/quote]
Sorry, but could you elaborate a little bit more about binding resources? What does this entail, and how do you bind, or avoid binding a resource? If it's not too much to ask, could you also elaborate a bit more on copying vs copying by reference?[/quote]
A copy operation follows this basic syntax ( [] = optional, ... = more than one):
[code]
[ post ] destination = [ keywords ... ] source
[/code]
- If post is specified, the operation will be performed after the draw call instead of before. This is useful to copy the result of a render target after the shader has run (perhaps in combination with copying it before running the shader so that a comparison can be made), and to restore the original state before continuing (usually by unbinding resources that were bound before the draw call).
- destination specifies where in the rendering pipeline the resource should be bound, or is a custom resource to hold the resource or a copy of it.
- keywords is used to override 3DMigoto's defaults for complex situations, or when you 'know better' than 3DMigoto.
- source specifies where in the pipeline the resource should be obtained from, or is a custom resource holding a reference/copy of a resource (or one loaded from disk or created from scratch).
- If source is 'null' or nothing is bound in the slot it refers to, any resource in the destination slot will be unbound, or if the destination is a custom resource it will be marked as invalid (and if used as the source will have the same effect as passing null).
- Source can also be 'bb', referring to the swap chain back buffer. The back buffer cannot be used as a destination - to write to the back buffer you bind it to a render target by reference.
If destination is one of the following:
[vhdgpc]s-cb[0-13] (constant buffer slot)
[vhdgpc]s-t[0-127] (texture / other shader resource slot)
vb[0-31] (vertex buffer slot)
ib (index buffer slot)
The resource will be bound as in input. If it is one of these:
o[0-7] (render target slot)
oD (depth/stencil slot)
so[0-3] (stream output slot)
It will be bound as an output. If it is one of these:
ps-u[0-7] (pixel shader UAV slot)
cs-u[0-7] (compute shader UAV slot)
It is simultaneously an input and output.
With the exception of UAVs, resources cannot be bound to both an input and output slot simultaneously, and attempting to do so will either fail to bind it, or will forcefully unbind it from wherever else it is bound in the pipeline. Performing a full copy is the easiest way to avoid this scenario.
If a resource is copied by reference (either as a default of 3DMigoto, or by specifying the 'reference' keyword, the source will be bound to the destination directly. This is a lightweight operation so performance reasons it can be a good idea to use this when it makes sense, and it is necessary for some use cases (such as binding a custom render target / UAV). But, as it is the SAME resource then the above rules apply that it cannot be bound as both an input and output simultaneously. Leaving such a resource bound anywhere can be risky as the game does not know that it is bound, and may try to bind it elsewhere in the pipeline and violate that rule. Copying by reference may or may not work between different slot types, depending on the bind flags that the game used when creating the resource (and a few other restrictions). 3DMigoto may still create a new resource view, so in some rare cases there might be differences observed from the POV of the shader.
If a full copy is performed (either as a default of 3DMigoto, or by specifying the 'copy' keyword), the resource destination will receive a COPY of the source resource, and will BE A DIFFERENT RESOURCE to the source. This avoids the risk of I/O conflicts since it is not the same, and means that the copy is a snapshot of the original resource at the time it was copied (whereas copying by reference may still allow the game to change it later, though sometimes you may want that). A full copy is also required for 3DMigoto to change certain details about the resource, such as changing it's bind flags to allow it to be bound to a different slot type than the game intended.
The default rules are (first rule matched will be used):
1. If the destination is a custom resource: use a full copy (ensures that bind flags are changed as necessary, and prevent surprises if the game later overwrites the source resource)
2. If the destination is a render target: copy by reference (assumes we want the result of the draw operation in the resource we assigned)
3. If the source is a custom resource: copy by reference (assumes that the custom resource will have already been created through a full copy to set the required bind flags)
4. If the source and destination are the same slot type: copy by reference (likely to be safe, and lightweight)
5. In any other case: perform a full copy (may need to change bind flags or avoid I/O conflicts)
Keywords include:
- copy - perform a full copy of the resource
- ref / reference - copy the resource by reference
- copy_desc / copy_description - make the destination resource have the same description as the source (width, height, format, etc. except for any overridden in the resource section), but do not actually copy the source resource. Used to create simultaneous render targets.
- unless_null - abort the copy operation if nothing is bound to the source. Does not increment the resource copy count for the frame.
- stereo - when creating the destination resource for a full copy, set the driver creation mode create it as a stereo resource.
- mono - As above, but set the creation mode to a mono resource.
- stereo2mono - perform a full copy using the reverse stereo blit that ends up with a double width mono resource with the image for the right eye on the left and vice versa. Current limitations: does not work with MSAA resources, and only the most detailed mip-map will have the information for the second eye.
- set_viewport - Set the DirectX viewport to match the dimensions of the source resource to ensure that the entire resource can be written to. Useful when assigning the back buffer as a render target (note - the original viewport cannot be restored through resource copying, but if this is run from a CustomShader section that will take care of backing up and restoring it).
- no_view_cache - Never cache the resource view. Workaround for glitches in Mad Max when running a custom shader from the present call very early in launch.
- resolve_msaa - Ask the hardware to resolve an MSAA resource into a non MSAA resource. This will not work for all resources, and it is not clear how universal the support is, so I do not recommend relying on it for now (e.g. my card cannot resolve MSAA depth buffers). A safer solution would be to use a custom shader to perform this operation instead, and eventually I would like to build that into 3DMigoto so that this works more universally.
For the most part I've tried to make the resource copying fairly simple to use for the common cases and 3DMigoto will try to do sensible things, but at the same time I did not want it to end up as an 'almost' useful feature that was limited by my imagination, so it has the flexibility to allow you to outsmart it if needed. Since you are just copying a constant buffer at the moment, that should fit into one of the easier use cases as there is not much that can go wrong in that scenario.
DarkStarSword said:Do you mean the shader gets broken by just doing the copy without otherwise modifying it?
No, just doing the copy function alone doesn't cause any errors. If I just comment out the one line in the PS above: r2=mul(ivp,tmp); then the shader remains functional as nothing gets modified. With that code in place, the fog of war covers the entire screen, which I believe is the same result as having the shader output set to 0.
In that case it is worth using frame analysis with analyse_options=dump_cb_txt and check that the constant buffer was definitely copied and that the matrix in the dump looks sane. Also be sure that the shader you copied it from was drawing something in the world from the POV of the camera (and not a HUD element or shadow caster).
Yeah, unfortunately the VS for this PS does not use the VPM, so I'm copying from a completely unrelated VS.
In that case forget my suggestion of changing it to a copy by reference (you can and should still use max_copies_per_frame=1), as something copied by reference can be changed by the game after the call it was copied from, so performing a full copy is the safest way to make sure you get the same values as the call you copied it from. This is one of the main reasons that 3DMigoto defaults to a full copy when using an intermediate resource.
-What exactly are the requirements for the declaration in the shader where you are using the copied resource?
The only requirement is they start with 'Resource' to disambiguate them from other sections in the ini file, and that their name be unique (and 3DMigoto warns if the name is not unique). It does not need to be related to the name used in the shader (I will usually name them consistently with the game if it makes sense, but that's just for my own benefit).
I was actually referring to the declaration in the PS where I'm copying the shader to, not the declaration in the d3dx.ini file. You kinda mention this later on in your response, but I'm still not 100% clear on this, whether there's a specific naming convention I need to use here, or if I'm free to use anything I choose.
You can choose anything you like in the HLSL as well. The only important part is that the register matches the slot you copied it into, and that the packoffset matches.
- Try to avoid binding a resource as both an input and output simultaneously (it's good practice to unbind a resource after the draw call with the something like 'post vs-cb13 = null' in case the game tries to bind it elsewhere later).
Sorry, but could you elaborate a little bit more about binding resources? What does this entail, and how do you bind, or avoid binding a resource? If it's not too much to ask, could you also elaborate a bit more on copying vs copying by reference?
A copy operation follows this basic syntax ( [] = optional, ... = more than one):
[ post ] destination = [ keywords ... ] source
- If post is specified, the operation will be performed after the draw call instead of before. This is useful to copy the result of a render target after the shader has run (perhaps in combination with copying it before running the shader so that a comparison can be made), and to restore the original state before continuing (usually by unbinding resources that were bound before the draw call).
- destination specifies where in the rendering pipeline the resource should be bound, or is a custom resource to hold the resource or a copy of it.
- keywords is used to override 3DMigoto's defaults for complex situations, or when you 'know better' than 3DMigoto.
- source specifies where in the pipeline the resource should be obtained from, or is a custom resource holding a reference/copy of a resource (or one loaded from disk or created from scratch).
- If source is 'null' or nothing is bound in the slot it refers to, any resource in the destination slot will be unbound, or if the destination is a custom resource it will be marked as invalid (and if used as the source will have the same effect as passing null).
- Source can also be 'bb', referring to the swap chain back buffer. The back buffer cannot be used as a destination - to write to the back buffer you bind it to a render target by reference.
With the exception of UAVs, resources cannot be bound to both an input and output slot simultaneously, and attempting to do so will either fail to bind it, or will forcefully unbind it from wherever else it is bound in the pipeline. Performing a full copy is the easiest way to avoid this scenario.
If a resource is copied by reference (either as a default of 3DMigoto, or by specifying the 'reference' keyword, the source will be bound to the destination directly. This is a lightweight operation so performance reasons it can be a good idea to use this when it makes sense, and it is necessary for some use cases (such as binding a custom render target / UAV). But, as it is the SAME resource then the above rules apply that it cannot be bound as both an input and output simultaneously. Leaving such a resource bound anywhere can be risky as the game does not know that it is bound, and may try to bind it elsewhere in the pipeline and violate that rule. Copying by reference may or may not work between different slot types, depending on the bind flags that the game used when creating the resource (and a few other restrictions). 3DMigoto may still create a new resource view, so in some rare cases there might be differences observed from the POV of the shader.
If a full copy is performed (either as a default of 3DMigoto, or by specifying the 'copy' keyword), the resource destination will receive a COPY of the source resource, and will BE A DIFFERENT RESOURCE to the source. This avoids the risk of I/O conflicts since it is not the same, and means that the copy is a snapshot of the original resource at the time it was copied (whereas copying by reference may still allow the game to change it later, though sometimes you may want that). A full copy is also required for 3DMigoto to change certain details about the resource, such as changing it's bind flags to allow it to be bound to a different slot type than the game intended.
The default rules are (first rule matched will be used):
1. If the destination is a custom resource: use a full copy (ensures that bind flags are changed as necessary, and prevent surprises if the game later overwrites the source resource)
2. If the destination is a render target: copy by reference (assumes we want the result of the draw operation in the resource we assigned)
3. If the source is a custom resource: copy by reference (assumes that the custom resource will have already been created through a full copy to set the required bind flags)
4. If the source and destination are the same slot type: copy by reference (likely to be safe, and lightweight)
5. In any other case: perform a full copy (may need to change bind flags or avoid I/O conflicts)
Keywords include:
- copy - perform a full copy of the resource
- ref / reference - copy the resource by reference
- copy_desc / copy_description - make the destination resource have the same description as the source (width, height, format, etc. except for any overridden in the resource section), but do not actually copy the source resource. Used to create simultaneous render targets.
- unless_null - abort the copy operation if nothing is bound to the source. Does not increment the resource copy count for the frame.
- stereo - when creating the destination resource for a full copy, set the driver creation mode create it as a stereo resource.
- mono - As above, but set the creation mode to a mono resource.
- stereo2mono - perform a full copy using the reverse stereo blit that ends up with a double width mono resource with the image for the right eye on the left and vice versa. Current limitations: does not work with MSAA resources, and only the most detailed mip-map will have the information for the second eye.
- set_viewport - Set the DirectX viewport to match the dimensions of the source resource to ensure that the entire resource can be written to. Useful when assigning the back buffer as a render target (note - the original viewport cannot be restored through resource copying, but if this is run from a CustomShader section that will take care of backing up and restoring it).
- no_view_cache - Never cache the resource view. Workaround for glitches in Mad Max when running a custom shader from the present call very early in launch.
- resolve_msaa - Ask the hardware to resolve an MSAA resource into a non MSAA resource. This will not work for all resources, and it is not clear how universal the support is, so I do not recommend relying on it for now (e.g. my card cannot resolve MSAA depth buffers). A safer solution would be to use a custom shader to perform this operation instead, and eventually I would like to build that into 3DMigoto so that this works more universally.
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
Hehe;) Yeah;) That's why everything I produce with Photoshop I open in Ms Paint after to see if it still works right...lol:)))
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)
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
My original display name is 3d4dd - for some reason Nvidia changed it..?!
https://forums.geforce.com/default/topic/685657/3d-vision/3dmigoto-now-open-source-/post/4810934/#4810934
https://forums.geforce.com/default/topic/908302/3d-vision/how-to-play-vr-images-and-videos-in-3dvision-using-the-whirligig-vr-player/post/4810984/#4810984
Had some issues trying to get it working with ARK, but they were more related to getting ARK working in side by side mode with 3D vision enabled at all.
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
The shader I'm working on is for the fog of war effect in Xcom 2, which renders in 2D. I'm trying to fix it in the PS, which receives a texcoord in world space, so I'm trying to a) copy a constant buffer from a VS that contains a VPM, and b) use DSS's matrix.hlsl to calculate the inverse (although I could potentially also copy another buffer from the same VS, but thought this would be cleaner) in order to attempt to do the fix, however when I follow the examples for this functionality it breaks the shader. So, if someone could take a look and see if I'm using this wrong, and provide any corrections it would be appreciated.
In my d3dx.ini file I have the following:
And here's the FoW PS
And in case it's needed, here is the declaration of the constant buffer from the VS it was copied from
Some questions I have regarding this functionality are:
-What exactly are the requirements for the declaration in the shader where you are using the copied resource? ie. Does it matter what name comes after 'cbuffer'? Here I have 'VPM', but in the original VS that buffer is called 'VSOffsetConstants' (which I've tried, and also tried PSOffsetConstants). In the Mad Max example, I believe there was some modifying of the naming, but it's not clear at all what is allowed/required.
-If there are any naming requirements, for example if it's necessary to use PSOffsetConstants, what happens if a shader already has a buffer using the same name in another buffer slot? Does that conflict at all?
-Are there any restrictions regarding using a constant buffer copied from a VS and using it in another type of shader (PS/CS/etc)?
-Are you allowed to copy more than one resource into a shader? I would assume so, but nothing specifically says so either way.
And here's an unrelated question: in some shaders, there is a matrix called ScreenToWorldMatrix, and others there are InvViewProjectionMatrix. Would they potentially be the same, or are they likely different?
3D Gaming Rig: CPU: i7 7700K @ 4.9Ghz | Mobo: Asus Maximus Hero VIII | RAM: Corsair Dominator 16GB | GPU: 2 x GTX 1080 Ti SLI | 3xSSDs for OS and Apps, 2 x HDD's for 11GB storage | PSU: Seasonic X-1250 M2| Case: Corsair C70 | Cooling: Corsair H115i Hydro cooler | Displays: Asus PG278QR, BenQ XL2420TX & BenQ HT1075 | OS: Windows 10 Pro + Windows 7 dual boot
Like my fixes? Dontations can be made to: www.paypal.me/DShanz or rshannonca@gmail.com
Like electronic music? Check out: www.soundcloud.com/dj-ryan-king
Do you mean the shader gets broken by just doing the copy without otherwise modifying it?
This looks fine to me. It will do a fully copy since you are using an intermediate resource and haven't specified otherwise, but that should be ok (you can either specify the 'ref' keyword in the copy *to* the custom resource, or you might add 'max_copies_per_frame=1' to the resource section to make sure that it doesn't perform excessive amounts of full copies). If the vertex + pixel shader are used in the same draw call you could alternatively just match on either one and do:
But your above code should work. Notably if you do match two separate shaders for the same draw call it is important to keep in mind that 3DMigoto processes their command lists in the same order as the rendering pipeline (Vertex -> Hull -> Domain -> Geometry -> Pixel), so if you were trying to copy something from the pixel shader to the vertex shader it would be best done with a single section (like I did in Mad Max to fix the lens flares), but copying forwards in the pipeline should work either way. Also note that when copying forwards in the pipeline if working in HLSL it is possible to add additional texcoord outputs & inputs and use them to pass values through.
The only requirement is they start with 'Resource' to disambiguate them from other sections in the ini file, and that their name be unique (and 3DMigoto warns if the name is not unique). It does not need to be related to the name used in the shader (I will usually name them consistently with the game if it makes sense, but that's just for my own benefit).
As above, the name in the ini file does not matter, but if you were to copy the definition in the HLSL file and that had a naming conflict you would need to rename it (hopefully it would fail to compile if there was a conflict, but I can't say I have tested this).
There are no restrictions for constant buffers. There are other cases where a copy may fail, but these are largely down to restrictions in DirectX (and in the case of using a stereo2mono copy, the driver), and those are really poorly documented and for the most part I've found them out the hard way, and am still finding new ones. Some of these I'm able to hide in 3DMigoto (e.g. copying a depth buffer to a texture slot works because 3DMigoto handles the format conversion, likewise copying a vertex buffer to a texture slot works because 3DMigoto converts it into a structured buffer and to a constant buffer slot works because 3DMigoto cuts it down to size if it was too large), but others I am not able to hide completely, or may be able to but don't do so yet (see below).
Yes, it was important for me that I did not place any arbitrary restrictions on this that might get in someone's way later on. You can have as many resources and copy operations as you like :)
If you are having issues copying a resource, there are a few things worth trying:
- Check the d3d11_log.txt to make sure that the copy directives show up in the ini parsing and that there are no warnings or errors.
- Check the d3d11_log.txt for any errors about creating resources or views. If this is happening it will likely be repeated... a lot. Please report any of these you find - I am trying to understand all the combinations that don't work so I can try to solve them, but these combinations are not documented anywhere and the only way I find out is from these messages (or the DX debug layer).
- Try explicitly doing a full copy with the 'copy' keyword
- Try explicitly doing a copy by reference with the 'reference' keyword
- If using an intermediate resource, try different combinations of the above on the copy to the intermediate resource, and the copy from the intermediate resource.
- If you leave the resource bound to the pipeline after the draw call frame analysis can be used to dump it out (if you unbind it with 'post ps-cb13 = null' it will not be seen in frame analysis)
Off the top of my head, here are some of the nitty gritty details - as I said above, most of these restrictions come from DX, not from us:
- Try to avoid binding a resource as both an input and output simultaneously (it's good practice to unbind a resource after the draw call with the something like 'post vs-cb13 = null' in case the game tries to bind it elsewhere later).
- Copying by reference may not work if copying between different slot types, unless the game created the resource with the required bind flags.
- Constant buffers can be copied by reference to other constant buffer slots, and as they can never be bound as an output there is no need to worry about IO conflicts. To copy these to any other slot type, a full copy must be used. Likewise, copying anything else to a constant buffer slot must use a full copy, and 3DMigoto will limit it to the maximum supported size of a constant buffer, which is 64K.
- Avoid vs-cb12, which is used by the 3D Vision driver
- If a constant buffer slot is not working, try a different constant buffer slot (I fully expect that there is a profile setting to change the slot that the driver uses, so suspect any that aren't working).
- If you are trying to opportunistically copy a resource that you aren't certain will be bound, use the 'unless_null' keyword.
- To avoid using stale data from a previous frame, use the Present call to NULL out the intermediate resource (this is fast - it does not throw it away, only marks it as invalid until it is next set). If you do this you will need to be certain that you set the resource from something in the frame prior to using it.
- If you are doing any full copies (keeping in mind that if you don't specify to do a full copy 3DMigoto will decide for itself whether it should or not, and errs on the side of using a full copy in situations where there isn't a clear answer), use 'max_copies_per_frame=1' in the resource section to limit the number of times the copy operation might be performed to avoid adverse performance impacts. If you really need the result after the last draw call instead of the first, try to use a copy by reference if possible.
- Copying from one intermediate resource to another should work in theory, but there seem to be a number of edge cases that 3DMigoto is not yet handling (mostly related to certain options/formats requiring bind flags to be set which will not be in this case), so in many situations this may fail.
- The copy operations are logged in the frame analysis log.txt, so you can check if they are being executed by checking that.
- Be SURE to define the resource in the target shader. HLSL shaders will fail to compile if you don't, but it turns out that assembly shaders will assemble and kind of work, except for when they don't (e.g. the sample_l_indexable instruction may or may not ignore the mip-map level and behave like a regular sample instruction if the texture was not defined... found this out the hard way).
- If you are copying a stereo (or mono) resource and it is not working correctly, try explicitly adding the 'stereo' or 'mono' keywords. Note that in some cases the copy still seems to occur in mono regardless for a reason I don't fully understand (driver heuristics) and in that case you may need to copy by reference (or use a custom shader to copy it instead).
- MSAA resources have additional restrictions, and should be resolved using a custom shader first (there is a 'resolve_msaa' keyword to do this in 3DMigoto, but it currently lacks any fallback if the hardware does not support the format being resolved, and there is no documentation anywhere for what formats are supported on what hardware). These do not work with stereo2mono, and there might be issues with copying them to certain other slots as well. They can be injected into a vertex shader, but 'model=vs_5_0' may be required in the ShaderOverride section to allow Texture2DMS.
- I discovered the other day that stereo2mono does not work correctly for mip-maps - 3DMigoto attempts the copy for all mip-maps and subresources, but the driver only performs the reverse stereo blit on the most detailed mip-map level (I may be able to work around this with even more intermediate copies, but stereo2mono is already performing two copies per mip-map level as it is, plus will need an additional copy for MSAA resources when that's added).
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
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
https://github.com/bo3b/3Dmigoto/releases
This release is to fix bugs with ASM shader handling. This version should properly handle ASM text files, properly generate the corresponding .bin files with cache_shaders=1, and properly reload the .bin first and not reassemble.
In particular this removes all references to the *_reasm.txt files. Those were for assembler validation and are no longer necessary.
There should only be four files now, with a sensible naming convention, e.g.:
e706a624b9fe754a-ps_replace.txt - HLSL decompiled shader
e706a624b9fe754a-ps_replace.bin - binary cached version of HLSL shader
e706a624b9fe754a-ps.txt - ASM text file shader
e706a624b9fe754a-ps.bin - binary cached version of ASM shader.
If you have any fixes with _reasm.txt files, you should delete all of those, or reinstall so that caching regenerates the .bin files. They will cause problems, as I removed the workarounds for those files when hunting.
Let me know if you see any new bugs, I refactored some big chunks of code, and it's always possible to have missed something. Tested only in Witcher 3.
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
One question though;) Will the shaders be recompiled when the game encounters them? or will it compile all the txt files that are in the Shaders Folder?:)
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)
In principle we could make it generate the .bin for every file at launch, but it hasn't proven to be a problem in the past to do load on demand.
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
If you go that route, please still include the .txt files as reference for other ShaderHackers. I really, really don't want to get into a mode where we only ship binaries.
As a side note, I used 7zip on maximum compression, and the archive was 13.5M with just text files. As a general idea, I think that .zip is what we should ship, because it's more universal, no one will have trouble with a .zip file, whereas a few people will get snagged by .7z or .rar files. Just thought it was weird that text files didn't compress better for .rar.
If you include the presumably not compressible .bin files, that will make the archive 80% bigger, but that's still OK in today's world. Tradeoff of having a slow download versus a slow first launch.
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
Yeah! Big thanks bo3b! I was thinking of making the following:
- Use cmd_compiler to get the .bin for all the asm shaders. + add the HLSL shaders as text files (which are around 10 I believe in the whole fix)
- All the txt and source code I will zip-up and put it next to the shaders. (so we still have the reference and the actual ASM shader code) and place it inside the fix (in a folder called ASMSourceCode or similar)
This will make the archive smaller as well, we still have the source code (inside the zip) and the .bins that are actually used.
What do you think?:)
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)
Well Using 3DMigoto 1.2.34 and I think I found a bug related to HLSL shaders...
So, I have my shader in question in ROTTR with filename "33586be9d6e9bae3-vs_replace.txt" (This is the BLOOD on screen and it doesn't appear until you are injured).
The wrapper doesn't seem to pick it up or SWAP IT!!!
BUT! If I manually find it (hunting=2) and dump it again it seems to load the .bin file associated with it and then it starts working.
Also, when I am going through the shaders I can't see the description I have in the TXT file at the top. This clearly shows that the HLSL shader is not swapped or the .bin is not used but instead the original shader is used.
This didn't happen in 1.2.32 but then again 1.2.34 has major changes in this part... I think this is a bug:)
Other HLSL shaders seem to work just fine;) (I wonder IF, the wrapper changes the shader, BUT then the engine OVERWRITES it with it's own version...HMMM)
NVM! I actually found what the problem was... I was having both a HLSL and ASM variant and the ASM variant took precedence over the HLSL one. I was thinking if you can add a beep or some type of sound when this happens? (both an ASM and HLSL shader exist with the same CRC to tell there is a duplicate and we must chose one of them (like the silly me ^_^)). Is this possible?
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)
I read it over last night before going to bed, and my brain was a little too fried to process most of it. I'll read it over a few times when I get the time and try a few of the suggestions, and hopefully something will stick. For now I'll just make a few responses to your post where I can.
No, just doing the copy function alone doesn't cause any errors. If I just comment out the one line in the PS above: r2=mul(ivp,tmp); then the shader remains functional as nothing gets modified. With that code in place, the fog of war covers the entire screen, which I believe is the same result as having the shader output set to 0.
Yeah, unfortunately the VS for this PS does not use the VPM, so I'm copying from a completely unrelated VS.
I was actually referring to the declaration in the PS where I'm copying the shader to, not the declaration in the d3dx.ini file. You kinda mention this later on in your response, but I'm still not 100% clear on this, whether there's a specific naming convention I need to use here, or if I'm free to use anything I choose.
Sorry, but could you elaborate a little bit more about binding resources? What does this entail, and how do you bind, or avoid binding a resource? If it's not too much to ask, could you also elaborate a bit more on copying vs copying by reference?
(sorry if it's a bit elementary for me to be asking you to spell some of this out)
3D Gaming Rig: CPU: i7 7700K @ 4.9Ghz | Mobo: Asus Maximus Hero VIII | RAM: Corsair Dominator 16GB | GPU: 2 x GTX 1080 Ti SLI | 3xSSDs for OS and Apps, 2 x HDD's for 11GB storage | PSU: Seasonic X-1250 M2| Case: Corsair C70 | Cooling: Corsair H115i Hydro cooler | Displays: Asus PG278QR, BenQ XL2420TX & BenQ HT1075 | OS: Windows 10 Pro + Windows 7 dual boot
Like my fixes? Dontations can be made to: www.paypal.me/DShanz or rshannonca@gmail.com
Like electronic music? Check out: www.soundcloud.com/dj-ryan-king
In that case it is worth using frame analysis with analyse_options=dump_cb_txt and check that the constant buffer was definitely copied and that the matrix in the dump looks sane. Also be sure that the shader you copied it from was drawing something in the world from the POV of the camera (and not a HUD element or shadow caster).
In that case forget my suggestion of changing it to a copy by reference (you can and should still use max_copies_per_frame=1), as something copied by reference can be changed by the game after the call it was copied from, so performing a full copy is the safest way to make sure you get the same values as the call you copied it from. This is one of the main reasons that 3DMigoto defaults to a full copy when using an intermediate resource.
You can choose anything you like in the HLSL as well. The only important part is that the register matches the slot you copied it into, and that the packoffset matches.
A copy operation follows this basic syntax ( [] = optional, ... = more than one):
- If post is specified, the operation will be performed after the draw call instead of before. This is useful to copy the result of a render target after the shader has run (perhaps in combination with copying it before running the shader so that a comparison can be made), and to restore the original state before continuing (usually by unbinding resources that were bound before the draw call).
- destination specifies where in the rendering pipeline the resource should be bound, or is a custom resource to hold the resource or a copy of it.
- keywords is used to override 3DMigoto's defaults for complex situations, or when you 'know better' than 3DMigoto.
- source specifies where in the pipeline the resource should be obtained from, or is a custom resource holding a reference/copy of a resource (or one loaded from disk or created from scratch).
- If source is 'null' or nothing is bound in the slot it refers to, any resource in the destination slot will be unbound, or if the destination is a custom resource it will be marked as invalid (and if used as the source will have the same effect as passing null).
- Source can also be 'bb', referring to the swap chain back buffer. The back buffer cannot be used as a destination - to write to the back buffer you bind it to a render target by reference.
If destination is one of the following:
[vhdgpc]s-cb[0-13] (constant buffer slot)
[vhdgpc]s-t[0-127] (texture / other shader resource slot)
vb[0-31] (vertex buffer slot)
ib (index buffer slot)
The resource will be bound as in input. If it is one of these:
o[0-7] (render target slot)
oD (depth/stencil slot)
so[0-3] (stream output slot)
It will be bound as an output. If it is one of these:
ps-u[0-7] (pixel shader UAV slot)
cs-u[0-7] (compute shader UAV slot)
It is simultaneously an input and output.
With the exception of UAVs, resources cannot be bound to both an input and output slot simultaneously, and attempting to do so will either fail to bind it, or will forcefully unbind it from wherever else it is bound in the pipeline. Performing a full copy is the easiest way to avoid this scenario.
If a resource is copied by reference (either as a default of 3DMigoto, or by specifying the 'reference' keyword, the source will be bound to the destination directly. This is a lightweight operation so performance reasons it can be a good idea to use this when it makes sense, and it is necessary for some use cases (such as binding a custom render target / UAV). But, as it is the SAME resource then the above rules apply that it cannot be bound as both an input and output simultaneously. Leaving such a resource bound anywhere can be risky as the game does not know that it is bound, and may try to bind it elsewhere in the pipeline and violate that rule. Copying by reference may or may not work between different slot types, depending on the bind flags that the game used when creating the resource (and a few other restrictions). 3DMigoto may still create a new resource view, so in some rare cases there might be differences observed from the POV of the shader.
If a full copy is performed (either as a default of 3DMigoto, or by specifying the 'copy' keyword), the resource destination will receive a COPY of the source resource, and will BE A DIFFERENT RESOURCE to the source. This avoids the risk of I/O conflicts since it is not the same, and means that the copy is a snapshot of the original resource at the time it was copied (whereas copying by reference may still allow the game to change it later, though sometimes you may want that). A full copy is also required for 3DMigoto to change certain details about the resource, such as changing it's bind flags to allow it to be bound to a different slot type than the game intended.
The default rules are (first rule matched will be used):
1. If the destination is a custom resource: use a full copy (ensures that bind flags are changed as necessary, and prevent surprises if the game later overwrites the source resource)
2. If the destination is a render target: copy by reference (assumes we want the result of the draw operation in the resource we assigned)
3. If the source is a custom resource: copy by reference (assumes that the custom resource will have already been created through a full copy to set the required bind flags)
4. If the source and destination are the same slot type: copy by reference (likely to be safe, and lightweight)
5. In any other case: perform a full copy (may need to change bind flags or avoid I/O conflicts)
Keywords include:
- copy - perform a full copy of the resource
- ref / reference - copy the resource by reference
- copy_desc / copy_description - make the destination resource have the same description as the source (width, height, format, etc. except for any overridden in the resource section), but do not actually copy the source resource. Used to create simultaneous render targets.
- unless_null - abort the copy operation if nothing is bound to the source. Does not increment the resource copy count for the frame.
- stereo - when creating the destination resource for a full copy, set the driver creation mode create it as a stereo resource.
- mono - As above, but set the creation mode to a mono resource.
- stereo2mono - perform a full copy using the reverse stereo blit that ends up with a double width mono resource with the image for the right eye on the left and vice versa. Current limitations: does not work with MSAA resources, and only the most detailed mip-map will have the information for the second eye.
- set_viewport - Set the DirectX viewport to match the dimensions of the source resource to ensure that the entire resource can be written to. Useful when assigning the back buffer as a render target (note - the original viewport cannot be restored through resource copying, but if this is run from a CustomShader section that will take care of backing up and restoring it).
- no_view_cache - Never cache the resource view. Workaround for glitches in Mad Max when running a custom shader from the present call very early in launch.
- resolve_msaa - Ask the hardware to resolve an MSAA resource into a non MSAA resource. This will not work for all resources, and it is not clear how universal the support is, so I do not recommend relying on it for now (e.g. my card cannot resolve MSAA depth buffers). A safer solution would be to use a custom shader to perform this operation instead, and eventually I would like to build that into 3DMigoto so that this works more universally.
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