Page 6 of 7 FirstFirst ... 4567 LastLast
Results 51 to 60 of 61

Thread: ATI R500 Gallium3D Performance In June 2010

  1. #51
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,540

    Default

    Is there any chance that you had the two screens configured with one logically above the other rather than side-by-side ?

    If one screen was above the other then your total area would be something like 1280 x 1568, which would fit in a 2k x 2k texture limit, vs 2304 x 800 which does not.

  2. #52
    Join Date
    Jan 2009
    Posts
    629

    Default

    Quote Originally Posted by Mez' View Post
    I have to say that I used to have those same issues a year ago with the classic stack, but a correction of the mesa driver (unfortunately, I don't know exactly which one nor when) overcame the issue and then I could perfectly use Compiz with my 2304x768/800 desktop.
    Can you, by any chance, bisect this fix or point to a FDO bug?

  3. #53
    Join Date
    Mar 2009
    Posts
    17

    Default

    Quote Originally Posted by bridgman View Post
    Is there any chance that you had the two screens configured with one logically above the other rather than side-by-side ?

    If one screen was above the other then your total area would be something like 1280 x 1568, which would fit in a 2k x 2k texture limit, vs 2304 x 800 which does not.
    It's really a side-by-side configuration, with a width of 2304 then.
    But most of the time I'm only using the laptop and Compiz works just fine with Gallium with one screen.

    @marek, there's no way I could find it back. And I don't know what's a FDO bug, so if you could guide me through it, would be fine.

  4. #54
    Join Date
    Nov 2008
    Posts
    780

    Default

    Quote Originally Posted by Mez' View Post
    And I don't know what's a FDO bug, so if you could guide me through it, would be fine.
    FDO = freedesktop.org. He was asking if you know a related bug in their bugtracker.

  5. #55
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,540

    Default

    Quote Originally Posted by Mez' View Post
    It's really a side-by-side configuration, with a width of 2304 then.
    Sorry, maybe I wasn't clear. I understand that the physical layout of the displays is side by side, but I'm pointing out that *if* you logically organized them with one above the other (using randr or xorg.conf lines) then the two displays *would* fit into the hardware limit and would have a much greater chance of working.

    This is relevent in two ways :

    1. If you tried it now it might get your system working the way you want.

    2. It may be what you did a year ago to get the system working at the time.

    I vaguely remember reading about Compiz patches/versions that could break compositing operations into multiple steps in order to get around hardware limits but I don't remember any details or if the capability was ever implemented. I don't *think* there was a classic mesa driver version that could deal with a Compiz desktop bigger than the hardware limits of the GPU so it's most likely the solution you had came from a change in some other part of the system.

  6. #56
    Join Date
    May 2007
    Posts
    352

    Default

    Quote Originally Posted by bridgman View Post
    I don't *think* there was a classic mesa driver version that could deal with a Compiz desktop bigger than the hardware limits of the GPU so it's most likely the solution you had came from a change in some other part of the system.
    As far back as I can remember, the classic r300 driver has worked with compiz with resolutions > 2048 on my x700 and x850. Obviously any single texture larger than 2048 would be corrupted beyond the 2048th pixel. This includes the gnome desktop (drawn by nautilus) or xfce4 desktop (from xfdesktop). KDE4 breaks each monitor's wallpaper into a separate window, so there's no corruption there. The compiz wallpaper plugin does the same thing, and everything renders fine there.

    So if you have two 1280x1024 monitors side-by-side (physically and virtually), and you let compiz draw its own wallpaper, the desktop would render fine. If you maximized a window across both monitors for some strange reason, then it would be corrupted.

    Even in situations where the desktop itself was corrupted, every other window less than 2048 pixels would draw just fine.

    Adam

  7. #57
    Join Date
    May 2007
    Posts
    352

    Default

    Stupid one minute limit let me actually click the edit button, but then the minute expired before I hit submit... So I have to copy and paste my edit into a new post... Can I just say that's completely idiotic?

    Anyway, this is what my addition said:


    EDIT: On r300g, at least when I first tried, compiz would fail to start entirely in those situations, even if you didn't have a window larger than 2048. I have tried it since then, and compiz has at least started. There were issues with rain and blur, and a little bit of static when moving windows, but given that I was running r300g on a development build of the as-yet unreleased compiz 0.9.*, I am not sure if they were problems with r300g or compiz, or some combination of both.

    Adam

  8. #58
    Join Date
    Mar 2009
    Posts
    17

    Default

    Quote Originally Posted by bridgman View Post
    Sorry, maybe I wasn't clear. I understand that the physical layout of the displays is side by side, but I'm pointing out that *if* you logically organized them with one above the other (using randr or xorg.conf lines) then the two displays *would* fit into the hardware limit and would have a much greater chance of working.

    This is relevent in two ways :

    1. If you tried it now it might get your system working the way you want.

    2. It may be what you did a year ago to get the system working at the time.

    I vaguely remember reading about Compiz patches/versions that could break compositing operations into multiple steps in order to get around hardware limits but I don't remember any details or if the capability was ever implemented. I don't *think* there was a classic mesa driver version that could deal with a Compiz desktop bigger than the hardware limits of the GPU so it's most likely the solution you had came from a change in some other part of the system.
    Sorry to say so, but I just don't get you with this above thing. I use Xrandr to enable my TV screen, without any little tricks or modifications anywhere else, and I put it on the left of the laptop screen, so there's nothing about above or anything. And I move horizontally to change screens.

    Furthermore, as far as I'm concerned, I can't remember doing anything before it worked a year ago with the classic mesa driver and Compiz 0.8.X). Just updated my system with the update manager, and then a few days later, at reboot, it just worked.

    Besides, I got the same static, blur, and so on as adamk with r300g (+ Compiz 0.9.X), anytime, but it's been improving a lot in the last few weeks, even if I still get these every now and then when coming back from hibernation, before the clear password pop-up eventually appears on the screen. This is still very experimental (both r300G and compiz 0.9.X) so I won't complain too much, this is the drawback for using bleeding-edge, I guess.

  9. #59
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,540

    Default

    Right. What I'm saying is that instead of using randr to put the TV on the left of your laptop screen, try putting it above. Note that this will only affect *one* of the symptoms you mentioned, not static/blur etc..

    Anyways, this might all be overtaken by events. Adamk's posts suggest that you should be able to run OK with your current configuration with the right Compiz settings unless you drag a single window across the two displays.

  10. #60
    Join Date
    Dec 2007
    Posts
    2,402

    Default

    e.g.,
    xrandr --output S-video --above LVDS

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •