Announcement

Collapse
No announcement yet.

VA-API Support Set To Be Dropped From Mesa

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • #16
    Originally posted by Gusar View Post
    This is pure nonsense. First, the mesa work Intel does (to bring opengl 3.1 and such) benefits *both* kinds of drivers, gallium and classic mesa ones. Gallium doesn't have a whole different opengl stack, as some seem to think.
    You may be correct. but i don't know what doest intel help to bring r600/700 driver to reach opengl 3.1.


    Originally posted by Gusar View Post
    The second question I can't even parse. Are you saying the radeon and nouveau drivers are in the state they are (lack of power management, low performance, no access to hardware decoders) only because Gallium isn't mature or something? And that if Intel had a Gallium driver, the radeon and nouveau drivers would magically become better in this regard? That makes no sense.

    Intel switching to Gallium would change pretty much nothing. That's why they don't do it, it'd be a huge effort for no real gain.

    i am not a mesa expert, but if my understanding about Gallium is correct

    http://en.wikipedia.org/wiki/Gallium...s_from_Mesa_3D

    Gallium backend is shared between different drivers.

    if intel use Gallium, they will need to tune the Gallium backend performance and implement various state tracker (e.g a full functional vaapi/vdpau state tracker).

    But this means that AMD driver will be benefited from these features, too (automatically)

    AMD developers will have more time to tune their driver and it will mature much faster.


    Currently, intel is no match with AMD for display hardware. If their driver are at the same level, AMD kicks intel's ass.
    Last edited by unknown2; 09-08-2012, 07:00 AM.

    Comment


    • #17
      Originally posted by DanL View Post
      Hmm. I thought the tracker would be more generic and have the backend implementation left to the driver.
      A video tracker will be generic and shader based because there is no access to the video decoding HW. If the devs had access to the HW they would just expose the API and call it a day.

      Maybe the generic approach could be used for codecs that are not included in the HW but in any case the HW supports something i see no reason spending time implementing it with shaders.

      Comment


      • #18
        Originally posted by unknown2 View Post
        why mesa developer develop vdpau tracker rather than vaapi?

        is it because that vdpau is a better api than vaapi? (i am not a expert in this area)

        There is a talk about vdpau vs. va-api.
        somewhat outdated (2009), but still informative:
        http://html5tv.rot13.org/lpc2009-Vid...eathmatch.html

        Comment


        • #19
          Originally posted by unknown2 View Post
          You may be correct. but i don't know what doest intel help to bring r600/700 driver to reach opengl 3.1.
          I don't get what you mean here. Why would Intel help r600? They're Intel! They work on mesa core and their own driver. The radeon and nouveau guys benefit from Intel's mesa core work, but they of course need to take care of driver-specific work themselves. This wouldn't change if Intel switched to gallium.

          Originally posted by unknown2 View Post
          if intel use Gallium, they will need to tune the Gallium backend performance and implement various state tracker (e.g a full functional vaapi/vdpau state tracker).
          There already is a VDPAU state tracker and it works. The problem isn't in the tracker, it's accessing hardware decoders, or writing shader-based decoders. If Intel wrote a VA-API state tracker, they'd use it to access their hardware decoder and that's it.

          Originally posted by unknown2 View Post
          But this means that AMD driver will be benefited from these features, too (automatically)
          Incorrect. Intel writing a VA-API state tracker wouldn't magically give you access to AMD's hardware decoders. Neither would it give you a shader-based h264 decoder. AMD would still need to write either of these themselves.

          Originally posted by unknown2 View Post
          Currently, intel is no match with AMD for display hardware. If their driver are at the same level, AMD kicks intel's ass.
          Two things:
          One, AMD already kicks Intel's ass performance-wise if you use fglrx. So if someone needs the performance, they're already not using Intel. They're using AMD or Nvidia and their blobs.
          And two, Intel switching to gallium won't magically make the radeon driver better. To the extent that Intel's work benefits others (the mesa core work), this is already happening! Everything else (access to hardware decoders, power management) is driver-specific, so what framework Intel is using is irrelevant to radeon and nouveau.

          Comment


          • #20
            Originally posted by Gusar View Post
            I don't get what you mean here. Why would Intel help r600? They're Intel! They work on mesa core and their own driver. The radeon and nouveau guys benefit from Intel's mesa core work, but they of course need to take care of driver-specific work themselves. This wouldn't change if Intel switched to gallium.

            There already is a VDPAU state tracker and it works. The problem isn't in the tracker, it's accessing hardware decoders, or writing shader-based decoders. If Intel wrote a VA-API state tracker, they'd use it to access their hardware decoder and that's it.

            Incorrect. Intel writing a VA-API state tracker wouldn't magically give you access to AMD's hardware decoders. Neither would it give you a shader-based h264 decoder. AMD would still need to write either of these themselves.

            Two things:
            One, AMD already kicks Intel's ass performance-wise if you use fglrx. So if someone needs the performance, they're already not using Intel. They're using AMD or Nvidia and their blobs.
            And two, Intel switching to gallium won't magically make the radeon driver better. To the extent that Intel's work benefits others (the mesa core work), this is already happening! Everything else (access to hardware decoders, power management) is driver-specific, so what framework Intel is using is irrelevant to radeon and nouveau.
            I don't want to sound like I'm sticking up (or supporting) Intel here but how is that a fair comparison? Those are apples and oranges. ATI (AMD) and Nvidia are primarily graphics companies. At least, we're looking at them from that perspective. Intel is a processor company that offers a graphics chip on their motherboard. Are they making graphics/video cards now that I'm not aware of? Who cares if the Nvidia and ATI blob drivers are better? At least, Intel accomplishes the open source feat (maybe not great) as I don't read about as many problems as the oss radeon driver. Does the Intel driver for Linux update with X-Server and kernel upgrades (faster than ATI)?

            AMD pretends to offer an open source driver but going by their incomplete radeon driver matrix, I am wondering what mostly works with Intel. If you need a separate graphics card or want one, then Intel isn't even in the equation but that goes without saying.

            Comment


            • #21
              I'm with Panix on this one -- I don't hate on Intel, their video chips are not as quick as ATIs or NVidias, but they don't suck up near the power either. I don't want a 100 watt, 50 watt, or 20 watt... video chip on my motherboard when I'm just doing firefox, eclipse, and video playback.

              Anyway... since Gallium still has VDPAU, I think the loss of VA-API is not a major one. I like the idea of everything going through VA-API from a theoretical standpoint, but from a practical standpoint the software that I have that supports VA-API all supports VDPAU too. *shrug*

              Comment

              Working...
              X