|Anonymous | Login | Signup for a new account||2017-10-18 20:14 CEST|
|Main | My View | View Issues | Change Log | Roadmap|
|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0000462||madVR||bug||public||2016-12-26 16:50||2017-01-02 09:56|
|Platform||OS||Windows||OS Version||10.0.14393 x64|
|Summary||0000462: FinalStep rendering time spikes massively on specific video scenes when a 3DLUT is enabled|
|Description||I am experiencing a very strange problem when using madVR on my new Razer Blade 2016 laptop (Intel HD Graphics 530). Basically, madVR rendering times skyrocket during certain video scenes. This is completely reproducible - if I play the same video segment again, the issue is guaranteed to reoccur. In addition, this only happens when a 3DLUT is enabled.|
This happens only on specific scenes in a variety of videos encoded in a variety of ways (none of them "exotic" - this is very standard low-bitrate stuff). I was not able to discern a specific pattern among these problematic scenes.
|Steps To Reproduce||1. Enable the 3DLUT provided in "additional information", below.|
2. Play the short video sample provided in "additional information", below.
3. Use CTRL+J and watch render times while the sample is playing. ShowRenderSteps will provide more detail.
4. While the problematic scene is playing, the "FinalStep" rendering time will skyrocket from around ~7ms to ~25ms. If expensive madVR options are used at the same time, frames will be dropped as the system is unable to keep up.
5. After the problematic scene has passed, performance goes back to normal.
|Additional Information||The fact that this only happens on specific scenes might make this sound like a decoder performance issue, but I'm pretty sure it's not - these files are low bitrate (the sample is from a Youtube video), are very simple to decode, and switching decoders (e.g. between software and DXVA2) does not make any difference.|
Disabling the 3DLUT makes the issue go away entirely. No other madVR settings seem to make any difference (windowed/exclusive, overlay, D3D11, use separate device for presentation, queue size, flush settings, trade quality for performance, etc.).
The following file: https://drive.google.com/file/d/0B4SHVPm2DfK5bTY5a283SkUtWDQ/view?usp=sharing [^] contains the following:
- A 23-second video sample that reproduces the issue of my system. It is cut (remux'd) from the original video which itself is downloaded from https://youtu.be/qgSX5X52Cs4 [^] I cut the sample in such a way that the problematic scene is exactly in the middle of the video - specifically, at 00:11. The problematic scene lasts for about 2 seconds.
- The 3DLUT that triggers the issue, generated with ArgyllCMS.
- A madVR debug log that covers one playback session of the aforementioned 23-second sample from beginning to end on my system, with a 3Dlut enabled, reproducing the issue.
I also used GPUView to record a full trace while the sample is playing. The trace can reveal additional information when opened in GPUView or the Windows Performance Analyser. However, for privacy reasons, I will only provide the trace file on direct request from madshi.
|Tags||No tags attached.|
|Media Player (with version info)||MPC-HC 1.7.10|
|Splitter (with version info)||LAV Splitter 0.66.0.0 (MPC-HC built-in)|
|Decoder (with version info)||LAV Video 0.66.0.0 (MPC-HC built-in)|
|DXVA2 Scaling Active||no|
|Aero / Desktop Composition||On|
|Problem occurs with mode||all modes|
|GPU Model||HD Graphics 530 (Core i7 6700HQ)|
|GPU Driver Version||220.127.116.1142|
This has been reported mainly by NVidia users and seems to be less of a problem with AMD users. I think the issue is likely caused by the GPU texture cache failing because the 3DLUT texture is very big, and some rarely used colors might not be in the cache.
One thing you could try is clipping out of gamut colors with a custom pixel shader. E.g. just do a custom MPC-HC shader with "return saturate(tex2D(...))". I've no idea if that will help, but it should at least cut off a part of the 3DLUT area.
Thanks for the suggestion. I've tried the following shader:
sampler s0 : register(s0);
float4 main(float2 tex : TEXCOORD0) : COLOR
return saturate(tex2D(s0, tex));
It doesn't seem to make much of a difference. (I've verified the shader is actually running because it appears in the list of rendering steps.)
|Well, it was just a try. I suppose the only other option would be to create/use smaller sized 3dluts... :-(|
Yep. I think you're right when you say it has to do with the colours of the scene: if I apply the "greyscale" shader that comes with MPC-HC, the problem disappears. Also the "problematic scene" in the sample happens to have lots of highly saturated colours. Here's a screenshot of the scene: http://imgur.com/a/JBAli [^]
Maybe one way to work around the issue could be to split the 3Dlut texture into several smaller textures? (Just a suggestion - I have no idea how GPU programming works)
|No, that wouldn't help. The only solution I can see is either better GPU drivers, more GPU texture cache, or a smaller 3dlut (e.g. 65^3 instead of 255^3).|
i can confirm the problem with that file even on AMD which is way faster than nvidia in my personal experience.
i personally only notice this problem at UHD at 1080p i can't really reproduce this issue what so ever. why is the resolution playing such a big rule for this issue? i don't understand this part.
no chance with openCL or stuff like that?
I don't think OpenCL would make things better. *Maybe* D3D11, but I highly doubt it. I think it's a texture cache issue and the API set probably won't affect that.
The 3dlut is applied at the very last rendering step, so it's not the resolution of the video which should make a difference, but the output resolution, I would expect.
the problem is more about the insane increase in GPU usage at UHD.
if i take a file with the problem i notice nothing at FHD but at UHD the render time easily triple or even more with such a scene.
or with numbers.
FHD final step 0000001:0000002-4 ms
UHD final step 10-250ms
UHD needs 4 x ms of FHD which makes sense but with the problem it is easily 64 times...
|In my report I mentioned FinalStep rendering times of ~25ms during the problematic scene instead of ~7ms otherwise. That's with a 1080p video playing at 1080p on a 1080p display. I think the reason why it's especially noticeable on my system is because of the slow GPU (Intel HD Graphics 530), which exacerbates the problem.|
|2016-12-26 16:50||e-t172||New Issue|
|2016-12-27 11:57||madshi||Note Added: 0001545|
|2016-12-27 13:28||e-t172||Note Added: 0001546|
|2016-12-27 13:38||madshi||Note Added: 0001547|
|2016-12-27 13:56||e-t172||Note Added: 0001548|
|2016-12-27 14:05||madshi||Note Added: 0001549|
|2016-12-31 07:44||huhn||Note Added: 0001561|
|2016-12-31 10:30||madshi||Note Added: 0001562|
|2017-01-02 02:25||huhn||Note Added: 0001563|
|2017-01-02 09:56||e-t172||Note Added: 0001564|
|Copyright © 2000 - 2012 MantisBT Group|