Announcement

Collapse
No announcement yet.

ATI R500 Gallium3D Performance In June 2010

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

  • bridgman
    replied
    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.

    Leave a comment:


  • Mez'
    replied
    Originally posted by agd5f View Post
    The max texture size is 2048. That's a hardware limit. If your desktop is larger than that you will hit problems. What the driver does when it gets a texture larger than the max is another issue.
    The second screen, which is a TV, adds 1024x768 to the initial 1280x800 resolution of my notebook. 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. It is far from being a blocker, so don't take my words as a criticism for the sake of it, but it would jsut be nice/perfect if this r300g Gallium driver could do the same without having to deal between both settings.

    Leave a comment:


  • agd5f
    replied
    The max texture size is 2048. That's a hardware limit. If your desktop is larger than that you will hit problems. What the driver does when it gets a texture larger than the max is another issue.

    Leave a comment:


  • Mez'
    replied
    Originally posted by agd5f View Post
    For compiz or any other GL compositor, they need to check the max texture size supported by the hardware before starting; unfortunately, they usually don't. The max texture size on r3xx/r4xx is 2048 pixels so if you desktop is larger than that, you will have display issues regardless of what driver you use.
    In fact, I don't have any of those issues when using 2 screens under the classic mesa driver with Compiz (in KMS mode, for bridgman), so I would say I can't agree with you.

    Leave a comment:


  • barkas
    replied
    I hope so, because in this state it's not quite usable.

    Leave a comment:


  • marek
    replied
    Originally posted by barkas View Post
    The main problem I have is terrible lag with gallium. Apart from that it runs significantly faster than plain old mesa.
    But that doesnt help much if it trails an estimated 300ms behind my input.
    This is caused by the driver emitting more command streams than your GPU can process. It can be fixed by inserting a sync at the end of every frame but there is no way to notify a 3D driver about that in DRI2. Shouldn't this issue be taken care of by DRI2 Swap & Sync?

    Leave a comment:


  • agd5f
    replied
    For compiz or any other GL compositor, they need to check the max texture size supported by the hardware before starting; unfortunately, they usually don't. The max texture size on r3xx/r4xx is 2048 pixels so if you desktop is larger than that, you will have display issues regardless of what driver you use.

    Leave a comment:


  • bridgman
    replied
    Mez', when you "fall back to the classic mesa stack" does that also involve going back to UMS/DRI1 or are you still running KMS/DRI2, just with the classic mesa driver ?

    Leave a comment:


  • barkas
    replied
    The main problem I have is terrible lag with gallium. Apart from that it runs significantly faster than plain old mesa.
    But that doesnt help much if it trails an estimated 300ms behind my input.

    Leave a comment:


  • marek
    replied
    Today I was able to make Enemy Territory: Quake Wars work seemlessly with graphics details set on "Normal" and this is a 2008 game with a very advanced rendering engine so I wouldn't say it's worse than other radeon drivers.

    I think the stability of Compiz is more influenced by the DRI state tracker than anything else, but I might be wrong. If you can somehow get a backtrace, please create a bug in the FDO bugzilla with the backtrace attached.

    We know about the hardlocks on RV410 but it looks like no developer has a clue about what goes wrong there (and I don't think any r300g developer uses this chipset).

    Leave a comment:

Working...
X