Announcement

Collapse
No announcement yet.

690G OpenGL video playback is Green & Purple

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

  • 690G OpenGL video playback is Green & Purple

    Hi All,
    Finally I have my 690G based computers up and running with open source drivers and everything is running well. Except video playback from within an OpenGL application. Everything is Green and Purple..
    System is Ubuntu 8.10 alpha 5 using the radeon driver

    Using the radeonhd driver the video playback is the correct colours however the performance is so terrible (about 1/10 of radeon) that it's unusable.

    Anyone run into this before or have any suggestions as to how to fix it?

  • #2
    Is this video playback over a normal monitor (VGA, DVI etc..) or over a TVOut (composite, S-Video, component) ?

    Comment


    • #3
      Sounds like a problem in the colorspace conversion. Does it happen with all videos or just certain ones?

      ...wait what do you mean by "video playback from within an OpenGL application"? Are you using Xv or is GL rendering the video?

      Comment


      • #4
        YUV decoding problem.

        Comment


        • #5
          Connection is via LVDS, I can try VGA but will have to wait til after the weekend.
          The 'application' is the python libavg framework. Renders everything using openGL sorry I'm not sure on the specific details of how it all works sorry.
          using ffplay works fine I've tested two videos one is mpeg2 the other is an mpeg4 of some variation. I'll check exactly what codecs when I'm near that machine again.

          Comment


          • #6
            Originally posted by ovoskeuiks View Post
            Connection is via LVDS, I can try VGA but will have to wait til after the weekend.
            The output doesn't matter.

            Originally posted by ovoskeuiks View Post
            The 'application' is the python libavg framework. Renders everything using openGL sorry I'm not sure on the specific details of how it all works sorry.
            using ffplay works fine I've tested two videos one is mpeg2 the other is an mpeg4 of some variation. I'll check exactly what codecs when I'm near that machine again.
            If ffplay uses Xv and it works, I'm guessing it's a problem with the GL code in libavg or the r300 3D driver.

            Comment


            • #7
              Originally posted by agd5f View Post
              If ffplay uses Xv and it works, I'm guessing it's a problem with the GL code in libavg or the r300 3D driver.
              Is the r300 3D driver common to both radeon and radeonhd? The radeonhd works but with terrible performance, so would that point to it being something in the implementation of the radeon driver?

              Comment


              • #8
                The 3D and DRM drivers are common between radeon and radeonhd, although 3D was only fully integrated into radeonhd relatively recently. One possibility is that radeonhd was falling back to software rendering for some reason -- "works but terribly slow" is another way of saying "software rendering"

                Could you pastebin a log with radeonhd ?

                Comment


                • #9
                  Originally posted by bridgman View Post
                  The 3D and DRM drivers are common between radeon and radeonhd, although 3D was only fully integrated into radeonhd relatively recently. One possibility is that radeonhd was falling back to software rendering for some reason -- "works but terribly slow" is another way of saying "software rendering"

                  Could you pastebin a log with radeonhd ?
                  I can but I'm away at a Tangi for the next few days will post it when I'm back in front of that machine.

                  Comment


                  • #10
                    Originally posted by bridgman View Post
                    The 3D and DRM drivers are common between radeon and radeonhd, although 3D was only fully integrated into radeonhd relatively recently. One possibility is that radeonhd was falling back to software rendering for some reason -- "works but terribly slow" is another way of saying "software rendering"

                    Could you pastebin a log with radeonhd ?
                    This is using radeonhd with the xorg.conf options specified in the installing open-source drivers thread in this forum. Uncommenting the DRI option gives a Warning saying Option DRI is not used

                    xorg.conf
                    http://pastebin.com/m5cc18acc

                    Xorg.0.log
                    http://pastebin.com/d632079c9

                    glxinfo
                    http://pastebin.com/m1a4ca0d0

                    glxgears performance with this is about 120 FPS as oppose to around 800 with ati-radeon

                    Cheers

                    Comment


                    • #11
                      (II) AIGLX: Screen 0 is not DRI2 capable
                      (II) AIGLX: Screen 0 is not DRI capable
                      (II) AIGLX: Loaded and initialized /usr/lib/dri/swrast_dri.so
                      (II) GLX: Initialized DRISWRAST GL provider for screen 0
                      OK, let's see. It's definitely using the software rasterizer, possibly because you are running with shadowfb.

                      Section "Device"
                      Identifier "Configured Video Device"
                      Driver "radeonhd"
                      Option "AccelMethod" "ShadowFB"
                      # Option "DRI"
                      EndSection
                      Suggest you either comment out the ShadowFB option (which gets you the default of XAA, I think) or choose EXA instead if you want to run Compiz. The reason for choosing EXA is that if you want to redirect textured video playback for Compiz you need the EXA memory manager; the one in XAA isn't good enough.

                      Try that first and let's see what happens.

                      Comment


                      • #12
                        Your glxinfo shows:
                        Code:
                        #
                        OpenGL vendor string: Mesa Project
                        #
                        OpenGL renderer string: Software Rasterizer
                        #
                        OpenGL version string: 2.1 Mesa 7.1
                        This tells you mesa (software) is running and not fglrx. Mine shows (for 780g and catalyst 8.9):
                        Code:
                        OpenGL vendor string: ATI Technologies Inc.
                        OpenGL renderer string: ATI Radeon HD 3200 Graphics
                        OpenGL version string: 2.1.7979 Release
                        Did you have errors when running the autoinstaller (sh ati*.run)? Are you running a different kernel since you installed the catalyst drivers and need to rerun? Sorry if you already answered as I didn't go back and read earlier posts.

                        Edit: oops, sorry, I didn't notice this was open source driver post as I'm reviewing both.
                        Last edited by forum1793; 09-25-2008, 07:49 PM.

                        Comment


                        • #13
                          I think the original poster is trying to run the open source drivers rather than fglrx.

                          Anyways, I think we have the answer to the original question, ie why the colours were correct with radeonhd but not with radeon. With radeonhd you were running with the software 3D driver so it's likely there is a colour conversion problem in the hardware accelerated 3D driver.

                          Comment


                          • #14
                            Originally posted by bridgman View Post
                            I think the original poster is trying to run the open source drivers rather than fglrx.

                            Anyways, I think we have the answer to the original question, ie why the colours were correct with radeonhd but not with radeon. With radeonhd you were running with the software 3D driver so it's likely there is a colour conversion problem in the hardware accelerated 3D driver.
                            Correct, So my next question is to whom do I direct a query regarding the colour space problem?

                            for reference here is the log using XAA acceleration, the result is the same software rendering
                            http://pastebin.com/d754cc025

                            Also would be interesting as to why direct rendering isn't working using radeonhd. It doesn't worry me particularly because radeon works fine but I'd be happy to do some debugging if it was useful to someone.
                            Last edited by ovoskeuiks; 09-25-2008, 08:51 PM.

                            Comment


                            • #15
                              Radeonhd doesn't enable the DRI by default so you'll need to add:
                              Option "DRI" "True"
                              to the device section of your config.

                              As to the color problem, if the software GL stack works correctly, but HW does not, you've probably stumbled upon a bug in the the r300 driver (which is used by both radeon and radeonhd). Your best bet it to file a bug against the r300 mesa driver at https://bugs.freedesktop.org. Be sure to attach your xorg log and config and a description of the problem.

                              Comment

                              Working...
                              X