Page 8 of 10 FirstFirst ... 678910 LastLast
Results 71 to 80 of 92

Thread: A few questions about video decode acceleration

  1. #71
    Join Date
    Jul 2007
    Posts
    100

    Default

    Good *GOD* what a rush.

    Open source driver implementing MPEG2 and h264 acceleration?

    This is why I now buy AMD and ATI products instead of Intel and nVidia.
    OK, I know, Intel are doing it to. But they're expensive! ^.^
    Even if it doesn't happen with UVD2.
    SO EXCITED!!! 8D 8D 8D

    J1M.

  2. #72
    Join Date
    Nov 2007
    Posts
    67

    Default

    > Good *GOD* what a rush.
    >
    > Open source driver implementing MPEG2 and h264 acceleration?

    Huh? I can't find an announcement anywhere.

    Great news if it is true.

  3. #73
    Join Date
    Feb 2008
    Location
    Linuxland
    Posts
    4,973

    Default

    The gallium frontend to XvMC, I guess

  4. #74
    Join Date
    Jul 2007
    Posts
    100

    Default

    Quote Originally Posted by Dieter View Post
    > Good *GOD* what a rush.
    >
    > Open source driver implementing MPEG2 and h264 acceleration?

    Huh? I can't find an announcement anywhere.

    Great news if it is true.
    Sorry, I meant the *idea* of it.
    And even if it's not been announced, it's been talked about by the right people in the positive.
    I've always been planning to get a 780g/4850e machine for the living room (mythtv) but I'm going to BOUNCE UP AND DOWN ON MY SOFA HOPING FOR UVD2 SUPPORT!!! *D

    We're no longer standing still or moving in the wrong direction.
    For so long it's all been held back by companies keeping the specs for their hardware closed.
    Now, hopefully, with a few shining examples of how it's good PR and makes financial sense, everybody else will follow suit.

    'lest they fall behind with a Mineshaft Gap.

    And even if it never comes to pass, ATI are aiming for feature parity with Windows with fglrx, yes? Doesn't that mean UVD? Right? DRM? (As in digital rights, not the other DRM)

    I'm just sitting here hoping and being excited about all this.
    Probably too excited but I just don't care.

    J1M.

  5. #75
    Join Date
    Nov 2007
    Posts
    67

    Default

    > The gallium frontend to XvMC, I guess

    Assuming the SoC project goes well.

    But... then we need gallium for ATI. Is anyone working on that?

  6. #76
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,383

    Default

    Two parts to the answer :

    1. There are some pre-requisites which need to be at least partially in place for Gallium. A modern memory manager in drm is the first priority (Dave Airlie is working on that) and I believe DRI2 will be needed as well -- and DRI2 also needs the new memory manager.

    2. In terms of development priorities, we are aiming to get at least basic 3d functionality running on "classic mesa" before beginning implementation on Gallium, so that developers are only faced with the challenge of learning the chips and not learning a new environment & API at the same time. This definitely made sense for 5xx but 6xx/7xx will probably be the last generation where we get things running on "classic Mesa" before Gallium.

    Documentation and community knowledge for 5xx and earlier is good enough to support Gallium work today; glisse did some preliminary work a few months back, and MostAwesomeDude is eyeing Gallium now. I expect that work on both DRI2 and Gallium will ramp up over the next month or so as (a) we make more progress on 6xx/7xx 3d and (b) Dave's work on a new memory manager gets a bit further along.

    Memory manager => DRI2 => Gallium

    Memory Manager => Kernel Modesetting

    Work on the above initiatives can start in parallel to a certain extent, but they really need to "come up" in the order above and certainly need to finish in the order above.

    So... real soon now

  7. #77
    Join Date
    Jun 2006
    Posts
    311

    Default

    Quote Originally Posted by TechMage89 View Post
    Windows drivers are kind of messy because a large amount of the code goes in-kernel. Hopefully, Windows 7 should fix that, but you have to expect that the Windows graphical system will be less stable than the Linux graphical system.
    Do you think that the move to Kernel Modesetting is going to lighten the load on the Linux kernel? We are actively pushing more into the kernel while Windows is trying to pull things out. There are religious wars over drivers in userland/kernel so let's avoid it here....

    When kernel modesetting kicks in, the X developers, FB developers and other random display developers are all going to have to find a way to support the same OSS driver. If we end up with 3 kernel based graphics drivers, then I don't believe we have improved the situation.

    Regards,

    Matthew

  8. #78
    Join Date
    Jun 2006
    Posts
    311

    Wink

    Quote Originally Posted by chaos386 View Post
    This may be coming a little out of left field here, but what about using CAL/GPGPU? Would it be a reasonable way to avoid the legal issues surrounding the UVD, or would it be so much slower that it wouldn't be worth the effort?

    In any case, using the GPU to accelerate video encoding would be a dream come true, and if that gets done, how much more work would decoding be?
    Video encoding is probably best suited to OpenCL (I will use that term instead of CAL/OpenCL/CUDA/Shader/whatever), since in general that is done away from the consumers desktop.

    The OpenCL based solutions scale their performance with the number of shader cores that are available. This means the effectiveness will scale with hardware.

    The Proprietary driver has used shader based video (only colorspace conversion/attributes) since R5xx, and shader based 2D since R6xx, and has some people have been playing with RENDER acceleration (TexturedVideo, Textured2D and TexturedXRender). It does work, but it does present a number of technical issues that need to be resolved, and realistically we focus a lot more on 2D acceleration than video.

    I am absolutely in support of the GP-GPU approaches to computing problems (including xvmc/h264 decode), but just be aware that the performance of those solutions will scale with hardware.

    Regards,

    Matthew
    Last edited by mtippett; 07-16-2008 at 03:38 PM.

  9. #79
    Join Date
    May 2007
    Posts
    230

    Default

    Quote Originally Posted by mtippett View Post
    The Proprietary driver has used shader based video (only colorspace conversion/attributes) since R5xx, and shader based 2D since R6xx, and has some people have been playing with RENDER acceleration (TexturedVideo, Textured2D and TexturedXRender). It does work, but it does present a number of technical issues that need to be resolved, and realistically we focus a lot more on 2D acceleration than video.

    This is exactly why UVD hardware was created. It is dedicated hardware that is consistent across all market segments and is built to do only video decode.
    This why there are discussion (i think i heard things ) about adding special infrastructure in pipe to be able to take advantage of such hw instead of trying to do it in shader. I am convinced that for decode gpu is not the best solution, dedicated hw is. Shader will be the default safe path, i think...

  10. #80

    Default

    Quote Originally Posted by glisse View Post
    This why there are discussion (i think i heard things ) about adding special infrastructure in pipe to be able to take advantage of such hw instead of trying to do it in shader. I am convinced that for decode gpu is not the best solution, dedicated hw is. Shader will be the default safe path, i think...
    But what good does that do when the HW makers' contract terms with the "content protection" cartels and with Microsoft apparently explicitly forbid them from enabling their video-dedicated hardware to be used with free software?

    (And has anyone discussed the antitrust implications of Microsoft and the HW makers signing secret agreements that say certain HW functionality shall be off-limits to Microsoft's chief competitors?)

Posting Permissions

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