Page 2 of 5 FirstFirst 1234 ... LastLast
Results 11 to 20 of 41

Thread: R600g Driver Patch That Can 4x The Frame-Rate

  1. #11
    Join Date
    Jan 2009
    Posts
    596

    Default

    Well, don't get too happy yet. I only replaced one heuristic with some other one. It's possible it will behave worse in some other app, who knows. Buffer placements are not a solved problem yet. We need a solution that is more robust in extreme scenarios.

  2. #12
    Join Date
    Jun 2011
    Posts
    315

    Default

    Quote Originally Posted by marek View Post
    Well, don't get too happy yet. I only replaced one heuristic with some other one. It's possible it will behave worse in some other app, who knows. Buffer placements are not a solved problem yet. We need a solution that is more robust in extreme scenarios.
    More specifically.. If the game is VRAM starved then the performance would go down by some unknown amount with this patch, right? If it's not VRAM starved, the performance would go up by 4x or more with this patch, correct?. So it's just trading apples for oranges, although it certainly seems better to assume that the user has bought enough VRAM to play the games they're trying to play, it's certainly possible some users with cheaper hardware are better off without this patch, right?.

    Somebody should try benchmarking the patch with an R600 GPU that has very little VRAM.

    Do all the open source graphics drivers have these buffer heuristics problems?
    Last edited by Sidicas; 11-01-2012 at 10:30 AM.

  3. #13
    Join Date
    Mar 2011
    Posts
    87

    Default

    Quote Originally Posted by marek View Post
    Well, don't get too happy yet.
    Well spoken Actually mesa is borked for me with present git master as the gdm login screen shows only garbage, which I believe did not happen like that in the long time. I am not sure what happen within the last two days for r600 [AMD E-350] but I am emerging (Gentoo package management) commit by commit to see what made my screen like that... However it is not this patch as I am already few commits back with checking and it is still there

  4. #14
    Join Date
    Dec 2007
    Posts
    2,272

    Default

    Quote Originally Posted by ryszardzonk View Post
    Well spoken Actually mesa is borked for me with present git master as the gdm login screen shows only garbage, which I believe did not happen like that in the long time. I am not sure what happen within the last two days for r600 [AMD E-350] but I am emerging (Gentoo package management) commit by commit to see what made my screen like that... However it is not this patch as I am already few commits back with checking and it is still there
    It's much easier to isolate a regression using git bisect.

  5. #15
    Join Date
    Dec 2007
    Posts
    2,272

    Default

    Quote Originally Posted by Sidicas View Post
    Do all the open source graphics drivers have these buffer heuristics problems?
    Potentially all drivers for hardware with different memory pools with different performance trade-offs. Additionally, besides, the total amount of vram on a card, the amount of vram used by other user apps will affect this to a certain degree.
    Last edited by agd5f; 11-01-2012 at 10:59 AM.

  6. #16
    Join Date
    Jun 2012
    Posts
    306

    Default

    Quote Originally Posted by Sidicas View Post
    More specifically.. If the game is VRAM starved then the performance would go down by some unknown amount with this patch, right? If it's not VRAM starved, the performance would go up by 4x or more with this patch, correct?. So it's just trading apples for oranges, although it certainly seems better to assume that the user has bought enough VRAM to play the games they're trying to play, it's certainly possible some users with cheaper hardware are better off without this patch, right?.

    Somebody should try benchmarking the patch with an R600 GPU that has very little VRAM.

    Do all the open source graphics drivers have these buffer heuristics problems?
    That was my initial thought as well: If this change will ALWAYS put the resources in VRAM, what happens if you are VRAM starved (or worse: Don't have enough free VRAM to honor the request?).

  7. #17
    Join Date
    Dec 2007
    Posts
    2,272

    Default

    Quote Originally Posted by gamerk2 View Post
    That was my initial thought as well: If this change will ALWAYS put the resources in VRAM, what happens if you are VRAM starved (or worse: Don't have enough free VRAM to honor the request?).
    The kernel driver will attempt to free up enough vram to honor the request by migrating other buffers out of vram, but if there is still not enough room, you'll end up with gart. Depending on how much migration has to take place, it's sometimes better to just use gart in the first place. There are no simple answers.

  8. #18
    Join Date
    Jun 2006
    Location
    Poland
    Posts
    107

    Default

    Quote Originally Posted by ryszardzonk View Post
    Well spoken Actually mesa is borked for me with present git master as the gdm login screen shows only garbage, which I believe did not happen like that in the long time. I am not sure what happen within the last two days for r600 [AMD E-350] but I am emerging (Gentoo package management) commit by commit to see what made my screen like that... However it is not this patch as I am already few commits back with checking and it is still there
    Can you try setting R600_LLVM to 0, because running glxgerars with R600_LLVM=1 produces this:

  9. #19
    Join Date
    Jan 2009
    Posts
    596

    Default

    Quote Originally Posted by Sidicas View Post
    More specifically.. If the game is VRAM starved then the performance would go down by some unknown amount with this patch, right? If it's not VRAM starved, the performance would go up by 4x or more with this patch, correct?. So it's just trading apples for oranges, although it certainly seems better to assume that the user has bought enough VRAM to play the games they're trying to play, it's certainly possible some users with cheaper hardware are better off without this patch, right?.
    If the game is VRAM starved, TTM will do a lot of buffer moves to satisfy r600g wanting buffers in VRAM, possibly moving some buffers out. The same happens when those other buffers are used. Yeah, the time spent on rendering can be lower than the time spent on buffer moves. The problem with the current implementation is it doesn't honor the initial placement when we run out of memory and then some memory is freed. I would expect some buffers to be moved back to their initial location, which isn't happening. Also we should evict buffers based on how they're used (colorbuffer or texture, index buffer, etc.).

  10. #20
    Join Date
    Oct 2009
    Location
    Brisbane, Queensland, Australia
    Posts
    145

    Default

    Quote Originally Posted by Sidicas View Post
    More specifically.. If the game is VRAM starved then the performance would go down by some unknown amount with this patch, right? If it's not VRAM starved, the performance would go up by 4x or more with this patch, correct?. So it's just trading apples for oranges, although it certainly seems better to assume that the user has bought enough VRAM to play the games they're trying to play, it's certainly possible some users with cheaper hardware are better off without this patch, right?.

    Somebody should try benchmarking the patch with an R600 GPU that has very little VRAM.
    According to the tables at http://en.wikipedia.org/wiki/Compari...3xxx.29_series the Radeon HD 2400 Pro (RV610) was available with 128MB or 256MB or 512MB of DDR2 VRAM. All other desktop/discrete R600 hardware has 256MB or more. In the mobility segment, the Mobility Radeon X2300 and the Mobility Radeon HD 2300 (RV515) were available with 128MB (as well as 256MB and 512MB for the Mobility Radeon HD 2300), with everything else having 256MB or more.

Posting Permissions

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