Announcement

Collapse
No announcement yet.

Gallium3D VDPAU On Radeon Starts Working

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

  • #51
    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


    • #52
      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


      • #53
        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


        • #54
          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


          • #55
            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


            • #56
              Christian, what are the major milestones needed to add h264 support? I'm assuming that much of the stuff can be reused (MC, deblocking, etc.)

              Comment


              • #57
                Originally posted by pingufunkybeat View Post
                Christian, what are the major milestones needed to add h264 support? I'm assuming that much of the stuff can be reused (MC, deblocking, etc.)
                I wouldn't start with h264, mpeg4 (divx, xvid) would be the next logical step.

                For this we need at least a new bitstream decoder, and at minimum quite some changes to the mc stage.

                h264 also defines some new form of transformation which needs to be implemented, but to be honest I actually doesn't know much about how h264 works.

                Comment


                • #58
                  /me does not understand, if the vdpau one already does more than xvmc, why is it reported as slower than xv?

                  Comment


                  • #59
                    Originally posted by curaga View Post
                    /me does not understand, if the vdpau one already does more than xvmc, why is it reported as slower than xv?
                    Most people are currently only testing the yuv->rgb and scaling part of vdpau, since this works with all supported codecs.

                    This stages of the rendering pipeline are just a bit slower than Xv because of the debugging overhead. If you compile the state tracker without debugging support, it should be slightly faster because we don't need to call the x server to display every frame.

                    But the real improvement comes only when you enable more decoding stages, with mplayer provide the "-vc ffmpeg12vdpau" option for example.

                    Comment


                    • #60
                      MythTV / VDPAU / r600g

                      Looks like some people have MythTV working using VDPAU over r600g now, albeit playback is a bit jerky:

                      http://www.gossamer-threads.com/lists/mythtv/dev/482148

                      Comment

                      Working...
                      X