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
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
