3Dmigoto now open-source...
  42 / 141    
[quote="Oomek"]Wouldn't it be to much trouble to add a currently disabled shader's hash to the OSD?[/quote] It's not a giant change to make this work, but we haven't added it because we are trying to solve the problem by better work flow. The giant hex numbers are mostly just visual noise. The main reason to use it on HelixMod was because there was no automatic copying. In 3Dmigoto we are trying to get around ever needing those numbers by being smart about how we manage the fies. We do CopyOnMark for example, so the shader you have selected is automatically Decompiled and moved to ShaderFixes and made live. No need for big number there. If you hit Mark on a file that already exists, we 'touch' the file so the mod date is different. If you keep your folder sorted by date, then the most recent thing you've looked at it is on top. No need for big number. You might want an image with that big number stamped on it, showing the effect. We have this as a saved off JPS file in the folder whenever you Mark, with the same file name as the shader. (I hope to add an _on/_off for two JPS files.) Not saying no, but please give me an idea of your workflow, and why this seems necessary. [quote="masterotaku"]By the way, another idea that may not exist in 3Dmigoto: OSD messages. I'd like to show messages like "Bloom off", "Blurry as DoF FXAA" and similar things. If it exists, great. If not, I don't mind.[/quote] No feature like that at present. We could, for example, pull the first comment line of text out of the shader file as a description. Might be related to Oomek's idea there. Maybe you are thinking of some sort of on-screen stamp for screenshots as to effects. Please tell me more about what you are thinking. Maybe a work flow where this would help.
Oomek said:Wouldn't it be to much trouble to add a currently disabled shader's hash to the OSD?

It's not a giant change to make this work, but we haven't added it because we are trying to solve the problem by better work flow. The giant hex numbers are mostly just visual noise. The main reason to use it on HelixMod was because there was no automatic copying.

In 3Dmigoto we are trying to get around ever needing those numbers by being smart about how we manage the fies. We do CopyOnMark for example, so the shader you have selected is automatically Decompiled and moved to ShaderFixes and made live. No need for big number there.

If you hit Mark on a file that already exists, we 'touch' the file so the mod date is different. If you keep your folder sorted by date, then the most recent thing you've looked at it is on top. No need for big number.

You might want an image with that big number stamped on it, showing the effect. We have this as a saved off JPS file in the folder whenever you Mark, with the same file name as the shader. (I hope to add an _on/_off for two JPS files.)


Not saying no, but please give me an idea of your workflow, and why this seems necessary.


masterotaku said:By the way, another idea that may not exist in 3Dmigoto: OSD messages. I'd like to show messages like "Bloom off", "Blurry as DoF FXAA" and similar things. If it exists, great. If not, I don't mind.

No feature like that at present. We could, for example, pull the first comment line of text out of the shader file as a description. Might be related to Oomek's idea there.

Maybe you are thinking of some sort of on-screen stamp for screenshots as to effects.

Please tell me more about what you are thinking. Maybe a work flow where this would help.

Acer H5360 (1280x720@120Hz) - ASUS VG248QE with GSync mod - 3D Vision 1&2 - Driver 372.54
GTX 970 - i5-4670K@4.2GHz - 12GB RAM - Win7x64+evilKB2670838 - 4 Disk X25 RAID
SAGER NP9870-S - GTX 980 - i7-6700K - Win10 Pro 1607
Latest 3Dmigoto Release
Bo3b's School for ShaderHackers

Posted 12/12/2015 01:24 AM   
[quote="bo3b"][quote="Oomek"]Wouldn't it be to much trouble to add a currently disabled shader's hash to the OSD?[/quote] It's not a giant change to make this work, but we haven't added it because we are trying to solve the problem by better work flow. The giant hex numbers are mostly just visual noise. The main reason to use it on HelixMod was because there was no automatic copying. In 3Dmigoto we are trying to get around ever needing those numbers by being smart about how we manage the fies. We do CopyOnMark for example, so the shader you have selected is automatically Decompiled and moved to ShaderFixes and made live. No need for big number there. If you hit Mark on a file that already exists, we 'touch' the file so the mod date is different. If you keep your folder sorted by date, then the most recent thing you've looked at it is on top. No need for big number. You might want an image with that big number stamped on it, showing the effect. We have this as a saved off JPS file in the folder whenever you Mark, with the same file name as the shader. (I hope to add an _on/_off for two JPS files.) Not saying no, but please give me an idea of your workflow, and why this seems necessary. [/quote] I'm actually trying to avoid timestamping my previously modified shaders. I'm sorting by date and when for example I'm editing all the water shaders simultaneously (there is 12 of them in Dirt 3) and I accidentally redump an old one it breaks the workflow a bit. Maybe adding a little mark on the osd saying "dumped" or "fixed" would be even better option? Another reason is when my modded shader have some instructions skipped which I would like to keep and I redump it, in some circumstances the skipped lines get deleted. It's most likely the same thing what I described in my previous post. Edit: it only happens when I move the shader out of the folder. So no osd mark will help in that case.
bo3b said:
Oomek said:Wouldn't it be to much trouble to add a currently disabled shader's hash to the OSD?

It's not a giant change to make this work, but we haven't added it because we are trying to solve the problem by better work flow. The giant hex numbers are mostly just visual noise. The main reason to use it on HelixMod was because there was no automatic copying.

In 3Dmigoto we are trying to get around ever needing those numbers by being smart about how we manage the fies. We do CopyOnMark for example, so the shader you have selected is automatically Decompiled and moved to ShaderFixes and made live. No need for big number there.

If you hit Mark on a file that already exists, we 'touch' the file so the mod date is different. If you keep your folder sorted by date, then the most recent thing you've looked at it is on top. No need for big number.

You might want an image with that big number stamped on it, showing the effect. We have this as a saved off JPS file in the folder whenever you Mark, with the same file name as the shader. (I hope to add an _on/_off for two JPS files.)


Not saying no, but please give me an idea of your workflow, and why this seems necessary.


I'm actually trying to avoid timestamping my previously modified shaders. I'm sorting by date and when for example I'm editing all the water shaders simultaneously (there is 12 of them in Dirt 3) and I accidentally redump an old one it breaks the workflow a bit.

Maybe adding a little mark on the osd saying "dumped" or "fixed" would be even better option?

Another reason is when my modded shader have some instructions skipped which I would like to keep and I redump it, in some circumstances the skipped lines get deleted. It's most likely the same thing what I described in my previous post.

Edit: it only happens when I move the shader out of the folder. So no osd mark will help in that case.

EVGA GeForce GTX 980 SC
Core i5 2500K
MSI Z77A-G45
8GB DDR3
Windows 10 x64

Posted 12/12/2015 03:38 AM   
[quote="DarkStarSword"][quote="Oomek"]Hi, I've got a couple of questions. Does 3DM give the ability to add another render target to the shader and use it in another as a texture?[/quote]This is a planned feature for the near future - the pieces are almost all there, all that's missing is the ability to create a new render target compatible with what the shader is already using. That said, depending on exactly what the game does and exactly what you need it might be possible to achieve this already. For example, you could try making a copy of the existing render target (so that the copy will have the same size as the original which is necessary to have both assigned at the same time), then add a reference to it in another output slot, then copy it into the destination shader as a texture. That would look something like this: Note that this example will exercise untested code paths (namely, assigning a render target) so there could be bugs - if you find any let me know: [code] [ResourceNewRenderTarget] [ShaderOverrideWithInjectedRenderTarget] Hash = ... ; Make the new render target compatible with the existing one (3DMigoto will ; automatically choose "copy" since the destination is a custom resource, but ; it's important for this scenario so I'm specifying it explicitly): ResourceNewRenderTarget = copy o0 ; Then add it as a second render target (3DMigoto should automatically choose ; "reference" since the destination is an output slot and the source is a ; custom resource, but it's important for this scenario so I'm specifying it ; explicitly): o1 = reference ResourceNewRenderTarget ; Unbind the render target after the draw call to make sure it won't cause ; any issues for the game, and so we can reference it in a texture slot later: post o1 = null [ShaderOverrideWithInjectedTexture] Hash = ... ; Now copy it into this shader as a texture (either "copy" or "reference" ; should work, but if you use reference make sure it's not bound as both an input ; and an output simultaneously by explicitly unbinding it after the draw ; calls): ps-t108 = copy ResourceNewRenderTarget ; Unbind the texture after the draw call - not strictly necessary since we ; copied it into this shader instead of referencing it, but good practice for ; any resource that is to be used as both an input and an output: post ps-t108 = null [/code] [/quote] Would you give me an example please of how to add that reference to o1 in the shader code? Shall I just add the out float4 o1 : SV_Target1 ?
DarkStarSword said:
Oomek said:Hi, I've got a couple of questions.

Does 3DM give the ability to add another render target to the shader and use it in another as a texture?
This is a planned feature for the near future - the pieces are almost all there, all that's missing is the ability to create a new render target compatible with what the shader is already using.

That said, depending on exactly what the game does and exactly what you need it might be possible to achieve this already.

For example, you could try making a copy of the existing render target (so that the copy will have the same size as the original which is necessary to have both assigned at the same time), then add a reference to it in another output slot, then copy it into the destination shader as a texture. That would look something like this:

Note that this example will exercise untested code paths (namely, assigning a render target) so there could be bugs - if you find any let me know:

[ResourceNewRenderTarget]

[ShaderOverrideWithInjectedRenderTarget]
Hash = ...
; Make the new render target compatible with the existing one (3DMigoto will
; automatically choose "copy" since the destination is a custom resource, but
; it's important for this scenario so I'm specifying it explicitly):
ResourceNewRenderTarget = copy o0
; Then add it as a second render target (3DMigoto should automatically choose
; "reference" since the destination is an output slot and the source is a
; custom resource, but it's important for this scenario so I'm specifying it
; explicitly):
o1 = reference ResourceNewRenderTarget
; Unbind the render target after the draw call to make sure it won't cause
; any issues for the game, and so we can reference it in a texture slot later:
post o1 = null

[ShaderOverrideWithInjectedTexture]
Hash = ...
; Now copy it into this shader as a texture (either "copy" or "reference"
; should work, but if you use reference make sure it's not bound as both an input
; and an output simultaneously by explicitly unbinding it after the draw
; calls):
ps-t108 = copy ResourceNewRenderTarget
; Unbind the texture after the draw call - not strictly necessary since we
; copied it into this shader instead of referencing it, but good practice for
; any resource that is to be used as both an input and an output:
post ps-t108 = null



Would you give me an example please of how to add that reference to o1 in the shader code? Shall I just add the

out float4 o1 : SV_Target1 ?

EVGA GeForce GTX 980 SC
Core i5 2500K
MSI Z77A-G45
8GB DDR3
Windows 10 x64

Posted 12/12/2015 04:45 AM   
[quote="Oomek"]I'm actually trying to avoid timestamping my he previously modified shaders. I'm sorting by date and when for example I'm editing all the water shaders simultaneously (there is 12 of them in Dirt 3) and I accidentally redump an old one it breaks the workflow a bit. Maybe adding a little mark on the osd saying "dumped" or "fixed" would be even better option? Another reason is when my modded shader have some instructions skipped which I would like to keep and I redump it, in some circumstances the skipped lines get deleted. It's most likely the same thing what I described in my previous post. Edit: it only happens when I move the shader out of the folder. So no osd mark will help in that case.[/quote] OK, thanks for that. How about if we add the idea related to masterotaku, and add something found in the file itself? So for example, if the first line of the file starts with "//OSD: " we take whatever the text is, and put it up on screen. That would be flexible, allow you to put anything you want as a text reminder for the file. //OSD: Water, Done. //OSD: Water, needs work. This would put the onus upon you to write a comment, but that seems better than just looking for files in ShaderFixes, as some might be there and not be fixed, or might be there with a bad fix and still need work. If you really wanted the hash code, that would allow you to change that line to the hash. If we decide it's best, we could have an auto-generated default there of "//OSD: ShaderFixes" or something to show it's already live. This approach seems like it would solve your problem of fixing them in order and be able to see which you've finished. BTW, a lot of the ShaderHackers will actually batch fix shaders offline, as part of their workflow. So, if a set of shaders are very similar, they'll batch fix 10s, sometimes 100s of shaders using offline tools like grep/awk, python, VisualBasic scripts, regexp in NotePad++.
Oomek said:I'm actually trying to avoid timestamping my he previously modified shaders. I'm sorting by date and when for example I'm editing all the water shaders simultaneously (there is 12 of them in Dirt 3) and I accidentally redump an old one it breaks the workflow a bit.

Maybe adding a little mark on the osd saying "dumped" or "fixed" would be even better option?

Another reason is when my modded shader have some instructions skipped which I would like to keep and I redump it, in some circumstances the skipped lines get deleted. It's most likely the same thing what I described in my previous post.

Edit: it only happens when I move the shader out of the folder. So no osd mark will help in that case.

OK, thanks for that.

How about if we add the idea related to masterotaku, and add something found in the file itself?

So for example, if the first line of the file starts with "//OSD: " we take whatever the text is, and put it up on screen. That would be flexible, allow you to put anything you want as a text reminder for the file.

//OSD: Water, Done.
//OSD: Water, needs work.


This would put the onus upon you to write a comment, but that seems better than just looking for files in ShaderFixes, as some might be there and not be fixed, or might be there with a bad fix and still need work.

If you really wanted the hash code, that would allow you to change that line to the hash.

If we decide it's best, we could have an auto-generated default there of "//OSD: ShaderFixes" or something to show it's already live.


This approach seems like it would solve your problem of fixing them in order and be able to see which you've finished.

BTW, a lot of the ShaderHackers will actually batch fix shaders offline, as part of their workflow. So, if a set of shaders are very similar, they'll batch fix 10s, sometimes 100s of shaders using offline tools like grep/awk, python, VisualBasic scripts, regexp in NotePad++.

Acer H5360 (1280x720@120Hz) - ASUS VG248QE with GSync mod - 3D Vision 1&2 - Driver 372.54
GTX 970 - i5-4670K@4.2GHz - 12GB RAM - Win7x64+evilKB2670838 - 4 Disk X25 RAID
SAGER NP9870-S - GTX 980 - i7-6700K - Win10 Pro 1607
Latest 3Dmigoto Release
Bo3b's School for ShaderHackers

Posted 12/12/2015 06:14 AM   
[quote="Oomek"]I don't know if this is a bug or not, but I feel like reporting it anyway. Here's how it works: 1. dump a shader 2. modify it's output 3. delete the shader's file 4. press reload shaders button on a kb 5. dump shader again The result: file dumped will contain a previously modified file. I have shader cache disabled in NV control panel. Also cache_shaders=0[/quote] That seems like a bug for sure. We try to always be sure to never overwrite a file in ShaderFixes, because a ShaderHacker might have already put a lot of work into that file, and we'd blow away their changes. That's why we do the 'touch' operation instead, as a way to move it to the top of the modified list, but otherwise unmodified. Should also give a low-beep as warning. If the file has been deleted, we might very well be using the wrong binary source for a second pass. We should always be using the original loaded by the game, but after the text file is deleted, I'm not sure what happens.
Oomek said:I don't know if this is a bug or not, but I feel like reporting it anyway.

Here's how it works:
1. dump a shader
2. modify it's output
3. delete the shader's file
4. press reload shaders button on a kb
5. dump shader again

The result: file dumped will contain a previously modified file.

I have shader cache disabled in NV control panel. Also cache_shaders=0

That seems like a bug for sure.

We try to always be sure to never overwrite a file in ShaderFixes, because a ShaderHacker might have already put a lot of work into that file, and we'd blow away their changes. That's why we do the 'touch' operation instead, as a way to move it to the top of the modified list, but otherwise unmodified. Should also give a low-beep as warning.

If the file has been deleted, we might very well be using the wrong binary source for a second pass. We should always be using the original loaded by the game, but after the text file is deleted, I'm not sure what happens.

Acer H5360 (1280x720@120Hz) - ASUS VG248QE with GSync mod - 3D Vision 1&2 - Driver 372.54
GTX 970 - i5-4670K@4.2GHz - 12GB RAM - Win7x64+evilKB2670838 - 4 Disk X25 RAID
SAGER NP9870-S - GTX 980 - i7-6700K - Win10 Pro 1607
Latest 3Dmigoto Release
Bo3b's School for ShaderHackers

Posted 12/12/2015 06:20 AM   
[quote="bo3b"][quote="Oomek"]I'm actually trying to avoid timestamping my he previously modified shaders. I'm sorting by date and when for example I'm editing all the water shaders simultaneously (there is 12 of them in Dirt 3) and I accidentally redump an old one it breaks the workflow a bit. Maybe adding a little mark on the osd saying "dumped" or "fixed" would be even better option? Another reason is when my modded shader have some instructions skipped which I would like to keep and I redump it, in some circumstances the skipped lines get deleted. It's most likely the same thing what I described in my previous post. Edit: it only happens when I move the shader out of the folder. So no osd mark will help in that case.[/quote] OK, thanks for that. How about if we add the idea related to masterotaku, and add something found in the file itself? So for example, if the first line of the file starts with "//OSD: " we take whatever the text is, and put it up on screen. That would be flexible, allow you to put anything you want as a text reminder for the file. //OSD: Water, Done. //OSD: Water, needs work. This would put the onus upon you to write a comment, but that seems better than just looking for files in ShaderFixes, as some might be there and not be fixed, or might be there with a bad fix and still need work. If you really wanted the hash code, that would allow you to change that line to the hash. If we decide it's best, we could have an auto-generated default there of "//OSD: ShaderFixes" or something to show it's already live. This approach seems like it would solve your problem of fixing them in order and be able to see which you've finished. [/quote] This is a brilliant idea! It's more than I expected. :) I support the part with auto generated //OSD: line
bo3b said:
Oomek said:I'm actually trying to avoid timestamping my he previously modified shaders. I'm sorting by date and when for example I'm editing all the water shaders simultaneously (there is 12 of them in Dirt 3) and I accidentally redump an old one it breaks the workflow a bit.

Maybe adding a little mark on the osd saying "dumped" or "fixed" would be even better option?

Another reason is when my modded shader have some instructions skipped which I would like to keep and I redump it, in some circumstances the skipped lines get deleted. It's most likely the same thing what I described in my previous post.

Edit: it only happens when I move the shader out of the folder. So no osd mark will help in that case.

OK, thanks for that.

How about if we add the idea related to masterotaku, and add something found in the file itself?

So for example, if the first line of the file starts with "//OSD: " we take whatever the text is, and put it up on screen. That would be flexible, allow you to put anything you want as a text reminder for the file.

//OSD: Water, Done.
//OSD: Water, needs work.


This would put the onus upon you to write a comment, but that seems better than just looking for files in ShaderFixes, as some might be there and not be fixed, or might be there with a bad fix and still need work.

If you really wanted the hash code, that would allow you to change that line to the hash.

If we decide it's best, we could have an auto-generated default there of "//OSD: ShaderFixes" or something to show it's already live.


This approach seems like it would solve your problem of fixing them in order and be able to see which you've finished.


This is a brilliant idea! It's more than I expected. :) I support the part with auto generated //OSD: line

EVGA GeForce GTX 980 SC
Core i5 2500K
MSI Z77A-G45
8GB DDR3
Windows 10 x64

Posted 12/12/2015 12:15 PM   
[quote="Oomek"]Would you give me an example please of how to add that reference to o1 in the shader code? Shall I just add the out float4 o1 : SV_Target1 ?[/quote]Yep, that's right. Note that I haven't tested the code that assigns the render targets so it's entirely possible that there might be bugs there - let me know if it doesn't seem to be working.
Oomek said:Would you give me an example please of how to add that reference to o1 in the shader code? Shall I just add the

out float4 o1 : SV_Target1 ?
Yep, that's right. Note that I haven't tested the code that assigns the render targets so it's entirely possible that there might be bugs there - let me know if it doesn't seem to be working.

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

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

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

Posted 12/12/2015 12:53 PM   
With the help of DarkStar yesterday, I was able to fix the skyboxes. Now, I would like to fix water reflections as well, and later shadows. The problem with the water is that it adds stereo separation to the reflections, but those already had separation, so now the reflections are not lined up with their objects on the land. If I remove the separation with the following formula [code]"o0.x -= separation * (o0.w - convergence);"[/code] then the reflections are ok, but the water itself is rendered at screendepth. Is there a way to detect in the water reflection vertex shader if the currently processed input already has separation applied to it so this shader shouldn't add it's own separation? Or in other words, apply the separation only to the water itself and skip in case of reflections? Thank you in advance!
With the help of DarkStar yesterday, I was able to fix the skyboxes. Now, I would like to fix water reflections as well, and later shadows.
The problem with the water is that it adds stereo separation to the reflections, but those already had separation, so now the reflections are not lined up with their objects on the land. If I remove the separation with the following formula
"o0.x -= separation  * (o0.w - convergence);"

then the reflections are ok, but the water itself is rendered at screendepth.

Is there a way to detect in the water reflection vertex shader if the currently processed input already has separation applied to it so this shader shouldn't add it's own separation? Or in other words, apply the separation only to the water itself and skip in case of reflections?

Thank you in advance!

Posted 12/12/2015 02:05 PM   
[quote="DarkStarSword"][quote="Oomek"]Btw, Do you have in plans maybe (in some undefined future) to extend the OSD in the way that it would allow to peek on the variables in real time?[/quote]I've been mulling the idea around in my head for a while, so it's certainly on the cards, but I haven't decided on the best way to make it work yet. One idea that I was leaning towards, was rather than implement support directly in 3DMigoto, write some custom shaders to visualise the data buffers of interest in various ways and run them at a point of interest in the frame (probably skipping over remaining draw calls, or maybe just run them just before the present call using a buffer copied from earlier). That would potentially give us quite a bit of flexibility without over-complicating 3DMigoto itself, and we could create a library of the most useful visualisations. If you have any suggestions as to what you would like this to look like I'm all ears. I can't promise when (or if) I'll start working on it - custom shaders are on the way since I want them for other reasons as well, but anything specific to this idea is a lower priority for now.[/quote] There have be many, many times I wished I could see what the values were in a shader, and even have done some tedious if/then reload sequences to narrow down relative sizes. As a simplistic stab at this that would still be pretty useful, what if we show the set of iniParams on screen? Then in the shader, anything that was interesting to review could be stuffed into the iniParams and automatically show up on screen. Not as flexible as driving the full buffers, but something?
DarkStarSword said:
Oomek said:Btw, Do you have in plans maybe (in some undefined future) to extend the OSD in the way that it would allow to peek on the variables in real time?
I've been mulling the idea around in my head for a while, so it's certainly on the cards, but I haven't decided on the best way to make it work yet.

One idea that I was leaning towards, was rather than implement support directly in 3DMigoto, write some custom shaders to visualise the data buffers of interest in various ways and run them at a point of interest in the frame (probably skipping over remaining draw calls, or maybe just run them just before the present call using a buffer copied from earlier). That would potentially give us quite a bit of flexibility without over-complicating 3DMigoto itself, and we could create a library of the most useful visualisations.

If you have any suggestions as to what you would like this to look like I'm all ears. I can't promise when (or if) I'll start working on it - custom shaders are on the way since I want them for other reasons as well, but anything specific to this idea is a lower priority for now.

There have be many, many times I wished I could see what the values were in a shader, and even have done some tedious if/then reload sequences to narrow down relative sizes.

As a simplistic stab at this that would still be pretty useful, what if we show the set of iniParams on screen? Then in the shader, anything that was interesting to review could be stuffed into the iniParams and automatically show up on screen. Not as flexible as driving the full buffers, but something?

Acer H5360 (1280x720@120Hz) - ASUS VG248QE with GSync mod - 3D Vision 1&2 - Driver 372.54
GTX 970 - i5-4670K@4.2GHz - 12GB RAM - Win7x64+evilKB2670838 - 4 Disk X25 RAID
SAGER NP9870-S - GTX 980 - i7-6700K - Win10 Pro 1607
Latest 3Dmigoto Release
Bo3b's School for ShaderHackers

Posted 12/12/2015 05:17 PM   
Hi shader masters. Do you know by any chance some quick method which would allow me to see which outputs are tied to which inputs in the shaders chain?
Hi shader masters. Do you know by any chance some quick method which would allow me to see which outputs are tied to which inputs in the shaders chain?

EVGA GeForce GTX 980 SC
Core i5 2500K
MSI Z77A-G45
8GB DDR3
Windows 10 x64

Posted 12/12/2015 09:29 PM   
[quote="bo3b"] There have be many, many times I wished I could see what the values were in a shader, and even have done some tedious if/then reload sequences to narrow down relative sizes. As a simplistic stab at this that would still be pretty useful, what if we show the set of iniParams on screen? Then in the shader, anything that was interesting to review could be stuffed into the iniParams and automatically show up on screen. Not as flexible as driving the full buffers, but something? [/quote] Iniparams on the osd would do, but how to write to them from the shader code? I thought they are read only.
bo3b said:
There have be many, many times I wished I could see what the values were in a shader, and even have done some tedious if/then reload sequences to narrow down relative sizes.

As a simplistic stab at this that would still be pretty useful, what if we show the set of iniParams on screen? Then in the shader, anything that was interesting to review could be stuffed into the iniParams and automatically show up on screen. Not as flexible as driving the full buffers, but something?


Iniparams on the osd would do, but how to write to them from the shader code? I thought they are read only.

EVGA GeForce GTX 980 SC
Core i5 2500K
MSI Z77A-G45
8GB DDR3
Windows 10 x64

Posted 12/13/2015 12:29 AM   
[quote="bo3b"]There have be many, many times I wished I could see what the values were in a shader, and even have done some tedious if/then reload sequences to narrow down relative sizes. As a simplistic stab at this that would still be pretty useful, what if we show the set of iniParams on screen? Then in the shader, anything that was interesting to review could be stuffed into the iniParams and automatically show up on screen. Not as flexible as driving the full buffers, but something? [/quote] The general concept of pulling info out of the shader using a writable resource is fine, but I don't think IniParams is the way to do it - it's a small texture that we might overwrite many times in a frame from the CPU. To do this without stalling the pipeline we discard whatever was in the texture on the GPU with the master copy on the CPU. We also can't write to it from the shader since it is assigned to an input slot, not an output slot. What's more, we can't assign it to an output slot because it won't match the dimensions of other assigned render targets and we can't simultaneously assign a resource to both input and output slots. I think there's several stages in the pipeline we might be interested in, each with their own complications CASE 1 - SHOW VERTEX SHADER INPUTS 3DMigoto can get access to these values directly (albiet with some potential for pipeline stalling), which is what frame analysis does when you use the dump_tex, dump_cb_txt, dump_vb_txt or dump_ib_txt options. This is one case where expanding frame analysis might be the way to go to show a subset of these live. Arbitrary resource copying could also be used quite easily to copy them into another shader that will visualise them in some manner. CASE 2 - SHOW VALUES IN THE VERTEX/HULL/DOMAIN/GEOMETRY SHADERS This case is somewhat complicated by the fact that writable resources cannot be bound to these pipeline stages. The two options here are: - Add an additional output to these shaders that is passed through to the pixel shader and refer to case 3. This will lose the per-vertex information and relies on at least one pixel of the effect being drawn to output anything at all, and we might need to search the output buffer to find that pixel since it's not always going to be at the top-left. - Assign a buffer to the stream output stage of the pipeline (vertex or geometry stages only). This is complicated by the fact that we need to set this up in advance when the shader was created (via CreateGeometryShaderWithStreamOutput), but we could possibly make this work if we save off enough info about the shaders (which we probably already do in hunting mode) to recreate the shader as needed with the required stream output declaration. This has the advantage that we will know which vertex the information came from, and can collate information from multiple draw calls (buffer offset handling still needs some work in 3DMigoto for this). - If we restrict ourselves to Windows 8 and DirectX 11.1 we could use UAVs to output information from the vertex shaders directly. We probably don't want to make this compromise, and probably cannot do this most of the time even if we wanted to. CASE 3 - SHOW VALUES IN THE PIXEL/COMPUTE SHADERS These shaders support assigning additional render targets (pixel shaders only) or unordered access views as outputs (which can be done via the arbitrary resource copying support in 3DMigoto, bugs notwithstanding), which we can use to capture information from them. Further, frame analysis already supports dumping their outputs (buffers and 2D textures only at the moment), so expanding that to be able to show them live instead of dumping them to disk is one possibility. Assigning additional outputs as render targets is constrained by the fact that they must match the type and dimensions of any other render targets or depth/stencil targets assigned to the pipeline. I don't believe that the same constraint applies when using unordered access views instead (but need to confirm), and these open up some rather interesting possibilities. UAVs can be 1D, 2D or 3D textures, or they can be typed buffers, or writable structured buffers, or raw byte access buffers, or perhaps most interestingly - append/consume structured buffers. Using these would give us a great deal of flexibility with what sort of data we pass out of the shader, and I already want to add support for creating and using all these types of UAVs to 3DMigoto's arbitrary resource copying support - because I want to pass information (like the position and depth of all enemies on the screen) from one shader to another (like the corresponding health bar shader) for actual fixes as well. COMPLICATIONS: MULTIPLE VERTICES, MULTIPLE PIXELS, MULTIPLE DRAW CALLS If we want to show some information we have the further complication that there are multiple vertices in a draw call, which may or may not have different values of the information we are looking for. Then later we may or may not have different values for each pixel that is to be drawn, then later another draw call might come along using the same shaders but different values. In these cases what do we want to do? Do we want to get all the different values that were used in every draw call, or maybe we just need any value and don't care which vertex, pixel or draw call it came from. This is really hard to pick an answer that will work for everyone because we don't know what kind of information the shaderhacker will be trying to retrieve. Erring on the side of not showing much risks missing some vital clue the shaderhacker needs, but outputting everything could easily result in being presented with too much information to process (and that's assuming we even have enough pixels on the display to show "everything" live). This is part of my reasoning for considering not supporting this explicitly in 3DMigoto, but rather expanding the arbitrary resource creation and arbitrary resource assignment/copying that 3DMigtoo already has and adding the ability to run a custom shader to visualise the information instead - that way I don't have to make a decision that I know will only only work for some cases. We might still want some support in 3DMigoto to make this easier, and perhaps there are some common cases that we might want to focus on to ensure whatever solution we come up with can support them with as little hassle as possible (one that comes to mind is displaying values from a constant buffer live, or detecting patterns in the constant buffers that could indicate the presense of certain types of matrices).
bo3b said:There have be many, many times I wished I could see what the values were in a shader, and even have done some tedious if/then reload sequences to narrow down relative sizes.

As a simplistic stab at this that would still be pretty useful, what if we show the set of iniParams on screen? Then in the shader, anything that was interesting to review could be stuffed into the iniParams and automatically show up on screen. Not as flexible as driving the full buffers, but something?


The general concept of pulling info out of the shader using a writable resource is fine, but I don't think IniParams is the way to do it - it's a small texture that we might overwrite many times in a frame from the CPU. To do this without stalling the pipeline we discard whatever was in the texture on the GPU with the master copy on the CPU. We also can't write to it from the shader since it is assigned to an input slot, not an output slot. What's more, we can't assign it to an output slot because it won't match the dimensions of other assigned render targets and we can't simultaneously assign a resource to both input and output slots.

I think there's several stages in the pipeline we might be interested in, each with their own complications

CASE 1 - SHOW VERTEX SHADER INPUTS

3DMigoto can get access to these values directly (albiet with some potential for pipeline stalling), which is what frame analysis does when you use the dump_tex, dump_cb_txt, dump_vb_txt or dump_ib_txt options. This is one case where expanding frame analysis might be the way to go to show a subset of these live.

Arbitrary resource copying could also be used quite easily to copy them into another shader that will visualise them in some manner.

CASE 2 - SHOW VALUES IN THE VERTEX/HULL/DOMAIN/GEOMETRY SHADERS

This case is somewhat complicated by the fact that writable resources cannot be bound to these pipeline stages. The two options here are:

- Add an additional output to these shaders that is passed through to the pixel shader and refer to case 3. This will lose the per-vertex information and relies on at least one pixel of the effect being drawn to output anything at all, and we might need to search the output buffer to find that pixel since it's not always going to be at the top-left.

- Assign a buffer to the stream output stage of the pipeline (vertex or geometry stages only). This is complicated by the fact that we need to set this up in advance when the shader was created (via CreateGeometryShaderWithStreamOutput), but we could possibly make this work if we save off enough info about the shaders (which we probably already do in hunting mode) to recreate the shader as needed with the required stream output declaration. This has the advantage that we will know which vertex the information came from, and can collate information from multiple draw calls (buffer offset handling still needs some work in 3DMigoto for this).

- If we restrict ourselves to Windows 8 and DirectX 11.1 we could use UAVs to output information from the vertex shaders directly. We probably don't want to make this compromise, and probably cannot do this most of the time even if we wanted to.

CASE 3 - SHOW VALUES IN THE PIXEL/COMPUTE SHADERS

These shaders support assigning additional render targets (pixel shaders only) or unordered access views as outputs (which can be done via the arbitrary resource copying support in 3DMigoto, bugs notwithstanding), which we can use to capture information from them.

Further, frame analysis already supports dumping their outputs (buffers and 2D textures only at the moment), so expanding that to be able to show them live instead of dumping them to disk is one possibility.

Assigning additional outputs as render targets is constrained by the fact that they must match the type and dimensions of any other render targets or depth/stencil targets assigned to the pipeline.

I don't believe that the same constraint applies when using unordered access views instead (but need to confirm), and these open up some rather interesting possibilities. UAVs can be 1D, 2D or 3D textures, or they can be typed buffers, or writable structured buffers, or raw byte access buffers, or perhaps most interestingly - append/consume structured buffers. Using these would give us a great deal of flexibility with what sort of data we pass out of the shader, and I already want to add support for creating and using all these types of UAVs to 3DMigoto's arbitrary resource copying support - because I want to pass information (like the position and depth of all enemies on the screen) from one shader to another (like the corresponding health bar shader) for actual fixes as well.


COMPLICATIONS: MULTIPLE VERTICES, MULTIPLE PIXELS, MULTIPLE DRAW CALLS

If we want to show some information we have the further complication that there are multiple vertices in a draw call, which may or may not have different values of the information we are looking for. Then later we may or may not have different values for each pixel that is to be drawn, then later another draw call might come along using the same shaders but different values. In these cases what do we want to do? Do we want to get all the different values that were used in every draw call, or maybe we just need any value and don't care which vertex, pixel or draw call it came from. This is really hard to pick an answer that will work for everyone because we don't know what kind of information the shaderhacker will be trying to retrieve. Erring on the side of not showing much risks missing some vital clue the shaderhacker needs, but outputting everything could easily result in being presented with too much information to process (and that's assuming we even have enough pixels on the display to show "everything" live).

This is part of my reasoning for considering not supporting this explicitly in 3DMigoto, but rather expanding the arbitrary resource creation and arbitrary resource assignment/copying that 3DMigtoo already has and adding the ability to run a custom shader to visualise the information instead - that way I don't have to make a decision that I know will only only work for some cases. We might still want some support in 3DMigoto to make this easier, and perhaps there are some common cases that we might want to focus on to ensure whatever solution we come up with can support them with as little hassle as possible (one that comes to mind is displaying values from a constant buffer live, or detecting patterns in the constant buffers that could indicate the presense of certain types of matrices).

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

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

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

Posted 12/13/2015 04:28 AM   
[quote="Oomek"]Hi shader masters. Do you know by any chance some quick method which would allow me to see which outputs are tied to which inputs in the shaders chain?[/quote]This is supposed to be what the semantic names and indices are for - "out foo : texcoord5" in the vertex shader is supposed to match "in bar : texcoord5" in the pixel shader. But as always there are gotchas - this one is named fxc (the shader compiler). fxc doesn't like respecting these semantics and may decide that since you just used texcoord1 and are now saying texcoord5, that you surely didn't mean that and most certainly meant texcoord2, right? Or maybe that since texcoord1 was only used for a float2 and since you are also only asking to pack a float2 into texcoord5, maybe it would be really helpful if it packed that into the .z and .w components of texcoord1 instead? That's mostly a problem for our decompiler to deal with though - if the output signature of a shader matches the input signature of another, the matching semantics should show you which outputs are tied to which inputs.
Oomek said:Hi shader masters. Do you know by any chance some quick method which would allow me to see which outputs are tied to which inputs in the shaders chain?
This is supposed to be what the semantic names and indices are for - "out foo : texcoord5" in the vertex shader is supposed to match "in bar : texcoord5" in the pixel shader.

But as always there are gotchas - this one is named fxc (the shader compiler). fxc doesn't like respecting these semantics and may decide that since you just used texcoord1 and are now saying texcoord5, that you surely didn't mean that and most certainly meant texcoord2, right? Or maybe that since texcoord1 was only used for a float2 and since you are also only asking to pack a float2 into texcoord5, maybe it would be really helpful if it packed that into the .z and .w components of texcoord1 instead?

That's mostly a problem for our decompiler to deal with though - if the output signature of a shader matches the input signature of another, the matching semantics should show you which outputs are tied to which inputs.

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

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

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

Posted 12/13/2015 04:42 AM   
i am thoroughly confused in disable shader..... i found dc30afb1360f741b-ps_replace.txt and b05f4cb7ce9f11e7-vs_replace.txt relat to gun model in bfh,i can see it is disabled in shader hunting mode,but i can't disable it in the ShaderFixes folder or d3dx.ini this is in dc30afb1360f741b-ps_replace.txt: float4 v0 : SV_Position0, float4 v1 : TEXCOORD0, float4 v2 : TEXCOORD1, float4 v3 : TEXCOORD2, float4 v4 : TEXCOORD3, float4 v5 : TEXCOORD4, out float4 o0 : SV_Target0, out float4 o1 : SV_Target1, out float4 o2 : SV_Target2, out float4 o3 : SV_Target3) add o0 = 0 or float4 stereo = StereoParams.Load(0); o0.x -= stereo.x * (o0.w - stereo.y); return; also tried this in d3dx.ini ;[ShaderOverride2] ;Hash=dc30afb1360f741b ;Handling=skip ..............that doesn't disable anything but if it add to b05f4cb7ce9f11e7-vs_replace.txt,it have another disable effect that diffent in shader hunting mode.tried in so many games.i can only successfully deleted part of the gun model in in shader hunting mode,so how can i save it in ShaderFixes folder?
i am thoroughly confused in disable shader.....
i found dc30afb1360f741b-ps_replace.txt and b05f4cb7ce9f11e7-vs_replace.txt relat to gun model in bfh,i can see it is disabled in shader hunting mode,but i can't disable it in the ShaderFixes folder or d3dx.ini
this is in dc30afb1360f741b-ps_replace.txt:
float4 v0 : SV_Position0,
float4 v1 : TEXCOORD0,
float4 v2 : TEXCOORD1,
float4 v3 : TEXCOORD2,
float4 v4 : TEXCOORD3,
float4 v5 : TEXCOORD4,
out float4 o0 : SV_Target0,
out float4 o1 : SV_Target1,
out float4 o2 : SV_Target2,
out float4 o3 : SV_Target3)

add o0 = 0 or
float4 stereo = StereoParams.Load(0);
o0.x -= stereo.x * (o0.w - stereo.y);
return;

also tried this in d3dx.ini
;[ShaderOverride2]
;Hash=dc30afb1360f741b
;Handling=skip

..............that doesn't disable anything

but if it add to b05f4cb7ce9f11e7-vs_replace.txt,it have another disable effect that diffent in shader hunting mode.tried in so many games.i can only successfully deleted part of the gun model in in shader hunting mode,so how can i save it in ShaderFixes folder?

Posted 12/13/2015 07:16 AM   
[quote="daspwan"] also tried this in d3dx.ini ;[ShaderOverride2] ;Hash=dc30afb1360f741b ;Handling=skip ..............that doesn't disable anything [/quote] Those ini settings are not active in the above form as they are marked as comments with the semicolons placed before them. Remove the semicolons and try it that way. [code][ShaderOverride2] Hash=dc30afb1360f741b Handling=skip[/code] I'm sorry If you are already aware of that and just accidentally copied the commented out version to your post.
daspwan said:

also tried this in d3dx.ini
;[ShaderOverride2]
;Hash=dc30afb1360f741b
;Handling=skip

..............that doesn't disable anything



Those ini settings are not active in the above form as they are marked as comments with the semicolons placed before them. Remove the semicolons and try it that way.

[ShaderOverride2]
Hash=dc30afb1360f741b
Handling=skip



I'm sorry If you are already aware of that and just accidentally copied the commented out version to your post.

Posted 12/13/2015 08:32 AM   
  42 / 141    
Scroll To Top