<div dir="ltr">Hi Christian,<div><br></div><div>I am more than happy to solve these problems, the Lanczos filtering was getting a little stale </div><div>anyway because I was not able to reproduce the problems Andy was facing. </div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Aug 8, 2016 at 6:24 PM, Christian König <span dir="ltr"><<a href="mailto:christian.koenig@amd.com" target="_blank">christian.koenig@amd.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  
    
  
  <div text="#000000" bgcolor="#FFFFFF">
    <div>Hi Nayan,<br>
      <br>
      ok let's take a step back and put the lanczos filtering aside for
      a moment. I have another task for you which is more urgent right
      now.<br>
      <br>
      The order we do things in vlVdpVideoMixerRender() was never 100%
      correct, so we have at least three problems here which needs
      fixing:<br>
      <br>
      1) The noise reduction and sharpness filter read and write to the
      same surface at the same time. That only works because we use a
      linear layout.<br>
      <br></div></div></blockquote><div>Is that why I need to add a PIPE_BIND_LINEAR to a surface? So I need to use maybe a couple of surfaces alternatively to read and write with the filters. This approach should work I guess.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div text="#000000" bgcolor="#FFFFFF"><div>
      2) We apply the noise reduction and sharpness filter after the
      composition. That is rather odd and should be fixed so that we
      apply those filters on the original video frame instead.<br>
      <br></div></div></blockquote><div> So we need to apply the filter before the CSC conversion.</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div text="#000000" bgcolor="#FFFFFF"><div>
      3) We use delayed rendering to render into output surfaces
      directly. We should rather use the DRI3 capabilities to allocate
      multiple output surfaces instead.<br>
      <br></div></div></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div text="#000000" bgcolor="#FFFFFF"><div>Could you take care of some of those issues? Especially #1 has
      become a problem recently.<br>
      <br></div></div></blockquote><div>Surely, I will start working on the first 2 problem for now and look at the third problem a little later. </div><div><br></div><div>Regards,</div><div>Nayan.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div text="#000000" bgcolor="#FFFFFF"><div>
      Regards,<br>
      Christian.<div><div><br>
      <br>
      Am 04.08.2016 um 19:22 schrieb Nayan Deshmukh:<br>
    </div></div></div><div><div>
    <blockquote type="cite">
      
      <div dir="ltr">Hi Andy,
        <div><br>
        </div>
        <div class="gmail_extra"><br>
          <div class="gmail_quote">On Thu, Aug 4, 2016 at 8:48 PM, Andy
            Furniss <span dir="ltr"><<a href="mailto:adf.lists@gmail.com" target="_blank">adf.lists@gmail.com</a>></span>
            wrote:<br>
            <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>Nayan
                Deshmukh wrote:<br>
                <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
                  Hi Andy,<br>
                  <br>
                  Thanks for testing my patches.<br>
                </blockquote>
                <br>
              </span>
              NP<span><br>
                <br>
                <br>
                <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
                  <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
                    The scaling happens after CSC.<br>
                  </blockquote>
                </blockquote>
                <br>
              </span>
              OK, thanks.<span><br>
                <br>
                <br>
                <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
                  I believe there is some misunderstanding here, I was
                  able to see the<br>
                  artifacts in the video that you sent me previously.
                  But I was not<br>
                  able to replicate them<br>
                </blockquote>
                <br>
              </span>
              Yea, I got that - just thought you may want to see how
              they had changed.<span><br>
                <br>
                <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
                  with the pendulum video on my system. Same case this
                  time the<br>
                  pendulum video plays fine this time too. I am attacing
                  a video of it<br>
                  here<br>
                  <br>
                  <a href="https://drive.google.com/file/d/0B1s62k5GtdBwOVAtOUVaU0V5c1E/view?usp=sharing" rel="noreferrer" target="_blank">https://drive.google.com/file/<wbr>d/0B1s62k5GtdBwOVAtOUVaU0V5c1E<wbr>/view?usp=sharing</a><br>
                </blockquote>
                <br>
              </span>
              Hmm, that's interesting for a few reasons.<br>
              <br>
              Though my monitor won't do 1366x768 I can replicate the
              same scale<br>
              factor windowed with mplayer ... -xy 768/576 ...<br>
              <br>
              At first glance only level 2 is obviously artifacted
              (though very close<br>
              inspection shows others are slightly).<br>
              <br>
              Levels: for some reason your vid has the black bars at 0
              but the content<br>
              isn't scaled - like your mplayer didn't expand tv to pc on
              playback.<br>
              This shouldn't happen by default. Do you have some extra
              config<br>
              somewhere like in $HOME/.mplayer, if so maybe better to
              test without.<br>
              <br>
              Most important - though the vp9 compression may be to
              blame I can't<br>
              really see any difference between the levels in that vid.<br>
              <br>
              In fact closely comparing just your level 1 to my
              (admittedly<br>
              uncompressed) level 1 and 0 output scaled the same plus
              unstretched<br>
              levels wise it looks to me like you are getting level 0 on
              this test.<br>
            </blockquote>
          </div>
          <br>
        </div>
        <div class="gmail_extra">You are right it I am getting level 0
          only. I have a PRIME configuration</div>
        <div class="gmail_extra">and I forgot to set DRI_PRIME to 1. But
          for some reason, I am not able to create</div>
        <div class="gmail_extra">a screen recording when I use my AMD
          card. So, for now, I can't reproduce the artifacts </div>
        <div class="gmail_extra">you are having so can't debug them too
          :( </div>
        <div class="gmail_extra"><br>
        </div>
        <div class="gmail_extra">Regards,</div>
        <div class="gmail_extra">Nayan.</div>
      </div>
    </blockquote>
    <p><br>
    </p>
  </div></div></div>

</blockquote></div><br></div></div>