Page 2 of 8 FirstFirst 1234 ... LastLast
Results 11 to 20 of 78

Thread: There May Still Be Hope For R600g Supporting XvMC, VDPAU

  1. #11
    Join Date
    Aug 2007
    Posts
    6,607

    Default

    Every Evergreen or newer has OpenGL 4.x in the opengl version string and olders show 3.x. Why don't you use that?

  2. #12
    Join Date
    Jun 2009
    Location
    Paris
    Posts
    432

    Default

    Quote Originally Posted by Kano View Post
    Every Evergreen or newer has OpenGL 4.x in the opengl version string and olders show 3.x. Why don't you use that?
    This is not sure, and you don't know if the same workarounds are necessary. Someone will have to check with the relevant XVBA_VIDEO_EVERGREEN_WORKAROUND variables. Checking for the OpenGL version string is silly.

  3. #13
    Join Date
    Aug 2007
    Posts
    6,607

    Default

    That's maybe 99.9% sure...

  4. #14
    Join Date
    Aug 2009
    Posts
    2,264

    Default

    Hello world. CPU's can playback video. CPU's can't do 3D graphics. Why do you think people buy GPU's?

    Is it just me or is the world nuts? Okay...

  5. #15
    Join Date
    Dec 2009
    Posts
    338

    Default

    Quote Originally Posted by V!NCENT View Post
    Hello world. CPU's can playback video. CPU's can't do 3D graphics. Why do you think people buy GPU's?

    Is it just me or is the world nuts? Okay...
    Well, CPUs can play videos up to a certain level. My Turion X2 ultra (2.2GHz) can play 1080p with mplayer-mt, but with high bitrate scenes it struggles and drops frames, sometimes stops drawing new ones for ~5 seconds. I have a fairly good GPU, a HD4650 (rv730).

    So here is the deal: if my GPU could do a little more work in the decoding process I might as well be able to enjoy all my videos.

    Am I nuts?

  6. #16
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,386

    Default

    Bingo.

    Many systems don't have *quite* enough CPU power to play the videos that users want to watch, so offloading even part of the decode work to the GPU can make a big difference in user experience. There are also formats which hardware acceleration won't handle today (VP8 is an obvious example but I'm sure there will be more in the future) so a general purpose, easily extensible solution will be useful in other ways as well.

    You might still be nuts but not in this specific case

  7. #17
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,386

    Default

    There is also the obvious point that if we are not able to open up UVD programming information then shader-assisted decode is going to be a nice thing to have even if it only implements prediction/MC and filtering.

  8. #18
    Join Date
    Dec 2009
    Posts
    338

    Default

    Quote Originally Posted by bridgman
    ...if we are not able to open up UVD programming information...
    Yes, I wanted to mention that you never said that you won't as Michael wrote in the article. You wrote in the other forum that you will look at it and in 6 months you will be able to tell if it will ever happen or not.

    So, for example the vdpau state tracker would eat the vdpau calls from mplayer and turn them into tgsi intsructions* then the r600g driver would eventually display it.

    *: Well, I think tgsi will be turned back to glsl ir by the driver first, then it would get optimised and fed back to the driver to actually display something. Right?

    Quote Originally Posted by bridgman View Post
    You might still be nuts but not in this specific case
    Thanks. :P

  9. #19
    Join Date
    Dec 2009
    Posts
    338

    Default

    Let's assume we have a working vdpau state tracker with r600g.
    Now how could we add vp8 decoding possibility to this?


    1) The shader based version which was started eons ago needs to be done for all formats, right?
    2) An opencl based solution would require a working opencl state tracker and the ffmpeg guys to write decoders for each codec.
    3) The vdpau state tracker needs to be written only once and then we've got to wait for nvidia devs to implement support new formats. Maybe some modifications are needed afterwards.

    Assuming the above points are correct the 3rd option requires the least amount of xorg work I think. Plus it would work immediately.
    The 1st option seems pointless.
    The 2nd option is interesting, because ffmpeg devs are interested in that and that state tracker could be used for several other projects, too.

    So I am actually confused; why haven't the xorg devs written a proper opencl state tracker with good driver support and said that:
    "Write opencl code and don't ever mention again uvd/xvba/vdpau/vaapi!"?
    It seems much easier to me and the end result might as well be better than with any other option.

    Conclusion:
    The fastest solution is what is in the article, the "vdpau state tracker for r600g".
    The best would be possibly the opencl one but there is no such decoder at the moment so it wouldn't solve the situation right now.


    One more thing:
    So the decoder is now written in c/assembly which runs on the cpu or gpu (through vdpau/xvba/vaapi).
    If it was written in opencl then it could run on the cpu, the gpu or both. In this case vdpau/xvba/vaapi won't get touched but the drivers' opencl capabilities will be used.

    Please correct me if I am wrong somewhere!

  10. #20
    Join Date
    Sep 2008
    Posts
    40

    Default

    Quote Originally Posted by V!NCENT View Post
    Hello world. CPU's can playback video. CPU's can't do 3D graphics. Why do you think people buy GPU's?

    Is it just me or is the world nuts? Okay...
    CPU's actually can do 3D graphics, but they suck at it. We already had 3D games before the everybody started installing Voodoo cards.

    As said, videos with a high bitrate are hard to decode using just the CPU. Also, the GPU can often do it using far less power. Don't be surprised if GPU decoding uses 30 watts less compared to having the CPU do the same thing. Apart from the slightly lower electricity bill this mostly reduces fan noise and, in case of laptops, improves battery time.

    So yeah, call me nuts..

Tags for this Thread

Posting Permissions

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