New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Problem with vo=gpu-hq on windows #4905

Closed
shinchiro opened this Issue Sep 22, 2017 · 17 comments

Comments

Projects
None yet
6 participants
@shinchiro
Contributor

shinchiro commented Sep 22, 2017

mpv version and platform

52789d6 - Windows 10-x64

Reproduction steps

Play any video with profile=gpu-hq

Actual behavior

There's at least 2 problem:

  1. mpv crashed when taking screenshot with Ctrl+s with gpu-context=angle
  2. gpu-context=win lead to flickering blackout screen when when going fullscreen. Gave this error:
    [vo/gpu/opengl] after creating texture: OpenGL error INVALID_OPERATION.
@haasn

This comment has been minimized.

Member

haasn commented Sep 22, 2017

Does this patch fix ANGLE screenshots?

diff --git a/video/out/opengl/context.c b/video/out/opengl/context.c
index 6c8821f6c7..85be3a0ace 100644
--- a/video/out/opengl/context.c
+++ b/video/out/opengl/context.c
@@ -260,7 +260,7 @@ struct mp_image *ra_gl_ctx_screenshot(struct ra_swapchain *sw)
     // OpenGL FB is also read in flipped order, so we need to flip when the
     // rendering is *not* flipped, which in our case is whenever
     // p->params.flipped is true. I hope that made sense
-    if (p->params.flipped)
+    if (screen && p->params.flipped)
         mp_image_vflip(screen);
 
     return screen;

Also, cc @rossy maybe you should set external_swapchain.screenshot directly to avoid this altogether, instead of using the VOCTRL-based overriding mechanism.

@rossy

This comment has been minimized.

Member

rossy commented Sep 22, 2017

Whoops. I didn't test window screenshots (I didn't really expect the vo_gpu change to affect them.) Ideally ANGLE should use external_swapchain.fns for this, so I'll change it.

That gpu-context=win thing is strange though. I'm pretty sure resizing/fullscreen worked for me, but maybe I should test again.

@haasn

This comment has been minimized.

Member

haasn commented Sep 22, 2017

Is windows the new OS X?

@shinchiro

This comment has been minimized.

Contributor

shinchiro commented Sep 22, 2017

@haasn Yeah, that fixed the crash

@aufkrawall

This comment has been minimized.

aufkrawall commented Sep 22, 2017

Hm, no crash here with profile=gpu-hq + gpu-context=win (edit: ok, got that wrong with the crashing).
However, the window content is flickering a lot during resizing.

Edit: However, after resizing it's working normally, and so does switching to fullscreen.

@rossy

This comment has been minimized.

Member

rossy commented Sep 22, 2017

The screenshot crash is fixed in #4907 when using the DXGI swapchain surface, but it still crashes when using the EGL windowing surface (with --angle-egl-windowing,) so I think @haasn's patch is needed as well.

@haasn haasn closed this in aabe12b Sep 22, 2017

@haasn

This comment has been minimized.

Member

haasn commented Sep 22, 2017

Oh, we should probably keep this issue open for the context=win issue.

@rossy rossy reopened this Sep 22, 2017

@rossy

This comment has been minimized.

Member

rossy commented Sep 22, 2017

@shinchiro Can we have a full log for the gpu-context=win issue? I can't reproduce it on my machine.

@haasn

This comment has been minimized.

Member

haasn commented Sep 22, 2017

An apitrace comparing the call sequence from before vo_gpu would be the most helpful, I feel. We also have this weird regression on OS X.

@shinchiro

This comment has been minimized.

Contributor

shinchiro commented Sep 22, 2017

My bad, this turn out to be issue with my shitty intel driver. The flickering issue already happen before gpu or ra refactor. With my secondary nvidia gpu, no problem happen when going fullscreen with gpu-context=win. I guess problem solved?

@aufkrawall

This comment has been minimized.

aufkrawall commented Sep 22, 2017

A few months back, my experience with Skylake + backend=win was also disastrous, at least regarding performance.

@shinchiro

This comment has been minimized.

Contributor

shinchiro commented Sep 23, 2017

Well, I believe I got that problem after updating through windows update.

Also @rossy , now I got Could not bind API! error with ANGLE. Does this seem weird for you?

[vo/gpu] Probing for best GPU context.
[vo/gpu/opengl] Initializing GPU context 'angle'
[vo/gpu] Using Direct3D 11 feature level 11_0
[vo/gpu] Device: NVIDIA GeForce GT 755M
[vo/gpu] VendorId: 0x4318
[vo/gpu] DeviceId: 0x4045
[vo/gpu] LUID: 00000000000185ca
[vo/gpu/opengl] EGL_VERSION=1.4 (ANGLE 2.1.0.f32cd0b789b7)
[vo/gpu/opengl] EGL_VENDOR=Google Inc. (adapter LUID: 00000000000185ca)
[vo/gpu/opengl] EGL_CLIENT_APIS=OpenGL_ES
[vo/gpu/opengl] Trying to create Desktop OpenGL context.
[vo/gpu/opengl] Could not bind API!
[vo/gpu/opengl] Trying to create GLES 3.x context.
@rossy

This comment has been minimized.

Member

rossy commented Sep 23, 2017

Yeah, I think this is normal, or at least not a problem. It seems like mpv uses ANGLE's EGL APIs to try to create a desktop OpenGL context (which will never work,) then it falls back to OpenGL ES 3.0, which is correct.

@aufkrawall

This comment has been minimized.

aufkrawall commented Sep 23, 2017

So mpv always uses OGL ES with angle? Might that explain why it gives me higher GPU usage than win or dxinterop with Nvidia?

@Hrxn

This comment has been minimized.

Hrxn commented Sep 23, 2017

Why mpv? Doesn't ANGLE always use OpenGL ES, because it does not support anything else?
And I think that differences in GPU usage don't stem from Desktop GL vs ES GL etc., it's just that ANGLE is an intermediate step, basically, as an interface/translation layer between APIs.

@aufkrawall

This comment has been minimized.

aufkrawall commented Sep 23, 2017

You are apparently right regarding GL ES, so that answers my first question. ;)
The difference in GPU load between angle and the rest is quite notable when heavy stuff going on like deband for 4k 60fps, ewa deringing filter etc.

@kevmitch kevmitch added the intel-bug label Dec 9, 2017

@kevmitch

This comment has been minimized.

Member

kevmitch commented Dec 9, 2017

To summarize, this has remained opened because gpu-context=win on Intel drivers is non-fatally crappy. There's a weird [vo/gpu/opengl] after creating texture: OpenGL error INVALID_OPERATION. message after flipping through full screen and things can look a little "flickery".

On Win7 Haswell, I barely notice it, but it's definitely worse than gpu-context=angle. Occasionally, on toggling fullscreen, my TV will blink and show the input frame rate (which usually only happens when you change it even though in this case it hasn't changed).

However, unless somebody can come up with a compelling reason why we should care about gpu-context=win not working perfectly when we now have lots of better options I'm closing this.

@kevmitch kevmitch closed this Dec 9, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment