CS Memory Accounting For Radeon Gallium3D
With the Radeon Gallium3D driver (and Mesa/Gallum3D drivers in generally) finally moving on to properly handling more visually demanding and modern OpenGL games and other workloads, it's time for CS memory accounting to be implemented within the open-source driver.
Jerome Glisse implemented support today in R600g for basic CS memory usage accounting, per this commit. The memory usage accounting basically comes down to making sure what's submitted to the GPU doesn't end up going over the video RAM and GTT size. Right now the check is seeing that the submission doesn't go over 70% the GTT+vRAM size to allow for some memory fragmentation.
The commit description explains, " The idea is to compute a gross estimate of memory requirement of each draw call. After each draw call, memory will be precisely accounted. So the uncertainty is only on the current draw call. In practice this gave very good estimate (+/- 10% of the target memory limit)."
Jerome Glisse implemented support today in R600g for basic CS memory usage accounting, per this commit. The memory usage accounting basically comes down to making sure what's submitted to the GPU doesn't end up going over the video RAM and GTT size. Right now the check is seeing that the submission doesn't go over 70% the GTT+vRAM size to allow for some memory fragmentation.
The commit description explains, " The idea is to compute a gross estimate of memory requirement of each draw call. After each draw call, memory will be precisely accounted. So the uncertainty is only on the current draw call. In practice this gave very good estimate (+/- 10% of the target memory limit)."
6 Comments