Page 2 of 4 FirstFirst 1234 LastLast
Results 11 to 20 of 31

Thread: Mesa 7.4 Released, Fixes The 7.3 Bugs

  1. #11
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,279

    Default

    Quote Originally Posted by MPF View Post
    @KDesk : No, I don't. I've been using radeon for almost a year now.
    Moreover, I'm running a 2.6.29 kernel and xserver 1.6. Both are incompatible with the latest AMD's driver.

    Everyone agrees it is strange so. I can do a screencast if you want. But I can assure you, this is REALLY great !! Every single animation is so smoooooooooth ! And the CPU load while playing with compiz approaches 0 !
    Yep, you're definitely running radeon. Unless you picked up a KMS driver stack from Fedora (which seems unlikely given the version numbers) I don't have a good explanation for why you are getting RDR, but I guess it's a good problem to have. Don't touch anything on that system

    If you *are* running a KMS stack somehow, then you're seeing what everyone else should start to see in a few months.

  2. #12
    Join Date
    Feb 2009
    Location
    France
    Posts
    265

    Default

    I did compile a KMS stack, but I changed back because of instabilities.

    But I'm sure I'm using the normal stack now, pacman (the package manager of ArchLinux) would have warned me if I didn't.

    So, for those who haven't my chance, I can assure you it is AWESOME !

    My glxgears in action, RDR but not tear-free:
    http://fs.mupuf.org/files/glxgears2.png

  3. #13
    Join Date
    Jul 2008
    Location
    Greece
    Posts
    3,762

    Default

    How on earth did you make that picture?

  4. #14
    Join Date
    Feb 2009
    Location
    France
    Posts
    265

    Default

    Quote Originally Posted by RealNC View Post
    How on earth did you make that picture?
    $ glxgears

    And then grabbed the window and moved it while pressing the screenshot key.

    I have no clues why the background is transparent though.

  5. #15
    Join Date
    Jul 2008
    Location
    Greece
    Posts
    3,762

    Default

    Tearing is an effect of the monitor. It never shows in screenshots, only with pictures taken with a camera... :P Why is it showing on your screenshot?

  6. #16
    Join Date
    Feb 2009
    Location
    France
    Posts
    265

    Default

    Are you sure that tearing is an effect of the monitor ?
    I thought it had to see with changing the front buffer while updating the screen. I didn't activate V-Sync (I should start looking for it).

    Whatever, it has always been this way with the radeon driver on my laptop. Usually, you can barely see it but it is quite visible with glxgears. I guess it is because it is not really accelerated (look at the poor FPS rate, and a core of my CPU is fully used).

  7. #17
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,279

    Default

    When you add a compositor into the mix, you can get tearing at the compositor level as well and that *does* show up in screen shots.

  8. #18
    Join Date
    Jul 2008
    Location
    Greece
    Posts
    3,762

    Default

    Didn't think of that.

    So in other words, we're screwed double

  9. #19
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,279

    Default

    Quote Originally Posted by RealNC View Post
    So in other words, we're screwed double
    Only temporarily -- I'm sure that's a great comfort

    MacOS and Vista were designed around a compositor, while X/DRI has a variety of compositors which can be inserted in what is fundamentally a non-composited stack. There probably needs to be a standard way to handle buffer queues all the way from app through compositor to screen so that :

    (a) only completed images get composited,

    (b) only completed frames from the compositor get displayed on the screen,

    (c) screen updates are synchronized with vblank, and

    (d) fixed-rate apps like video playback can either double or drop frames as needed to stay in sync with the display refresh, and games can reliably cap at display refresh rate.

    Working the other way - genlocking the display refresh rate to the video frame rate -- sounds attractive but is tough to implement reliably.

    Krh's work on Wayland is a good example of "designing around a compositor from day one". Whether the future is something like Wayland or just knowledge and ideas from Wayland going back into the current graphics stack, that's what it's going to take.

    The good news is that a lot of this can probably be hacked into the current stack (the current tear-free code in radeon/radeonhd is essentially an innovative hack), it just won't work all the time or in all configurations.
    Last edited by bridgman; 03-28-2009 at 10:10 AM.

  10. #20
    Join Date
    Feb 2009
    Location
    France
    Posts
    265

    Default

    Quote Originally Posted by bridgman View Post
    Only temporarily -- I'm sure that's a great comfort

    MacOS and Vista were designed around a compositor, while X/DRI has a variety of compositors which can be inserted in a non-composited stack. I don't think the changes required will be huge, but there needs to be a standard way to handle buffer queues from app to compositor and compositor to screen so that only completed images get composited, only completed frames from the compositor get displayed on the screen, screen updates are synchronized with vblank, and fixed-rate apps like video playback can either double or drop frames as needed to stay in sync with the display refresh, or that the display refresh can be synchronized to the video frame rate.

    Krh's work on Wayland is a good example of "designing around a compositor from day one". Whether the future is something like Wayland or just knowledge and ideas from Wayland going back into the current graphics stack, that's what it's going to take.

    The good news is that a lot of this can probably be hacked into the current stack (the current tear-free code in radeon/radeonhd is essentially an innovative hack), it just won't work all the time or in all configurations.
    Thanks for the explanation. Wayland is surely a good project, I can't wait to find an Intel GPU to try it out.

    Do you think GEM will be the perfect way to pass buffers from the compositor to the driver ? It would be faster than copying each frame (it is a supposition). I think it is the way Wayland implements everything.

Posting Permissions

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