R600g Driver Patch That Can 4x The Frame-Rate

[marek]

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.

[Sidicas]

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?

[ryszardzonk]

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

[agd5f]

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.

[agd5f]

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.

[gamerk2]

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?).

[agd5f]

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.

[sobkas]

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:

[marek]

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.).

[madbiologist]

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.