RFC: hardware accelerated bitblt using dma engine

[Enrico Weigelt, metux IT consult]

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