<html>
    <head>
      <base href="https://bugs.freedesktop.org/" />
    </head>
    <body>
      <p>
        <div>
            <b><a class="bz_bug_link 
          bz_status_NEW "
   title="NEW - Tonga UVD not working with GL_NV_vdpau_interop"
   href="https://bugs.freedesktop.org/show_bug.cgi?id=91308#c10">Comment # 10</a>
              on <a class="bz_bug_link 
          bz_status_NEW "
   title="NEW - Tonga UVD not working with GL_NV_vdpau_interop"
   href="https://bugs.freedesktop.org/show_bug.cgi?id=91308">bug 91308</a>
              from <span class="vcard"><a class="email" href="mailto:adf.lists@gmail.com" title="Andy Furniss <adf.lists@gmail.com>"> <span class="fn">Andy Furniss</span></a>
</span></b>
        <pre>I tried reproducing these with agd5f drm/mesa amd-staging and I can reproduce
but I have to try a lot harder, were I not using scripts I would probably call
working.

The vdpau interop fail took about 30 tries with mpv.

After about 60 runs of mpv --vo=vdpau with cpufreq both on_demand and perf I
failed to get a ring 9 lock.

With mplayer I did about 60 with cpufreq perf without a lock, but did get one
after about 50 starts with cpufreq on_demand.

On amdgpu branches I can lock with both in < 10 starts sometimes as low as 3.

Historically I've had uvd issues that I can provoke with mplayer but not mpv -
looking at vdpau traces, I see that mplayer at start up, twice creates and
instantly destroys a decoder with w/h 48 before creating one with the correct
w/h (which depending on content it may then destroy if it needs more ref
frames).

mpv just does one create and uses it, perhaps this is why mplayer can trigger
some issues better.</pre>
        </div>
      </p>
      <hr>
      <span>You are receiving this mail because:</span>
      
      <ul>
          <li>You are the assignee for the bug.</li>
      </ul>
    </body>
</html>