Announcement

Collapse
No announcement yet.

Installing latest Open Source ATI drivers under Ubuntu 8.04

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

  • Ragool
    replied
    Originally posted by Pitabred View Post
    With 99%/50%, that means you've got a single thread pegged for decoding 1080p. Since there's no hardware H.264/VC-1 decode acceleration for ATI under Linux yet, if you have a multi-core CPU I'd suggest hitting up mplayerhq.hu for the multithreaded mplayer. I ran into the same problem... if the 720p is smooth, that's almost certainly your problem, and not Xv.
    I missed you post earlier. Will try it out next week and let you know.

    Thanks.

    Regards

    Leave a comment:


  • tormod
    replied
    Originally posted by oibaf View Post
    What about dropping all the packages for Jaunty and older Ubuntu from xorg-edgers PPA? Or you want to keep them for history purposes?
    Yes, we have been thinking about it. But if someone is happily using the last updates we pushed for Hardy or Intrepid, it does not hurt to keep it there. Personally I used the Hardy packages really long on my work machine with r500

    Leave a comment:


  • oibaf
    replied
    Originally posted by tormod View Post
    Anyway, doing on-the-edge testing with a year old distribution does not make sense, so this thread should die anyway. Maybe somebody can unstickify it?
    What about dropping all the packages for Jaunty and older Ubuntu from xorg-edgers PPA? Or you want to keep them for history purposes?

    Leave a comment:


  • bridgman
    replied
    Originally posted by Kjella View Post
    An accelerator could be written using shaders like any GPGPU application but noone's got a working implementation, only a few unfinished summer of code projects. All that could seem busy trying to make 3D acceleration work instead.
    General consensus is that implementing shader-based video decode over Gallium3D makes more sense than doing a hardware-specific implementation for every different GPU family. The current focus on 3D work reflects that :

    Classic 3D => Gallium3D => video decode over Gallium3D

    One thing I haven't had time to check is whether XvMC can be useful for H.264 and VC-1 if only the MC portion of the API were used (ie not IDCT, where the MPEG-2 coefficients definitely won't work). My guess is that XvMC in its current form simply won't fit with the newer video formats, so there's a strong argument for implementing a Gallium3D backend directly in the existing decoder stacks.
    Last edited by bridgman; 09-08-2009, 09:33 AM.

    Leave a comment:


  • Kjella
    replied
    Originally posted by Ragool View Post
    The short story is that it's not the interface that's important but what's powering it. Ranking from best to worst:

    a) Fixed-function hardware
    b) GPU shaders
    c) CPU decoding

    Radeon HAS fixed-function hardware for h.264/vc-1 decoding, but it's not available under Linux because AMD has not, and probably can not release specs. An accelerator could be written using shaders like any GPGPU application but noone's got a working implementation, only a few unfinished summer of code projects. All that could seem busy trying to make 3D acceleration work instead.

    Basically, you'll probably have to wait a long time. It's one of the areas where being closed source helps as nVidia has full fixed-function hardware decoding in their blob.

    Leave a comment:


  • nanonyme
    replied
    Originally posted by Ragool View Post
    Does the current XVideo in this driver have XvMC working with mpeg-2 atleast? Is VA API coming for radeon or is XvMC going to be implemented with XVideo for mpeg4/VC-1?
    No XvMC yet. XvMC is coming at latest as a Gallium3D feature (some day) and I got the impression open drivers would eventually get VDPAU too with Gallium3D. (everyone's free to implement more video decoding API's on Gallium3D if they have spare time)

    Leave a comment:


  • Pitabred
    replied
    Originally posted by Ragool View Post
    works now!
    drmOpenDevice: node name is /dev/dri/card0
    drmOpenDevice: open result is 7, (OK)

    720p runs full screen with 50%/40% per cpu core, 1080p runs at 99%/50% per core!!

    fglrx used to run 1080p @60%/45% per core. This is also what AMD/ATI promised with the chipset without phenom+1066 RAM. Clearly the XVideo accel needs working on.

    cpu is BE-2350 2.1 ghz with Dell 2408wfp @1920x1200.

    But atleast its mostly working (except audio which appears to be a ffmpeg issue)

    Thanks for your assistance. Please update when XVideo improvements need to be tested. I will be happy to test and report.

    Regards
    With 99%/50%, that means you've got a single thread pegged for decoding 1080p. Since there's no hardware H.264/VC-1 decode acceleration for ATI under Linux yet, if you have a multi-core CPU I'd suggest hitting up mplayerhq.hu for the multithreaded mplayer. I ran into the same problem... if the 720p is smooth, that's almost certainly your problem, and not Xv.

    Leave a comment:


  • Ragool
    replied
    Originally posted by bridgman View Post
    Some of the CPU usage is from the tear-free code waiting for vblank. If you use xvattr to turn off the XV_VSYNC option that will probably cut down your CPU utilization but increase tearing. The rest of the CPU use probably is from decoding, and accelerated decoding (mostly motion comp) would help there.

    The latest driver code has been updated to look for the r600 driver, but that was probably done a bit after the 6.2.1 release.
    Does the current XVideo in this driver have XvMC working with mpeg-2 atleast? Is VA API coming for radeon or is XvMC going to be implemented with XVideo for mpeg4/VC-1?

    I read this but am not clear: http://xorg.freedesktop.org/wiki/RadeonFeature

    Sorry if this is OT in this thread, please point me to the correct one.

    TIA

    Leave a comment:


  • bridgman
    replied
    Some of the CPU usage is from the tear-free code waiting for vblank. If you use xvattr to turn off the XV_VSYNC option that will probably cut down your CPU utilization but increase tearing. The rest of the CPU use probably is from decoding, and accelerated decoding (mostly motion comp) would help there.

    The latest driver code has been updated to look for the r600 driver, but that was probably done a bit after the 6.2.1 release.

    Leave a comment:


  • Ragool
    replied
    PS: Is lack of hardware accel the cause of 99% cpu on 1080p?

    (EE) AIGLX error: dlopen of r300_dri.so failed
    (EE) AIGLX: reverting to software rendering

    wonder why the s/w is looking into r300 chipset on RS780 ?

    Regards

    Leave a comment:

Working...
X