Announcement

Collapse
No announcement yet.

AMD's UVD2-based XvBA Finally Does Something On Linux

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

  • Originally posted by mirv View Post
    fglrx targets a workstation crowd (always has). Their xvba targets embedded systems. Linux support fglrx to the home user has been ramped up, but xvba is still mainly aimed at embedded systems - they're releasing stuff for the home user, but it's not the emphasis for it.
    What the "users" (linux community) jumped up & down about was open source drivers. AMD delivered (more than they originally said too). fglrx drivers have improved drastically, and continue to do so for the average home user (and you can't deny that one) - the updates are incremental, not huge, with the benefit being more frequent updates.
    That's why I'm passing to nVidia next time. I am a general plain desktop user (no workstation, non embedded system)

    Ok , for gaming on windows (dual boot) ATI would be better (performance/price evaluation)... but I cannot live with this state of drivers/support on Linux

    For the casual Linux Desktop user, AMD today *is* the inferior choice, compared to nVidia.

    Comment


    • why is it inferior? I don't miss anything from nvidia. Games work, X is fast (with patched X to reverse the damage), video works well.

      What is 'missing'?

      Btw, reaaaallly smart move supporting a company that does not support open source solutions. Really. *applaud*.

      Comment


      • I need something working!

        Originally posted by energyman View Post
        why is it inferior? I don't miss anything from nvidia. Games work, X is fast (with patched X to reverse the damage), video works well.

        What is 'missing'?

        Btw, reaaaallly smart move supporting a company that does not support open source solutions. Really. *applaud*.
        Apart from publishing some tech docs, does AMD support OSS driver development? Ok better than nVidia, that's why when I was to substitute my 6600GT I chose radeon HD3650. I hoped to enjoy videos through its HDMI exit in few months...
        Well... in the past 18 months my experience was nothing but a pain in the a##

        Drivers are improving... but at a really slow pace (both OSS and Catalyst). Tearfree videos has been annoying me for ages, preventing me from enjoying the exceptional HTPC features my card is capable under windows.

        Plus, I *do* care about 3D, so the OSS driver for me is still unusable on my R6xx card, and I should stick on a blob driver just like nVidia.

        Then, AMD officially states that first they care on workstations, then embedded systems... and at last desktop users.
        So my conclusion is as follows: nVidia at least has always given me a good experience on Linux. nowadays they release drivers that feature working VDPAU and CUDA, OpenCL

        What should I do? fund AMD waiting (and hoping) that they release something WORKING? Well I already did it!!! *applause to me*
        I bougth my 3650 even because of that tech doc disclosure!
        Now, sorry it's time for a change.

        The day I read that AMD drivers have performances AND features comparable to those found in Win/OSX drivers... well I'll come back to AMD.
        As simple as that!

        Comment


        • AMD have released x86 cpu and their own gpu opencl implementations.
          fglrx is aimed primarily at workstations - open source drivers is aimed at home users.
          xvba is aimed at embedded. That doesn't mean other parts aren't aimed at other areas.
          3D driver....slow pace....did you expect it to be done in a couple of weeks?
          AMD are doing more than just releasing docs - they're providing programming examples, and more - but I'll leave our esteemed Mr Bridgman to respond to that one.

          Comment


          • Originally posted by mirv View Post
            AMD have released x86 cpu and their own gpu opencl implementations.
            fglrx is aimed primarily at workstations - open source drivers is aimed at home users.
            xvba is aimed at embedded. That doesn't mean other parts aren't aimed at other areas.
            3D driver....slow pace....did you expect it to be done in a couple of weeks?
            AMD are doing more than just releasing docs - they're providing programming examples, and more - but I'll leave our esteemed Mr Bridgman to respond to that one.
            I really support AMD in its efforts. I even bought one of its cards (and CPU).
            But as you say: they aim at workstation customers. I'm not among them. So I'll choose something that works. 6 months is an acceptable waiting time. not 18 and counting!
            Talking about OSS drivers: if I buy a R8xx HD5xxx card for Christmas... when OSS drivers will work on 3D? 2011? 2012? notice that R5xx drivers (2 generations old) started working seamlessly only last spring.

            Bridgman, mtippet and those who work on AMD linux drivers are really great guys, but I fear they're seriously under-staffed (AMD's fault).
            The guys involved in nouveau and radeonHD are heroes, but under-staffed as well (not even paid!!!)

            So: I repeat.. I need something working, and video has been impossible to enjoy for me for more than one year, and still today has severe problems. If I'm to use my box as an HTPC *TODAY*, sorry the solution is nVidia
            Last edited by TeoLinuX; 17 November 2009, 09:43 AM.

            Comment


            • AMD is pretty small compared to intel. If you look at the relation to its size AMD has a lot of personal working on linux drivers.

              A big problem part of the slow speed wasn't even AMD's 'fault' - waiting for the kernel infrastructure to be in place.

              Comment


              • people did have a rather unrealistic (note: this wasn't their fault, and it sure wasn't AMD's or the driver developers') expectation of when the open source drivers would be "ready". I would hope that people realise that it's not a matter of weeks, or even months, until the OSS drivers are at a level they're expecting (I personally think they've done a ripper of a job so far, but I had different expectations - I thought it would take longer than it has!).

                Comment


                • Originally posted by mirv View Post
                  people did have a rather unrealistic (note: this wasn't their fault, and it sure wasn't AMD's or the driver developers') expectation of when the open source drivers would be "ready". I would hope that people realise that it's not a matter of weeks, or even months, until the OSS drivers are at a level they're expecting (I personally think they've done a ripper of a job so far, but I had different expectations - I thought it would take longer than it has!).
                  To OSS drivers developers I can only say "thank you guys, great job! Hold on!"
                  But, on the other hand... if (as you say) a solution is to be ready in many months not to say 1-2 years... well, considering graphic cards you're talking of a 2-3 generation delay!!!

                  If you're doing retrocomputing, that's good. If you want to re-use that X1600 card... it's ok
                  If you want to be up to date with the features offered with windows/OSX/linux_blobs well, that much time isn't affordable

                  So, if you're a general Linux desktop user that wants at least 75% of performances and features of windows/OSX on a same card, the matter is: who's providing the best blobs?

                  I really dislike nVidia's lack of support to OSS developers. I think intel is giving a great support (let's see if they continue like that with Larrabee!). About AMD: I'm puzzled. They support OSS but I'd like to see them more convinced, maybe putting now and then their hands on the OSS drivers code.
                  That's my personal point of view.

                  Comment


                  • I'm pretty sure AMD do put their hands on the OSS code (someone care to verify that one?) - at the very least, they do show how to do things (code samples for rendering, for example). I know AMD do more, but I can't remember if it was through monetary support, or helping directly with code. I'm not sure what more you'd like from them there....

                    Comment


                    • I thought the thread was about xvba here OSS drivers do not provide any feature yet needed to decode high bitrate h264 or vc1 at all. When only low bitrate files are tested by most people that will not change soon. It is a bit complicated to get high bitrate m2ts on Linux but those need accelleration even with very fast pcs around 3 ghz dual/quad. I don't know why the mplayer multitheaded code does not really help, when a/v sync is lost it is over. Win players are usually much smarter and can resync. You see that with "bad input" m2ts, which show a decode error at some point - mplayer is out of sync when this happens. Basically it could be done much better as timecode is the streams to resync. Then some bad frames would not hurt so badly. Offloading to gpu helps in some cases, but not in all. Also some input files show bad colors with 9-10 driver and i do not know of any other working one. It does help when i know that one dev could play it using the xvba sdk and mplayer pcom output when nobody else can use it. That's maybe fine for oem - but not for standard users. vaapi does not seem to be a bad idea as intel series 4+ can use it at least for mpeg2 and psb even for mpeg4 natively. What really misses is deinterlace, when this would work then vdpau would not be the first choice. As vlc might implement vaapi this should be really added as it does not seem to be possible to offload the decoding and deinterlace later - or maybe there is one trick, don't know. At least now the best driver to test vaapi is NOT using xvba-video - vdpau-video is more advanced - even if both are wrappers.

                      Comment

                      Working...
                      X