Announcement

Collapse
No announcement yet.

AMD's R300 Gallium3D Driver Is Looking Good For 2011

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

  • rohcQaH
    replied
    he said that there isn't much r300-related work in DRM. There's plenty of work to be done in userspace (mesa).

    Leave a comment:


  • 69acid69
    replied
    oh, well

    Originally posted by marek View Post
    Using drm-radeon-testing no longer makes sense for r300g, there's not much r300-related work, if any. The kernel 2.6.36 should perform well for most users. Running Mesa from master is still recommended because there are some critical r300/compiler fixes from Tom Stellard.
    So, that's mean no more HUGE performance boost in future for r300g series? Only +/- and some bug fix?

    P.S. Guess this http://www.x.org/wiki/RadeonFeature table is outdated.

    Leave a comment:


  • marek
    replied
    Using drm-radeon-testing no longer makes sense for r300g, there's not much r300-related work, if any. The kernel 2.6.36 should perform well for most users. Running Mesa from master is still recommended because there are some critical r300/compiler fixes from Tom Stellard.

    Leave a comment:


  • evil_core
    replied
    Originally posted by pejakm View Post
    Agreed. A simple export command on the command line makes a difference will a windows game work or not. I still have to use classic driver, wine games simply do not work with gallium.
    Thats not True in case of r300g/r500(UXGA T60p). Classic(or even UMS) is much more slower in most games, especially wine(except Ignition). Even CS:Source Video Stresstest run smoothly in Gallium at 1600x1200. UT2K4 also works really good. The only problem is tce, when I were forced to go to 1115x864 to get ~50fps and no lags in action.
    Maybe you miscofnigured wine, or its old? OR you dont have Mesa from master and kernel from drm-radoen-testing?

    Leave a comment:


  • nanonyme
    replied
    Originally posted by marek View Post
    Yes, --with-dri-drivers=x,y,z,... is for classic. --enable-gallium-xxx is for gallium. You don't have to type --enable-gallium-radeon and I recommend you not to do so, because it builds the xorg state tracker powered by r300g, which is unsupported and untested. lib/gallium/r300_dri.so is always built unless you type --disable-gallium-radeon.
    How about replacing the current enabling system with --with-gallium-drivers=r300,r600,llvm and such?

    Leave a comment:


  • agd5f
    replied
    note that the .drirc needs slightly different formatting for dri2 drivers. E.g.,

    <driconf>
    <device screen="0" driver="dri2">
    <application name="Default">
    <option name="vblank_mode" value="0" />
    </application>
    </device>
    </driconf>

    Leave a comment:


  • 69acid69
    replied
    Originally posted by agd5f View Post
    set env var vblank_mode=0 or set it in your .drirc.
    Did not help at all, still the same result.

    Leave a comment:


  • agd5f
    replied
    Originally posted by 69acid69 View Post
    Thanks for the detailed explanation marek. And one more thing, is there any possibility to turn off vsync? I mean to add some flag in build command line?
    set env var vblank_mode=0 or set it in your .drirc.

    Leave a comment:


  • agd5f
    replied
    Originally posted by bridgman View Post
    I'm not sure if the CMASK info turned out to be useful... there was some hope of using it for faster clears but don't remember if that actually worked out.
    CMASK is only applicable to MSAA buffers which are not implemented yet.

    Leave a comment:


  • 69acid69
    replied
    Thanks for the detailed explanation marek. And one more thing, is there any possibility to turn off vsync? I mean to add some flag in build command line?

    Leave a comment:

Working...
X