Announcement

Collapse
No announcement yet.

The UVD/UVD2 thread.

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

  • #31
    Originally posted by bridgman View Post
    I think you want VideoOverlay off and TexturedVideo on.
    Thanks for reply.
    I'm pretty sure I've already tried all the
    Code:
    "VideoOverlay"
    "OpenGLOverlay"
    "TexturedVideo"
    combinations with no noticeable difference.

    As coming back to Windows is not an option (and video decoding is perfect under Win), could you plz tell do you have any concrete plans on bringing UVD2 support to Linux or should I just get real and move to nvidia + intel?

    Comment


    • #32
      That doesn't seem likely; you would notice a pretty big difference when the GPU was doing the back-end processing, whether it be thorough Xv with TexturedVideo or through GL. Have you tried playback through gl, btw ?

      I can't really comment on specific plans for things we haven't released, sorry.

      Comment


      • #33
        It's sad, so sad
        It's a sad, sad situation
        And it's getting more and more absurd

        You were right, TexturedVideo mode is faster (still not fast enough on 4850e to decode a fullhd movie).
        Do I get it right that for HD3200 + fglrx 8.561 the best combination is
        Code:
        Option      "VideoOverlay" "off"
        #       Option      "OpenGLOverlay" "on" //this doesn't matter
                Option      "TexturedVideo" "on"
        Now, the real issue is that even SD content is jerky when screen resolution is set to 1920*1080 and plays just fine on 720p. Seems like memory bus saturation in action?

        Comment


        • #34
          Those options sound right.

          I'm surprised you are getting jerky playback at 1920x1080; the 780 should be fast enough to scale SD up to 1080 smoothly. The memory bus probably is the weakest link but I don't think we should be hitting the limits yet. Is the SD video MPEG2 or H.264 ?

          I'll try to find a 780 system I can play with here. What are you using for player and decoder ?

          Comment


          • #35
            bridgman
            Well, I don't remember having any troubles with any resolution under XP (esp. given that the ram config is 1gb *4).
            The SD video is h.264/mpeg4 played with xbmc (+ffmpeg).
            Here's what I've been experiencing with 1920*1080 screen resolution:

            Switching to 720p reduces the number of dropped frames down to 0.

            Comment


            • #36
              Was UVD2 support backported to old UVD?

              If I'm not wrong, my M76 (mobility radeon HD2600) should be equipped with UVD, but if I grep the Xorg log...

              Code:
              ben@Obi-Wan ~ $ grep UVD /var/log/Xorg.0.log
              (II) fglrx(0): UVD2 feature is available


              well... obviously I couldn't manage it to work.... but this i surprising

              Comment


              • #37
                Originally posted by gsmd View Post
                Here's what I've been experiencing with 1920*1080 screen resolution
                CPU utilization was pretty low there but I imagine that was snapped after the video finished playing.

                What is the CPU utilization like while playing the SD video scaled up to 1920x1080 ?

                Comment


                • #38
                  bridgman
                  That was snapped during video playback (~ 4 mins from the start) upscaled to 1080p. Again, no dropped frames playing the same video upscaled to 720p.

                  Here's HD downscaled to 720p:

                  Still jerky, but somewhat acceptable (snapped around the middle of the movie). Switching screen resolution to 1080p causes the same effects it does to SD: the thing becomes unwatchable.

                  Comment


                  • #39
                    Very interesting... so with the SD video the CPU utilization was very low and you were still dropping frames. I'll see if we can repro that in house.

                    Comment


                    • #40
                      Alex ran a quick test on a 780 mobo scaling SD video up to 1920x1200 using the just-released open source Xv code for 6xx/7xx in radeonhd. The video scaled up smoothly with no apparent dropped frames, so I don't think we've got a hardware limit here. It probably wasn't the same player/decoder stack and I know it wasn't the same video, but the CPU util was low enough that I don't think it would matter. Stay tuned.
                      Last edited by bridgman; 01-21-2009, 10:17 PM.

                      Comment


                      • #41
                        I've always had the same issue. I had a mythtv frontend with an ATI integrated 1250. Recordings were all MPEG2, both HD and SD. Everything played back perfectly on my 720p TV. I replaced that one with a 1080p set and it became unwatchable (same recordings). I even tried it on a spare R300 card I had, same thing. Anything scaled to 1080p was completely unwatchable. Didn't matter if the recording was 480i, 480p, 720p, or 1080i. If I changed the output resolution to 720p, everything played back fine. I spent hours messing around with the settings using just about every combo possible (texturedvideo, opengl, mythtv playback settings, deinterlacing, etc). Nothing was even close to watchable. I had another frontend with an NVIDIA card that was used on a 720p set. I swapped that with the R300, so I now have the NVIDIA card in the 1080p frontend, and the ATI in the 720p frontend. Everything is working fine, except I'd prefer to be able to use the integrated card. Every once in a while, I'll try the latest ATI driver and switch back to the integrated card to see if it's been resolved. The last time I tried, I think was November, and it still had the same issue.

                        Comment


                        • #42
                          That's interesting. The R300 should have no shortage of bandwidth and shader power, and CPU activity should have zero effect on the the scaling throughput.

                          If you're seeing this on discrete cards as well it should be easy to reproduce in house.

                          Comment


                          • #43
                            Oh, gods... is it still theoretically possible that we'll be seeing UVD2 open specifications? I don't even know if you can answer this, but... Bridgman, was it the UVD that was sold? (UVD is directly derived from the MIPS-based Xilleon, right?)

                            http://www.broadcom.com/press/release.php?id=1190026


                            Is it possible (at least on Microsoft Windows) to power off/suspend/kill the UVD block?

                            Comment


                            • #44
                              Without going into details, the sale does not affect our ability to provide UVDn docco for open source development. It does mean we need to be *very* careful when looking at whether or not it is safe to provide the info, but that isn't really anything new

                              I don't know whether UVD can be powered down. I imagine it has clock gating, probably automatic, but will find out as we start to dig into the block over the next couple of months.

                              Comment


                              • #45
                                Thank you so much Bridgman, for your exhaustive replies on these forums and continuous efforts on free and open software.

                                I was wondering whether UVD could be powered down, in case it would result useless by lack of open specifications, as it's expected to be embedded in the next hoard of AMD-based notebooks, one of which will be mine.

                                Now I'm kind of relieved.

                                Comment

                                Working...
                                X