<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 16 September 2016 at 08:43, Christian König <span dir="ltr"><<a target="_blank" href="mailto:deathsimple@vodafone.de">deathsimple@vodafone.de</a>></span> wrote:<br><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">
  
    
  
  <div bgcolor="#FFFFFF"><span class="gmail-">
    <div>Am 15.09.2016 um 23:07 schrieb Julien
      Isorce:<br>
    </div>
    <blockquote type="cite">
      <div dir="ltr"><br>
        <div class="gmail_extra"><br>
          <div class="gmail_quote">On 15 September 2016 at 16:02, Leo
            Liu <span dir="ltr"><<a target="_blank" href="mailto:leo.liu@amd.com">leo.liu@amd.com</a>></span>
            wrote:<br>
            <blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote"><span><br>
                <br>
                On 09/15/2016 10:43 AM, Andy Furniss wrote:<br>
                <blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">
                  Since bf901a2<br>
                  st/va: also honors interlaced preference when
                  providing a video format<br>
                  existing scripts and most use cases will need true.<br>
                  <br>
                  Signed-off-by: Andy Furniss <<a target="_blank" href="mailto:adf.lists@gmail.com">adf.lists@gmail.com</a>><br>
                  ---<br>
                   src/gallium/state_trackers/va<wbr>/surface.c | 2 +-<br>
                   1 file changed, 1 insertion(+), 1 deletion(-)<br>
                  <br>
                  diff --git a/src/gallium/state_trackers/v<wbr>a/surface.c
                  b/src/gallium/state_trackers/v<wbr>a/surface.c<br>
                  index 00df69d..e73e17e 100644<br>
                  --- a/src/gallium/state_trackers/v<wbr>a/surface.c<br>
                  +++ b/src/gallium/state_trackers/v<wbr>a/surface.c<br>
                  @@ -43,7 +43,7 @@<br>
                  <br>
                   #include "va_private.h"<br>
                  <br>
                  -DEBUG_GET_ONCE_BOOL_OPTION(no<wbr>interlace,
                  "VAAPI_DISABLE_INTERLACE", FALSE);<br>
                  +DEBUG_GET_ONCE_BOOL_OPTION(no<wbr>interlace,
                  "VAAPI_DISABLE_INTERLACE", TRUE);<br>
                </blockquote>
                <br>
              </span>
              Like being mentioned,  It'll still override the preferred
              interlaced format when this env is not explicitly used.<br>
              <br>
              Not sure this will be okay with other case. @Julien?<br>
            </blockquote>
            <div><br>
            </div>
            <div>Hi,<br>
              <br>
            </div>
            <div>So the problem is that with radeon,
              PIPE_VIDEO_CAP_SUPPORTS_<wbr>INTERLACED always returns false
              for encoding<br>
            </div>
            <div>but can return true for decoding (depending on the
              chipset and the codec). Then when doing transcoding you
              need all to be non interlaced to avoid extra
              copy/conversion and even a clash. Is it correct ?<br>
            </div>
          </div>
        </div>
      </div>
    </blockquote>
    <br></span>
    Yes correct. The decoder supports both interlaced as well as
    progressive memory layout, but the encoder can only handle
    progressive input.<br>
    <br>
    Interlaced memory layout is needed for things like adaptive
    deinterlacing as well as VDPAU OpenGL interop.<span class="gmail-"></span></div></blockquote><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote"><div bgcolor="#FFFFFF"><span class="gmail-"><blockquote type="cite">
      <div dir="ltr">
        <div class="gmail_extra">
          <div class="gmail_quote">
            <div><br>
            </div>
            <div>Should debug_get_option_nointerlace() be moved to
              radeon_video.c::rvid_get_<wbr>video_param ?<br>
            </div>
          </div>
        </div>
      </div>
    </blockquote>
    <br></span>
    For the short term that sounds like a good idea to me.<br></div></blockquote><div> </div><div><br></div><div>Hi @<span class="gmail-"><span>Andy, could you update your patch to move that debug env flag to radeon ?  Thx<br><br><br></span></span> </div><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote"><div>
    <br>
    In the mid term we need to better handle this case. E.g. allocate
    the video buffer with the layout the driver reports as preferred, if
    that doesn't match the use case (transcoding, deinterlacing or
    interop) convert as needed.<span class="gmail-"><br></span></div></blockquote><div><br></div><div>yes, also if the conversion is done in HW that should still acceptable.<br></div><div>But also it should be a way to configure that from gstreamer-vaapi/libva using VA_SURFACE_ATTRIB_USAGE_HINT_ENCODER / VA_SURFACE_ATTRIB_USAGE_HINT_VPP_READ maybe ... and catch this flag in vlVaCreateSurfaces2.<br></div><div> </div><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote"><div><span class="gmail-">
    <br>
    <blockquote type="cite">
      <div dir="ltr">
        <div class="gmail_extra">
          <div class="gmail_quote">
            <div><br>
            </div>
            <div>Other question:<br>
              <br>
                  case PIPE_VIDEO_CAP_SUPPORTS_<wbr>INTERLACED:<br>
                      if (rscreen->family < CHIP_PALM) {<br>
                          /* MPEG2 only with shaders and no support for<br>
                             interlacing on R6xx style UVD */<br>
                          return codec != PIPE_VIDEO_FORMAT_MPEG12
              &&<br>
                                 rscreen->family > CHIP_RV770;<br>
                      } else {<br>
                          if (u_reduce_video_profile(<wbr>profile) ==
              PIPE_VIDEO_FORMAT_HEVC)<br>
                              return false; //The firmware doesn't
              support interlaced HEVC.<br>
                          return true;<br>
                      }<br>
            </div>
            <div>So if instead it would always return false then it will
              really work on hardware for which above code says true ?<br>
            </div>
          </div>
        </div>
      </div>
    </blockquote>
    <br></span>
    It would work, but the deinterlacing and interop use case I noted
    above would break.<span class="gmail-"></span><br> </div></blockquote><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote"><div bgcolor="#FFFFFF"><span class="gmail-">
    <br>
    <blockquote type="cite">
      <div dir="ltr">
        <div class="gmail_extra">
          <div class="gmail_quote">
            <div>Because my understanding is that for nvidia hardware
              this is not a preference but rather a requirement but I
              might be wrong.<br>
            </div>
          </div>
        </div>
      </div>
    </blockquote>
    <br></span>
    Yes, as far as I know that is correct. AMD hardware can handle both
    for most hardware/profile combinations, even the HEVC limit only
    applies to a certain firmware version IIRC.<span class="gmail-"><br>
    <br>
    <blockquote type="cite">
      <div dir="ltr">
        <div class="gmail_extra">
          <div class="gmail_quote">
            <div><br>
            </div>
            <div>In any case, with current upstream code and <span>VAAPI_DISABLE_INTERLACE=1 it hits "</span>assert(templat->interlaced);"
              in nouveau_vp3_video_buffer_<wbr>create. If I remove the asset
              it crashes and can even stall the driver (just wanted to
              check ).<br>
              <br>
            </div>
          </div>
        </div>
      </div>
    </blockquote>
    <br></span>
    Crap, feel free to revert the patch setting it to true by default.<br></div></blockquote><div><br></div><div>It has not been pushed: <a href="https://cgit.freedesktop.org/mesa/mesa/log/src/gallium/state_trackers/va">https://cgit.freedesktop.org/mesa/mesa/log/src/gallium/state_trackers/va</a><br>so still time for @Andy to update his patch.<br><br><br></div><div>Cheers<br></div><div>Julien<br></div><div><br></div><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote"><div bgcolor="#FFFFFF">
    <br>
    Regards,<br>
    Christian.<br>
    <br>
    <blockquote type="cite"><span class="gmail-">
      <div dir="ltr">
        <div class="gmail_extra">
          <div class="gmail_quote">
            <div>Cheers<br>
            </div>
            <div>Julien<br>
            </div>
            <div><br>
            </div>
            <blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">
              <br>
              Regards,<br>
              Leo<br>
              <br>
              <blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">
                <br>
                 #include <va/va_drmcommon.h><br>
                <br>
              </blockquote>
              <br>
            </blockquote>
          </div>
          <br>
        </div>
      </div>
      <br>
      <fieldset></fieldset>
      <br>
      </span><span class="gmail-"><pre>______________________________<wbr>_________________
mesa-dev mailing list
<a target="_blank" href="mailto:mesa-dev@lists.freedesktop.org">mesa-dev@lists.freedesktop.org</a>
<a target="_blank" href="https://lists.freedesktop.org/mailman/listinfo/mesa-dev">https://lists.freedesktop.org/<wbr>mailman/listinfo/mesa-dev</a>
</pre>
    </span></blockquote>
    <p><br>
    </p>
  </div>

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