Announcement

Collapse
No announcement yet.

Gallium3D VDPAU On Radeon Starts Working

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

  • #51
    Well, here VPDAU does work with my r300, meaning that it displays video. I too would like to know what streams is meant to accelerate. I'm on the move and I only have available a couple of youtube h264 videos. Using VDPAU with mplayer appears just slightly slower than xv. It will be very nice if it improves somehow. One negative thing is that in fullscreen it scales the video without respecting the aspect ratio...

    Comment


    • #52
      Originally posted by agd5f View Post
      It currently implements iDCT and MC on the shaders.
      z-scan, quantification and mismatch control is also implemented and working (at least with r600g).

      For r300g I have an old RV350 for testing and got z-scan, quantification, the first idct stage, mc and yuv->rgb/scaling working.
      I still have problems with the second idct stage and mismatch control, those shaders uses to many alu/tex instructions.

      Also the missing hardware features (instanced drawing, blender clamping control) is giving me quite an headache.

      Christian.

      Comment


      • #53
        Originally posted by pingufunkybeat View Post
        Most of the difficult parts of H264 are still not implemented,
        i'm 100% sure amd is opensourcing ATI Avivo!!!

        and Avivo can handle h264 in shader...
        Phantom circuit Sequence Reducer Dyslexia

        Comment


        • #54
          Originally posted by Deathsimple View Post
          z-scan, quantification and mismatch control is also implemented and working (at least with r600g).

          For r300g I have an old RV350 for testing and got z-scan, quantification, the first idct stage, mc and yuv->rgb/scaling working.
          I still have problems with the second idct stage and mismatch control, those shaders uses to many alu/tex instructions.

          Also the missing hardware features (instanced drawing, blender clamping control) is giving me quite an headache.

          Christian.
          Thanks for the update. You're doing great work!

          Comment


          • #55
            Originally posted by Deathsimple View Post
            z-scan, quantification and mismatch control is also implemented and working (at least with r600g).

            For r300g I have an old RV350 for testing and got z-scan, quantification, the first idct stage, mc and yuv->rgb/scaling working.
            I still have problems with the second idct stage and mismatch control, those shaders uses to many alu/tex instructions.

            Also the missing hardware features (instanced drawing, blender clamping control) is giving me quite an headache.

            Christian.
            There is a patch for draw_instanced on Marek branch:
            http://cgit.freedesktop.org/~mareko/...draw-instanced
            Dunno about its state.

            Comment


            • #56
              Originally posted by oibaf View Post
              There is a patch for draw_instanced on Marek branch:
              http://cgit.freedesktop.org/~mareko/...draw-instanced
              Dunno about its state.
              Thanks for the tip, but I tried this patch-set and it seems to only cause a system hangup, maybe the patches aren't complete (yet).

              But even with an instanced drawing implementation in r300g this seems to be only some sort of emulation, because the hardware simply doesn't supports it. The end result is worse performance for the decoder.

              For the motion vectors I could use an texture instead of a vertex buffer, but for the dct block list the texture size limit would also limit the picture size to something like 360x360, which isn't acceptable.

              What I basically need is a attribute per primitive instead of per vertex (or it will increase the memory bandwith needed by 4).

              Just give me a couple of days to thing about it and find a working solution.

              Comment


              • #57
                Originally posted by Deathsimple View Post
                z-scan, quantification and mismatch control is also implemented and working (at least with r600g).
                Awesome, keep up the good work. I am particularly interested because I will have to use an old athlon64 single core with an RV610 card for the next months
                ## VGA ##
                AMD: X1950XTX, HD3870, HD5870
                Intel: GMA45, HD3000 (Core i5 2500K)

                Comment


                • #58
                  Originally posted by Deathsimple View Post
                  z-scan, quantification and mismatch control is also implemented and working (at least with r600g).
                  That is impressive. I had been thinking of just MC/IDCT/Deblock on the shaders, but you've gone way past that already.

                  Comment


                  • #59
                    Originally posted by bridgman View Post
                    That is impressive. I had been thinking of just MC/IDCT/Deblock on the shaders, but you've gone way past that already.
                    The profecy has it that once every 7 Mars oppositions a new chosen hacker will arise from the mud of Phoronix posts and bring the state of open source drivers to new heights.

                    Comment


                    • #60
                      Originally posted by bridgman View Post
                      That is impressive. I had been thinking of just MC/IDCT/Deblock on the shaders, but you've gone way past that already.
                      z-scan and quantification were easy to do, and z-scan gives quite a performance boost because of the better memory layout.

                      A major stage that?s still missing is Deblock, because that's only optional for mpeg2.

                      Comment

                      Working...
                      X