Announcement

Collapse
No announcement yet.

VA-API Support Set To Be Dropped From Mesa

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

  • hwertz
    replied
    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*

    Leave a comment:


  • Panix
    replied
    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.

    Leave a comment:


  • Gusar
    replied
    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.

    Leave a comment:


  • orome
    replied
    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:

    Leave a comment:


  • 89c51
    replied
    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.

    Leave a comment:


  • unknown2
    replied
    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



    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; 08 September 2012, 07:00 AM.

    Leave a comment:


  • brent
    replied
    Originally posted by markg85 View Post
    That would be a shame.. I consider va-api the vendor neutral api that should be used by all other vendors to expose there video decoding stuff.
    VA-API is about as vendor neutral as VDPAU.

    Leave a comment:


  • Gusar
    replied
    Originally posted by gururise View Post
    Its too bad. Wish someone could patch this up into working condition, maybe then r600 users would have some nice VA-API.
    r600 has the VDPAU state tracker, why would you additionally want VA-API? The problem is not in the api, it's writing a shader based h264 decoder. Right now the only shader based decoder in Gallium is mpeg2. This wouldn't suddenly change if someone updated the VA-API state tracker.



    Originally posted by unknown2 View Post
    why would they develop a good shareable graphic framework that benefit their rivals directly?
    if Gallium3D is stable, mature and fast, who will buy intel?
    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.

    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.

    Leave a comment:


  • unknown2
    replied
    Originally posted by 89c51 View Post
    As far as i understand it this has nothing to do with Intel. Intel uses their HW and this is a shader based implementation. So if intel was on G3D they would just plug their HW in the tracker (or whatever fits technically) and would not even bother with shaders.
    it is normal that intel do not use Gallium3D

    why would they develop a good shareable graphic framework that benefit their rivals directly?
    if Gallium3D is stable, mature and fast, who will buy intel?

    they will develop a working driver for their flagships NOW, using the old mesa infrastructure (quick, easy and dirty)

    After a few years later, who will maintain the unmaintainable driver => let other open source enthusiast do it, developer will surely "enjoy" maintaining two different driver structure
    Last edited by unknown2; 08 September 2012, 12:11 AM.

    Leave a comment:


  • unknown2
    replied
    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)

    Leave a comment:

Working...
X