I want to fix what 3.1.0-3.1.1 dof detection issue
- seri14
- Topic Author
case 1:
ReShade 3.1.0 or less
case 2:
Enable copy depth before clearing
In case 2, the frame of the depth buffer is delayed.
I want to solve this problem. But I do not have graphic knowledge.
If you are busy, I resolve it myself, so please tell me the mechanism that was changed.
Please Log in or Create an account to join the conversation.
- crosire
github.com/crosire/reshade/pull/38
github.com/crosire/reshade/pull/40
github.com/crosire/reshade/pull/49
github.com/crosire/reshade/pull/51
Please Log in or Create an account to join the conversation.
- seri14
- Topic Author
I recognized this (detection) problem at september, but I could not understand that graphic process, I started with the work to fix other issues.
Even now I have not understand that graphic process, so I asked a question.
and,
The problem between versions 3.1.0 and 3.1.1 is # 38, but do I should to track changes to newer versions?
#40 is for 3.2.0
#49 and #51 is for 3.4.0
Please Log in or Create an account to join the conversation.
- crosire
Please Log in or Create an account to join the conversation.
- seri14
- Topic Author
I did not said "please compare source code".
I want to know "Where did changes the processing seen from game?".
Seen from game, detection process was where moved there?
Please Log in or Create an account to join the conversation.
- OtisInf
Nowadays games more and more use multiple render contexts for rendering (what DX11 calls deferred contexts). All draw calls to a deferred context are converted to command lists by the game and then executed on the immediate context, however which depth buffer is active at that point is unknown (as setting the buffer is part of the command list). So in the #38 pull request, I added code to track and count the drawcalls made on a deferred context as well and add them to the total # of drawcalls for a depth buffer, whether it was active on a deferred context or the immediate context.
This could lead to a different depth buffer being the one with the most draw calls. Especially in games with multi-threaded rendering (each thread renders to its own deferred context, hence the reason games use it), it made a big difference.
There was a problem tho: what if two depth buffers received the same # of draw calls? Or one which isn't the right one, received more drawcalls? My changes don't know that and sometimes made the wrong choice. The PRs following #38 added features to mitigate that, where it also allowed users to pick the right one so there was always a way to make sure the right depth buffer is picked.
HTH.
Please Log in or Create an account to join the conversation.
- thalixte
So the purpose of those PRs was to enable a new depth buffer detection mode, which makes a copy of the depth buffer in an earlier stage than the final rendering stage (mostly just before the clearing depth buffer stage).
As there can be more than one clearing steps, the UI propose the user to select the one where he wants the depth buffer to be retrieved.
In some games (for instance, Shadow Warrior 2, or Project Cars 2), those techniques made it possible to retrieve a valid depth buffer.
Note that, like all the depth buffer retrieval techniques, the db retrieval can only work in offline mode. It is intended.
Please Log in or Create an account to join the conversation.
- seri14
- Topic Author
Using in ESO at after fixed, User must toggle on [Copy depth before clearing] and [Extended depth buffer detection].
Is this correct?
or require add/fix conditions/codes? (e.g. add [Copy all resources immediately] option)
Modify code:
github.com/crosire/reshade/blob/317b252f..._context.cpp#L58-L59
And I have a question, What means this code?
_device->_clear_DSV_iter <= runtime->cleared_depth_buffer_index
_device->_clear_DSV_iter == runtime->cleared_depth_buffer_index
Please Log in or Create an account to join the conversation.
- thalixte
seri14 wrote: I found how to just fix this (the delayed depth) problem.
Using in ESO at after fixed, User must toggle on [Copy depth before clearing] and [Extended depth buffer detection].
Is this correct?
or require add/fix conditions/codes? (e.g. add [Copy all resources immediately] option)
Modify code:
github.com/crosire/reshade/blob/317b252f..._context.cpp#L58-L59
And I have a question, What means this code?I do not know why not this code._device->_clear_DSV_iter <= runtime->cleared_depth_buffer_index_device->_clear_DSV_iter == runtime->cleared_depth_buffer_index
The number of clearing instances of depth buffer can fluctuate from one frame to another.
Take an example:
In frame 1, you can have four depthstencil clearing passes.
In frame 2, you have only three depthstencil clearing passes.
In this case, if cleared_depth_buffer_index = 4 (which means you retrieve the depth buffer at the last clearing pass), when the clearing instances decrease, you cannot retrieve a valid depthstencil in frame 2 because this index does not correspond to any existing clearing instance
In order to fix it, i prefer to check if the index is greater or equal than the current clearing index (hope i make it clear for you, not sure it is).
Please Log in or Create an account to join the conversation.
- seri14
- Topic Author
Please Log in or Create an account to join the conversation.
- thalixte
Please Log in or Create an account to join the conversation.
- seri14
- Topic Author
This function does remove the revision of depths until found that they have flagged on of the cleared. (from newest revision to oldest in a span of one frame)
The tracking process is expect that this game does clear the depth before "Present()" call, but this game does reverse behavior.
so in the current frame, the just updated depth stencil view will be ignored at find the best of the depth. (this is the reason of delaying)
This change is make certain that "save_depth_texture()" function does copy the last used depth texture before "Present()" call.
And add support that if game does clearing depth stencil view at inverted timing.
To solve this issue, user can use option of "Always copy depth buffer" or "Inverted".
Fix delaying of depth detection
github.com/crosire/reshade/pull/119
Please Log in or Create an account to join the conversation.
- thalixte
seri14 wrote: Focus to "keep_cleared_depth_textures()" function.
This function does remove the revision of depths until found that they have flagged on of the cleared. (from newest revision to oldest in a span of one frame)
The tracking process is expect that this game does clear the depth before "Present()" call, but this game does reverse behavior.
so in the current frame, the just updated depth stencil view will be ignored at find the best of the depth. (this is the reason of delaying)
This change is make certain that "save_depth_texture()" function does copy the last used depth texture before "Present()" call.
And add support that if game does clearing depth stencil view at inverted timing.
To solve this issue, user can use option of "Always copy depth buffer" or "Inverted".
Fix delaying of depth detection
github.com/crosire/reshade/pull/119
Ok, i see. But, normally, the last used depth textures before "Present()" call are not cleared, so why does the depth buffer does not display with the standard mode ?
Please Log in or Create an account to join the conversation.
- seri14
- Topic Author
The important DSV does always referring to same texture and the depth results is still alive at begin of frame.
The next step in the future is I think good to do compare the standard mode with the case of enabled [Extended depth buffer detection] and [Always copy depth buffer] options.
It should have same reason.
Please Log in or Create an account to join the conversation.
- seri14
- Topic Author
as you said "not cleared", This word make confuse to us that it break the subject. (who, what/whom)
I have not mistake about the timing and what the tracker does.
Please Log in or Create an account to join the conversation.
- thalixte
seri14 wrote: And the words "clear" and "cleared" are the reason why these codes are hard to read.
as you said "not cleared", This word make confuse to us that it break the subject. (who, what/whom)
I have not mistake about the timing and what the tracker does.
Thks . So you suggest me to change this portion of code, and use another term ? I use the term "cleared" to refer to the depthstencil textures that were cleared by the ClearDepthStencilView, by opposition to the ones that are kept until the present stage arises. Sorry, but i don't remember in which game i was forced to introduce this filtering.
Have you tried to force the clearing of the depth textures at the end of the present stage ? Maybe doing so will fix the pb in an easier way ?
For instance, in DX9, i added an extra clearing step at the end of the present method, in order to ensure the depth buffer is cleared before the next frame.
Please Log in or Create an account to join the conversation.
- seri14
- Topic Author
Please Log in or Create an account to join the conversation.
- thalixte
seri14 wrote: I give up
Oh, really I will try to see what i can do (this will make me dive again in my portions of code to remember how it works. Before implementing this in DX12, it is a good idea, i guess...).
Please Log in or Create an account to join the conversation.
- seri14
- Topic Author
github.com/crosire/reshade/pull/119
Please Log in or Create an account to join the conversation.
- thalixte
seri14 wrote: Fix delaying of depth detection #119
github.com/crosire/reshade/pull/119
Please, could it be possible for you to post a video of the pb in The Elder Scolls Online, in order for me to better understand your PR ?
By advance, thks...
Please Log in or Create an account to join the conversation.