Page 1 of 2 12 LastLast
Results 1 to 10 of 13

Thread: XvMC Support Now Disabled By Default In Mesa

  1. #1
    Join Date
    Jan 2007
    Posts
    14,344

    Default XvMC Support Now Disabled By Default In Mesa

    Phoronix: XvMC Support Now Disabled By Default In Mesa

    For those that haven't jumped onto the VDPAU state tracker bandwagon with the Gallium3D graphics drivers but are reliant upon the XvMC state tracker, your days may be limited. While the XvMC support code is still found within Mesa, it's now disabled by default...

    http://www.phoronix.com/vr.php?view=MTU3MDM

  2. #2
    Join Date
    Jan 2011
    Posts
    1,287

    Default

    I won't argue the decision, as it's true that it's not used that much nowadays (at least not in currently supported drivers, anyway), but the motivation seems counter intuitive, I mean, unit tests fail, so instead of fixing whatever makes them fail, they disabled the build on the default configuration. The only way that reasoning makes sense to me is if the idea is to point out "well, this is in no conditions for production use, use it at your own risk", but nothing else.

  3. #3
    Join Date
    Aug 2012
    Location
    Pennsylvania, United States
    Posts
    1,860

    Default

    Quote Originally Posted by mrugiero View Post
    I won't argue the decision, as it's true that it's not used that much nowadays (at least not in currently supported drivers, anyway), but the motivation seems counter intuitive, I mean, unit tests fail, so instead of fixing whatever makes them fail, they disabled the build on the default configuration. The only way that reasoning makes sense to me is if the idea is to point out "well, this is in no conditions for production use, use it at your own risk", but nothing else.
    Preeeeeeeeeeeeetty much. I think this was mostly a "We finally have excuse to kill this" move. Checking out Arch's wiki page for XVMC I see the following faults in XVMC:

    1) Support -- Only Mplayer and Xine have any sort of support for XVMC. (Just checked VLC, it only supports XVideo, not sure if thats newer or older than XVMC though)

    2) Targets -- You're only guaranteed acceleration for MPEG-1 and MPEG-2, anything else will probably fail and get shoved to the CPU anyway

    3) Obsolete-ness -- Anything that you really want to bother doing acceleration on is probably support by VA-API, VDPAU, or at worst XvBA.

    And thats only looking at a very high level view of the project as a whole. Who knows the last time it was properly tested in a RUNNING environment, when it was last maintained, if it HAS a maintainer, or when the last bug fix was for anything beyond "It doesnt compile against XYZ release of ABC project."

  4. #4
    Join Date
    Jan 2011
    Posts
    1,287

    Default

    Quote Originally Posted by Ericg View Post
    it only supports XVideo, not sure if thats newer or older than XVMC though
    IIRC, XVideo accelerates even less of the process, doing only the scaling, and it's older. Maybe I remember it wrong, although checking it is fairly trivial, the specs for those extensions are in FDO, IIRC.

  5. #5
    Join Date
    May 2012
    Posts
    762

    Default

    Any patch that kills any of those old shitty alternatives to VA-API and VDPAU are A GOOD THING (TM) (C).

  6. #6
    Join Date
    Aug 2013
    Posts
    26

    Default

    Quote Originally Posted by Ericg View Post
    Who knows the last time it was properly tested in a RUNNING environment, when it was last maintained, if it HAS a maintainer, or when the last bug fix was for anything beyond "It doesnt compile against XYZ release of ABC project."
    Works great with nouveau on NV40-NV96 cards (PMPEG and VP2 engines), better than VDPAU does for MPEG1/2's. Neither of these decoding engines don't have support for bitstream-level MPEG1/2 acceleration, which means that the mesa VDPAU impl has to do the decode in software (and it can't use libmpeg2 due to license incompatibility, so it's reimplemented). And not that much attention is given to it, compared to, say, mplayer. At present, it's buggy and slow.

    In a perfect world, there would be a VA-API state tracker which enables exposing acceleration levels (so you could say IDCT-only vs full-stream), but until that happens, XvMC is superior for supporting that sort of older hardware. [Apparently there was a vaapi state tracker at one point, but it was removed, presumably due to disrepair.]

  7. #7
    Join Date
    Jan 2013
    Posts
    1,116

    Default

    Can somebody explain to me if this is relevant for owners of hardware that just can't use the "well supported VDPAU", for example with RS780/880 or RV790? And if it is relevant, what are the implications of this?

  8. #8
    Join Date
    Dec 2009
    Location
    Greece
    Posts
    351

    Default

    Quote Originally Posted by Vim_User View Post
    Can somebody explain to me if this is relevant for owners of hardware that just can't use the "well supported VDPAU", for example with RS780/880 or RV790? And if it is relevant, what are the implications of this?
    Modern cpus(decade old) don't need hardware accel. for mpeg1/2... They are quite powerful...

  9. #9
    Join Date
    Sep 2008
    Location
    Vilnius, Lithuania
    Posts
    2,521

    Default

    I always use either VDPAU or OpenGL for video rendering. VDPAU for the things it supports (a fairly limited set of codecs) and OpenGL for correct rendering (no other output device I tried could play 4:4:4 chroma subsampling videos correctly, they all would recode it to 4:2:0 or such).

  10. #10
    Join Date
    Nov 2008
    Posts
    762

    Default

    Quote Originally Posted by mrugiero View Post
    I mean, unit tests fail, so instead of fixing whatever makes them fail, they disabled the build on the default configuration. The only way that reasoning makes sense to me is if the idea is to point out "well, this is in no conditions for production use, use it at your own risk", but nothing else.
    The issue is not that unit tests fail, the issue is that nobody is maintaining it and it starts to bitrot.

    Now you're saying that "they" should just keep maintaining it, but how do you enforce something like that in a community project? No volunteer cares enough about the feature to maintain it, no company cares about the feature enough to pay someone to maintain it.. and in fact, most people aren't even using it. What now?


    Unless someone steps forward to maintain it, the only way to go is to disable it by default. If it deteriorates further, remove it.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •