Announcement

Collapse
No announcement yet.

NVIDIA Releases Standalone VDPAU Library

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

  • bridgman
    replied
    I think you can take it for granted that video acceleration is coming to open source drivers. While we're not sure yet about UVD, there is already work being done on a shader-based acceleration stack. Cooper will be including ymanton's XvMC-over-Gallium3D code as one of the test cases for the 300g Gallium3D driver, and zrusin is planning to integrate that XvMC code into the xorg state tracker as well. Once XvMC is working all the key bits of plumbing will be there and adding support for additional video standards (or APIs) will not require much in the way of hardware-specific knowledge.

    Even moving MC (the largest consumer of CPU cycles) from CPU to GPU is likely to save enough CPU cycles that one CPU core will be enough for most users.

    Hey, wasn't this thread supposed to be about the new VDPAU wrapper library ?
    Last edited by bridgman; 18 September 2009, 12:18 PM.

    Leave a comment:


  • lbcoder
    replied
    Originally posted by myxal View Post
    I'd say video acceleration for R600/R700 is simply not coming to opensource drivers (not from official sources), we might see it in fglrx if we're lucky.
    I don't believe that that is an entirely accurate statement. There are different levels of video acceleration... the difference is in how much of the decode process is accelerated. Right now we DO have acceleration -- though only very basic Xv. Playing a full-HD video right now *does* peg any CPU that isn't at least a fairly recent 2-core or better. Offloading a -- lets call it a -- "significant chunk" over to the GPU (even without using the video decoder junk in the GPU) will take a significant chunk of the processing off the CPU to hopefully make HD playback stable on even older 2-core processors (maybe even 1-core's).

    Now the question you need to ask yourself is this: how much acceleration do you really need? My "tv computer" is an older X2-3800 that I recently picked up for free + an RHD3650 ($40). HD video playback goes like this;
    720P single threaded: fairly OK with the occasional chop. Very watchable.
    720P multi-threaded: perfect.
    1080P single threaded: unwatchable, drops about 50%.
    1080P multi-threaded: fairly OK with the occasional chop. About the same as 720P single threaded.

    So how much acceleration do *I* need on this "$40" computer to make 1080P perfect? The answer is *not much*. And that's on old junk.

    Here's what bridgman has to say about video decode acceleration:
    Technical support and discussion of the open-source AMD Radeon graphics drivers.

    Leave a comment:


  • m4rgin4l
    replied
    Originally posted by myxal View Post
    I'd say video acceleration for R600/R700 is simply not coming to opensource drivers (not from official sources), we might see it in fglrx if we're lucky.
    It's a damn shame.

    Originally posted by myxal View Post
    Such is the sorry state of linux graphics - my choices are intel (drivers in quantum state, getting all the features to work with adequate performance is next to impossible for a casual Linux user), AMD (no opensource 3D for cards less than 4 years old, proprietary driver has problems with some basic functionality (Xv) and switching between computer power modes), nvidia (no opensource driver worth using yet, proprietary driver mostly works, but lacks some common features (XR&R1.2), and there's always the creeping shadow of nvidia's 'Bumpgate'). Other graphics vendors have no drivers/hardware worth using.
    That sounds about right. I wish someone would write an article (HEY PHORONIX, I'M TALKING TO YOU! on the lines of "The Sorry State of Sound on Linux". At least no one has figured out a way to integrate PulseAudio into the X stack to mess things up

    Leave a comment:


  • pingufunkybeat
    replied
    I run open drivers on my rv710 at home (chipset released this year, I believe), play OpenArena and neverball for hours on end, and have all the 3d effects in KWin enabled, and I have no issues right now. So for me, it's both useful and stable, although it won't reach feature parity with fglrx for quite a while.

    I'm sure that experiences will differ, though, as the rate of development is really fast. But I disagree that there is no OSS 3D for any card less than 4 years old.

    The AMD/XOrg devs have been doing great work recently.

    Leave a comment:


  • m4rgin4l
    replied
    Originally posted by pingufunkybeat View Post
    There is opensource 3D for all currently shipping ATi cards. Your info is too old.

    It's not at the level of their binary right now, but many advanced games work (stuff like Nexuiz).
    That's not entirely true. Although there has been some progress on the 3D support for the latest chipsets, it's not even close to being useful/stable right now.

    Leave a comment:


  • pingufunkybeat
    replied
    AMD (no opensource 3D for cards less than 4 years old
    There is opensource 3D for all currently shipping ATi cards. Your info is too old.

    It's not at the level of their binary right now, but many advanced games work (stuff like Nexuiz).

    Leave a comment:


  • myxal
    replied
    Originally posted by DoDoENT View Post
    So what are the odds of having VDPAU support in xorg-driver-ati one day in the future?
    Last time I checked, the documentation released by AMD lacked any info for the video decoder. Also, as Bridgman pointed out earlier, the early HD Radeons had the acceleration implemented in a way such that documenting it would compromise HDCP (or something along those lines).

    I'd say video acceleration for R600/R700 is simply not coming to opensource drivers (not from official sources), we might see it in fglrx if we're lucky.

    Such is the sorry state of linux graphics - my choices are intel (drivers in quantum state, getting all the features to work with adequate performance is next to impossible for a casual Linux user), AMD (no opensource 3D for cards less than 4 years old, proprietary driver has problems with some basic functionality (Xv) and switching between computer power modes), nvidia (no opensource driver worth using yet, proprietary driver mostly works, but lacks some common features (XR&R1.2), and there's always the creeping shadow of nvidia's 'Bumpgate'). Other graphics vendors have no drivers/hardware worth using.

    Leave a comment:


  • nanonyme
    replied
    Originally posted by gbeauche View Post
    This means you need an application supporting VA API to use it.
    Well, if everything had gone according to plans, all programs would now be supporting VA API, not VDPAU. Someone messed stuff up by starting to implement other frontends in video players.

    Leave a comment:


  • gbeauche
    replied
    Originally posted by nanonyme View Post
    Since according to Wikipedia you can use VDPAU as an VA API backend, that should not make a significant difference, I think...
    This means you need an application supporting VA API to use it.

    Leave a comment:


  • nanonyme
    replied
    Originally posted by gbeauche View Post
    Actually, MPEG-2 and H.264 video decode acceleration for Intel G45 (GMA4500HD et al.) is now being developed as VA API driver.
    Since according to Wikipedia you can use VDPAU as an VA API backend, that should not make a significant difference, I think...

    Leave a comment:

Working...
X