I want to fix what 3.1.0-3.1.1 dof detection issue

In The Elder Scrolls Online, detection of DOF works properly under conditions.

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.

A lot changed:
github.com/crosire/reshade/pull/38
github.com/crosire/reshade/pull/40
github.com/crosire/reshade/pull/49
github.com/crosire/reshade/pull/51

I had already discovered there. I know that there have many changes.
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

#38 is the important one, the rest more or less just adds new stuff without touching the existing much. I don't know how I'm supposed to explain how it works. Best way to try and understand is to read the pull request description and source code changes I guess.

I what said "mechanism" means what changed to A to B.
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?

As I wrote #38, I'll try to explain it a bit, perhaps that makes it more clear Before #38, reshade collected all draw calls to the set depth buffer on the immediate context. Per draw call there might be a different depth buffer active (or none at all). At the end of the frame, it checks which depth buffer had the most draw calls and whether it has the same dimensions as the frame buffer and picked that one as the depth buffer to pass to the reshade shaders. This worked/works OK if the game uses the immediate context for rendering only (i.e. single threaded rendering).

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.

For the #40 and #51 pull requests, the idea was to retrieve the great modifications made by OtisInf and to resolve a simple problem: how can Reshade retrieve a valid depth buffer if it has been cleared by the game engine before the final rendering happen.

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.

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.

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?

_device->_clear_DSV_iter <= runtime->cleared_depth_buffer_index

I do not know why not this code.

_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).

Solved.

Good to hear What was the pb whit The Elder Scrolls Online ?

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

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 ?

Actually I did not understand.
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.

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.

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.

I give up

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...).

Fix delaying of depth detection #119
github.com/crosire/reshade/pull/119

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...