Printable View
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?.Quote:
Originally Posted by marek
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?
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 :(Quote:
Originally Posted by marek
It's much easier to isolate a regression using git bisect.Quote:
Originally Posted by ryszardzonk
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.Quote:
Originally Posted by Sidicas
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?).Quote:
Originally Posted by Sidicas
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.Quote:
Originally Posted by gamerk2
Can you try setting R600_LLVM to 0, because running glxgerars with R600_LLVM=1 produces this:Quote:
Originally Posted by ryszardzonk
https://lh4.googleusercontent.com/-a...0/glxgears.png
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.).Quote:
Originally Posted by Sidicas
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.Quote:
Originally Posted by Sidicas