Announcement

Collapse
No announcement yet.

:confused: XPress 200M troubles with git mesa/xf86-video-ati

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

  • #11
    I tried It out, not sure I got an higher frame rate but I definitely got so much tearing that I haven't seen a single picture of some movies that would not be cut into 3 pieces
    There's something strange, the HD (720p) video I use as a benchmark was actually perfect ???.

    Ah ah, wrong !, it is only a 26" screen not a 24"
    Do they actually pay you at AMD ? If so, you should consider buying one, it is so huge you can actually have 3 files side by side !
    It could also be a good way to stress your graphic card a bit

    Thanks a lot for your help and sharing your knowledge, I wish I could help you back. Maybe one day
    Bye ! Have a nice week !

    Comment


    • #12
      Regarding the mode change bug, if the game uses the xvidmode extension to change the mode, that is the problem. That extension is not multi-head aware so it ends up reprogramming the default crtc and output which don't necessarily correspond to the crtc(s) and output(s) that are active. Better to change the mode before hand using xrandr.

      Comment


      • #13
        Diagonal tearing and some performance improvements for planar video are now available in xf86-video-ati git master. You might want to try that.

        Comment


        • #14
          I do not really have dual-head. Only one screen is active, the LVDS is off (xrandr --output LVDS off ; xrandr --output VGA-0 auto). Games that are crashing when changing resolution are based upon the Quake 3 engine. What do you want me to try with xrandr ?

          I'm was already running the latest version of xf86-video-ati git master. The only thing that has changed since is Alex Deutcher's commit (RV770: add missing pci id) 40 minutes ago.

          Comment


          • #15
            Originally posted by M?P?F View Post
            I do not really have dual-head. Only one screen is active, the LVDS is off (xrandr --output LVDS off ; xrandr --output VGA-0 auto). Games that are crashing when changing resolution are based upon the Quake 3 engine. What do you want me to try with xrandr ?
            xvidmode is an old extension that does not understand that LVDS is off and you are only using VGA. It just blindly changes the mode on one output and one crtc regardless of the current topology. My suggestion is to change the mode to whatever mode you want to run with xrandr first before starting the game, e.g.,
            xrandr --output VGA-0 --mode 800x600

            Originally posted by M?P?F View Post
            I'm was already running the latest version of xf86-video-ati git master. The only thing that has changed since is Alex Deutcher's commit (RV770: add missing pci id) 40 minutes ago.
            Ok. you should have the latest bits then.

            Comment


            • #16
              Originally posted by agd5f View Post
              My suggestion is to change the mode to whatever mode you want to run with xrandr first before starting the game, e.g.,
              xrandr --output VGA-0 --mode 800x600
              I doesn't change anything as the game reset the resolution with its own settings (and it works). But, when I try to change the resolution in game, it crashes.

              Comment


              • #17
                OK, some more silly questions that are hopefully not that silly :

                First of all, I did some more testing about in game resolution changing. agd5f told it was a multi-head problem, so I tried without multi-head at all (just using LVDS, unplugging the VGA cable) and it crashes just the same way. So, this is something wrong with the driver.
                Were should I bug report ?

                The second one is still about gaming. Two weeks ago, I started being able to play 3D games with more than 3 fps in 640*480. I am now at the point to be able to play tremulous with a resolution of 1600*1000 and 35fps. It is quite a big improvement ! But at the same time, some games are damnly slow ! For example, Extreme Tux Racer, I can't get more than 2 fps.
                Another strange behavior is about Nexuiz. Everything is smooth and fast but as soon as I spot a player or a weapon, the framerate drops from 50 to 3fps.
                I assume this problem is caused by a lack in vertex/pixel shaders. My question is, is it a hardware or software problem ?
                I also would like to say nexuiz takes almost no CPU. Would it be possible to get this missing shader software rendered ?

                Thanks by advance

                Comment


                • #18
                  OK, assuming the problem is in the driver and not in the game, you can find the bugzilla link on the home page of x.org, at http://www.x.org (yeah, I'm in "teach a man to fish" mode today ).

                  Really bad slowdowns areu usually caused by software fallbacks, ie doing something in software rather than on the GPU. You can use driconf to "disable low impact fallbacks" (presumably low impact refers to visual impact, not performance impact), although on the latest mesa that option is apparently on by default. Anyways, if you haven't already tried driconf it should be your next step.

                  Mesa will execute vertex shaders in SW as far as I know, it's just not fast. Is the CPU still low during the really slow times ?
                  Test signature

                  Comment


                  • #19
                    Originally posted by bridgman View Post
                    OK, assuming the problem is in the driver and not in the game, you can find the bugzilla link on the home page of x.org, at http://www.x.org (yeah, I'm in "teach a man to fish" mode today ).
                    OK, it doesn't depend on the game. I tried 4 different games and the problem is just the same. Moreover, there were no problem a few months back. I'm about to bug report it.
                    EDIT : Here is the bug with some more information (after a more intensive test) : https://bugs.freedesktop.org/show_bug.cgi?id=21778

                    Originally posted by bridgman View Post
                    Really bad slowdowns are usually caused by software fallbacks, ie doing something in software rather than on the GPU. You can use driconf to "disable low impact fallbacks" (presumably low impact refers to visual impact, not performance impact), although on the latest mesa that option is apparently on by default. Anyways, if you haven't already tried driconf it should be your next step.

                    Mesa will execute vertex shaders in SW as far as I know, it's just not fast. Is the CPU still low during the really slow times ?
                    Hmm hmm, 'Disable Low-Impact fallback' was on off, I tried turning it on and the game was even slower (as you expected). The CPU load is always very low (almost 0) on nexuiz while on some other games as Tremulous, a complete core is used and it runs pretty fast.
                    Last edited by MuPuF; 17 May 2009, 07:36 AM.

                    Comment

                    Working...
                    X