Time increase for post-processing (RESHADE v5)
- nolan
- Topic Author
Less
More
1 year 3 months ago - 1 year 3 months ago #1
by nolan
Time increase for post-processing (RESHADE v5) was created by nolan
Hi, I'm trying to update reshade from version 491 to 551 and I'm experiencing a time increase for any post processing effect.
Even with something simple as screen CAS.fx there seems to be a double penalty in time spent with the CPU.
Dunno about the GPU time since on the older version there no output for.
The issues first appear in version 500 and it's not present with 491.
Doesn't appear to be CAS specific because the increase with the spent time on the CPU happen to LumaSharpen.fx and all other shaders.
Also, with more shader enabled the one top run with the double frame delta while the down-most exhibit their real execution time.
Thank you.
Even with something simple as screen CAS.fx there seems to be a double penalty in time spent with the CPU.
V491 (CAS 20ms)
Dunno about the GPU time since on the older version there no output for.
The issues first appear in version 500 and it's not present with 491.
Doesn't appear to be CAS specific because the increase with the spent time on the CPU happen to LumaSharpen.fx and all other shaders.
Also, with more shader enabled the one top run with the double frame delta while the down-most exhibit their real execution time.
-
Stack 1 (levelplus 44ms | lumasharpen 15ms ) V551
-
Stack 2 (displayLUT 50ms | levelplus 16ms | lumasharpen 13ms ) V551
-
Is there a way to reduce the draw time for the top chain with reshade version 5 or is there some new default option to disable/change to get back the performance of version 4?Stack 1 (levelplus 44ms | lumasharpen 15ms ) V551
-
Stack 2 (displayLUT 50ms | levelplus 16ms | lumasharpen 13ms ) V551
-
Thank you.
Last edit: 1 year 3 months ago by nolan. Reason: formatting
Please Log in or Create an account to join the conversation.
- crosire
Less
More
1 year 3 months ago - 1 year 3 months ago #2
by crosire
Replied by crosire on topic Time increase for post-processing (RESHADE v5)
Capturing the GPU statistics has noticeable CPU overhead, which didn't exist before of course. But ReShade only captures those statistics if the "Statistics" window is visible, close the overlay and you'll get the same performance as before again, so it shouldn't be an issue.
Last edit: 1 year 3 months ago by crosire.
The following user(s) said Thank You: nolan
Please Log in or Create an account to join the conversation.
- nolan
- Topic Author
Less
More
1 year 3 months ago #3
by nolan
Replied by nolan on topic Time increase for post-processing (RESHADE v5)
The statistics offered by reshade (till the 4.9.1 version) are very helpful to estimate the global performance especially on still running static camera and scenes.
In the first post the capture above has been made on one know game menu with very few elements outside a looping video for quick reproduction.
Having something else hook to measure the added overhead of reshade would add another overhead layer on top that would require some major code and development to ascertain the real time difference while the view is not visible.
Hope there a way for you to consider to allow the user to disable whatever is causing the CPU time discrepancy, like the performance mode toggle, or make it available to option out directly the affected component within the configuration.
Thank you for the terrific and defining tool.
In the first post the capture above has been made on one know game menu with very few elements outside a looping video for quick reproduction.
Having something else hook to measure the added overhead of reshade would add another overhead layer on top that would require some major code and development to ascertain the real time difference while the view is not visible.
Hope there a way for you to consider to allow the user to disable whatever is causing the CPU time discrepancy, like the performance mode toggle, or make it available to option out directly the affected component within the configuration.
Thank you for the terrific and defining tool.
Please Log in or Create an account to join the conversation.
- crosire
Less
More
1 year 3 months ago #4
by crosire
Replied by crosire on topic Time increase for post-processing (RESHADE v5)
The Statistics page is aimed at developers and the CPU statistics are irrelevant for effect development (they run on the GPU). I should just remove them really. They don't add value.
Please Log in or Create an account to join the conversation.
- nolan
- Topic Author
Less
More
1 year 3 months ago #5
by nolan
Replied by nolan on topic Time increase for post-processing (RESHADE v5)
The use I made with the retrieved CPU time is outside the scope of development.
For posterity in version 5.5.1 returning false on line 2040 of source\runtime_gui.cpp nets a decent improvement for the statistic view yet still 0.010ms off by the value of 4.9.1
V551 custom build (CAS 30ms) with: _gather_gpu_statistics = false;
For posterity in version 5.5.1 returning false on line 2040 of source\runtime_gui.cpp nets a decent improvement for the statistic view yet still 0.010ms off by the value of 4.9.1
V551 custom build (CAS 30ms) with: _gather_gpu_statistics = false;
Please Log in or Create an account to join the conversation.
- crosire
Less
More
1 year 3 months ago - 1 year 3 months ago #6
by crosire
Replied by crosire on topic Time increase for post-processing (RESHADE v5)
We are talking 10 microseconds CPU time, that's not going to show up in a noticeable way. I should also mention that the values between ReShade 4 and 5 are not strictly comparable, since they are measured at slightly different locations/intervals.
But even if they were, them not being the same would still be expected: ReShade 5 renders a bit different, e.g. using D3D12 render passes instead of binding render targets directly. This gives the driver more hints to work with for better performance on the GPU, at the cost of negligible CPU overhead. And all rendering commands now go through an API abstraction layer in ReShade 5 with a single unified implementation of the effect rendering runtime (thus greatly enhancing feature adoption), rather than separate implementations for each graphics API, which too can add some barely measurable cost.
But you'll not find a game (which would have to be CPU-limited in the first place) where this is going to have any real impact.
I've made the change to carve out the GPU query overhead from the displayed CPU time now though.
But even if they were, them not being the same would still be expected: ReShade 5 renders a bit different, e.g. using D3D12 render passes instead of binding render targets directly. This gives the driver more hints to work with for better performance on the GPU, at the cost of negligible CPU overhead. And all rendering commands now go through an API abstraction layer in ReShade 5 with a single unified implementation of the effect rendering runtime (thus greatly enhancing feature adoption), rather than separate implementations for each graphics API, which too can add some barely measurable cost.
But you'll not find a game (which would have to be CPU-limited in the first place) where this is going to have any real impact.
I've made the change to carve out the GPU query overhead from the displayed CPU time now though.
Last edit: 1 year 3 months ago by crosire.
Please Log in or Create an account to join the conversation.
- nolan
- Topic Author
Less
More
1 year 3 months ago #7
by nolan
Replied by nolan on topic Time increase for post-processing (RESHADE v5)
Saw version 5 implementation for D3D on feature level and queue/ADDON and found the backporting code reveling, so, fully agree with any possible out-take on optimization since everything is anyway bound to be constrain by the limited CPU time availability.
Probably 4.8.2.931 should be somehow marked as candidate for codepath on future ESR versioning with direct legacy binding, or something.
Anyway, most of the GPU currently doesn't provide any access to their dumb system processor nor publish any internal routing statics execution for their blocking pipe and\or allow request since there literally no attached runnable\callback on the activity\fall.
Thank you to consider to allow/disallow the query overhead in reshade.
10 microsecond is something I can witness over necessary added value.
Probably 4.8.2.931 should be somehow marked as candidate for codepath on future ESR versioning with direct legacy binding, or something.
Anyway, most of the GPU currently doesn't provide any access to their dumb system processor nor publish any internal routing statics execution for their blocking pipe and\or allow request since there literally no attached runnable\callback on the activity\fall.
Thank you to consider to allow/disallow the query overhead in reshade.
10 microsecond is something I can witness over necessary added value.
Please Log in or Create an account to join the conversation.
- Martigen
Less
More
1 year 3 months ago - 1 year 3 months ago #8
by Martigen
Replied by Martigen on topic Time increase for post-processing (RESHADE v5)
"The Statistics page is aimed at developers and the CPU statistics are irrelevant for effect development (they run on the GPU). I should just remove them really. They don't add value."
I'd very much like to see it stay. I've used it in the past to compare shaders -- for example sharpen shaders to see which ones were the most and least demanding -- and again more recently with RTGI where I was comparing the load of the new optical flow/motion estimations shaders (and confirmed optical flow was twice as efficient), and performance of RTGI itself between versions to provide feedback.
I'd very much like to see it stay. I've used it in the past to compare shaders -- for example sharpen shaders to see which ones were the most and least demanding -- and again more recently with RTGI where I was comparing the load of the new optical flow/motion estimations shaders (and confirmed optical flow was twice as efficient), and performance of RTGI itself between versions to provide feedback.
Last edit: 1 year 3 months ago by Martigen.
The following user(s) said Thank You: nolan
Please Log in or Create an account to join the conversation.
- nolan
- Topic Author
Less
More
1 year 3 months ago - 1 year 3 months ago #9
by nolan
Replied by nolan on topic Time increase for post-processing (RESHADE v5)
I'd like to keep the CPU statistics over anything actually since its the only way to know at glance what going on with unit changes.
The tris draw call and vertices count in general were also a good way to co-measure the lost in between along the CPU statistics.
Thank you for voicing the need of keeping the CPU statistics stone fast&clean and very good job done on the super light RTGI.
You should have made each previously GI RT shader beta readily available on newer release for adoption.
The tris draw call and vertices count in general were also a good way to co-measure the lost in between along the CPU statistics.
Thank you for voicing the need of keeping the CPU statistics stone fast&clean and very good job done on the super light RTGI.
You should have made each previously GI RT shader beta readily available on newer release for adoption.
Last edit: 1 year 3 months ago by nolan. Reason: woot
Please Log in or Create an account to join the conversation.
- Martigen
Less
More
1 year 3 months ago #10
by Martigen
Replied by Martigen on topic Time increase for post-processing (RESHADE v5)
Oh you're confusing me with Marty McFly @nolan! And yes, his work on RTGI is amazing!
Please Log in or Create an account to join the conversation.
- nolan
- Topic Author
Less
More
1 year 3 months ago #11
by nolan
Replied by nolan on topic Time increase for post-processing (RESHADE v5)
Oh, sorry about that. Hope no offense taken. Still thank you for the analysis and the shared experience.
Please Log in or Create an account to join the conversation.