Announcement

Collapse
No announcement yet.

Open-Source 2D, 3D For ATI Radeon HD 5000 Series GPUs

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

  • rohcQaH
    replied
    difficult to say what you're running into without a screenshot.

    The kernel-patch from this bug solves some corruption issues. It hasn't been merges as of .36-rc4, so you'll need to apply it manually.

    Leave a comment:


  • DuSTman
    replied
    Just tried out the most recent code, and I'm running into a little corruption, most reproducably in the KDE game KNetwalk when you rotate a tile.

    Leave a comment:


  • pingufunkybeat
    replied
    Originally posted by agd5f View Post
    I think the last two major issues for getting on par with r6xx/r7xx are fixing mipmaps and stencil buffers.
    Speaking of stencil buffers, are there any news on this bug:

    https://bugs.freedesktop.org/show_bug.cgi?id=28363

    Other than that, Doom3 works perfectly on r600c. It's surprisingly effective even without dynamic shadows, but you do need them for the full experience, though.

    Leave a comment:


  • bridgman
    replied
    OK, so we need a word that describes the aggregate difficulty associated with supporting a new GPU family, including (among other things) degree of hardware change, completeness and accuracy of hardware documentation, trail of breadcrumbs left by driver teams (software documentation), other things going on at the same time... I guess PITA-ness is probably as close as we're going to get.

    Anyways, those numbers only work if you assume the next few generations of hardware follow an "equiPITA" curve

    Leave a comment:


  • smitty3268
    replied
    Originally posted by bridgman View Post
    Yep, and that's how it happened. Roughly ~31 months from launch to GL2 for 6xx, ~19 months for 7xx, <12 months for Evergreen... although it was arguably more like 8 months since work didn't really start until the end of 2009.
    31, 19, 12. How does this series end?

    Clearly 7, 5, 2, 0.

    So, Bridgman has officially confirmed Fusion support coming next April!

    Leave a comment:


  • bridgman
    replied
    ... and no, we're not going to make any schedule estimates for chips we haven't even launched yet

    Leave a comment:


  • bridgman
    replied
    Originally posted by darkbasic View Post
    They told the same thing with "evergreen" -.-
    Yep, and that's how it happened. Roughly ~31 months from launch to GL2 for 6xx, ~19 months for 7xx, <12 months for Evergreen... although it was arguably more like 8 months since work didn't really start until the end of 2009.

    Leave a comment:


  • agd5f
    replied
    I think the last two major issues for getting on par with r6xx/r7xx are fixing mipmaps and stencil buffers.

    Leave a comment:


  • rohcQaH
    replied
    Originally posted by agd5f View Post
    geartrain looks fine here
    Just booted into the oss drivers again and re-checked, now it looks fine. Weird.
    Originally posted by agd5f View Post
    (other than the problems with the gear teeth on the back gear, but that's a bug in geartrain itself).
    I know, I fixed those Which is the only reason why I cared about geartrain anyway.
    Originally posted by agd5f View Post
    Make sure you 'make clean' before rebuilding.
    gentoo's git ebuilds are a bit more thorough than make clean.


    ioquake3: background-gfx in the menus are broken, but start working after playing a game. The game itself works. Mipmaps seem broken: screenshot.
    Still looks a lot better than these from 5 days ago.
    Strafing doesn't work as well as it used to when I last played it. Surely a driver bug.

    doom3: Went to the menu screen, <1 fps. Didn't enter a game because it's asking about my CD key which I don't have here (where'd my ~/.doom3 go?)

    ut: ~0.5fps, but the intro sequence (ingame-gfx) does render correctly.

    ut2k4: menu works as fast as it should. Starting a game results in
    ut2004-bin: radeon_texture.c:94: radeonFreeTexImageData: Assertion `!image->base.Data' failed.

    I re-tested dynpm. It obediently upped the frequencies to maximum when starting the first game, but didn't lower them again, not even on my desktop with virtually nothing running. Back to profile / low for now.

    I'm pretty sure there's still a nasty bug hidden somewhere, writing to parts of the video memory it shouldn't write to. I experienced it less frequently than before, but there still were small changes (red lines) in some pixmaps after running 3d apps. I wish I knew how to reproduce it or how to boil it down to a testcase :/


    I'm amazed by the amount of complex games that run. Just a few days ago glxgears could force my computer into a reboot, now I can frag stuff. Nice!

    Leave a comment:


  • darkbasic
    replied
    Originally posted by Qaridarium
    but next time the amd-OS driver team will be much faster because the difference on R900 are not so high because its just a refresh on the biggest parts.
    They told the same thing with "evergreen" -.-

    Leave a comment:

Working...
X