On 03.08.2016 05:47, Dave Airlie wrote:
Because no hw is the same once you go beyond that.
hmm, it doesn't seem to be so extremly different, that we cant at least abstract some common aspects.
Video memory size means what? VRAM, GPU accessible system RAM, amount of CPU visible VRAM?
Actually, these are separate things, which of course should be reported in separate fields:
* phys_aperture_size: --> physical maximum for the shared ram between cpu and gpu (cpu-accessible gpu-memory) * avail_aperture_size: --> the logical maximum that the process can map --> might be lower than phys_..., eg. due to process limits or when running a 32bit userland on 64bit kernel * phys_gpu_memory_size: --> the total size of gpu's memory (that could be accessed by cpu) --> might be larger than phys_aperture_size / avail_aperture_size when gpu just has more memory than can be shared w/ cpu --> eg. an interesting indicator on how much can be filled w/ readonly textures (which dont need to be cpu-accessible anymore) * avail_gpu_memory_size: --> the logical maximum that process can consume * phys_shm_size: --> max size of shared system memory (directly accessible b both gpu and cpu) --> commonly available on SoCs - on other hw might be zero --> not counting on-board RAM that is hw-mapped to the GPU, thus not falling into system memory in the first place.
IMHO, that should catch all usual scenarios, from the fat gamer-GPU boards to tiny SoCs ... did I miss something here ?
In the end, these values only seem to be used as some statistics for the userland's decision on much stuff it uploads to the GPU.
By the way: what about resource limits ? Can we control, how much GPU memory an unprivileged process can consume, in order to prevent DOS'ing other processes (even other users) ?
--mtx