[PATCH RFC 00/24] Lima DRM driver

Christian K├Ânig christian.koenig at amd.com
Thu May 24 09:53:54 UTC 2018

Am 24.05.2018 um 09:25 schrieb Daniel Vetter:
> [SNIP]
>>> Does virtio drm driver need to move buffers around? amdgpu also
>>> has no vram when APU.
> Afaiui APUs have a range of stolen memory which looks and acts and is
> managed like discrete vram. Including moving buffers around.

BTW: We are actually working on getting rid of that. E.g. the only thing 
modern APUs need this stolen VRAM for are page tables, and it's just a 
matter of my time to fix this.

>>>>   From your description you don't have such a requirement, and
>>>> then doing what etnaviv has done would be a lot simpler. Everything
>>>> that's not related to buffer movement handling is also available
>>>> outside of ttm already.
>>> Yeah, I could do like etnaviv, but it's not simpler than using ttm
>>> directly especially want some optimization (like ttm page pool,
>>> ttm_eu_reserve_buffers, ttm_bo_mmap). If I have/want to implement
>>> them, why not just use TTM directly with all those helper functions.
>> Well TTM has some design flaws (e.g. heavily layered design etc...), but it
>> also offers some rather nice functionality.
> Yeah, but I still think that for non-discrete drivers just moving a
> bunch of more of the neat ttm functionality into helpers where
> everyone can use them (instead of the binary ttm y/n decision) would
> be much better. E.g. the allocator pool definitely sounds like
> something gem helpers should be able to do, same for reserving a pile
> of buffers or default mmap implementations. A lot of that also exists
> already, thanks to lots of efforts from Noralf Tronnes and others.
> I think ideally the long-term goal would be to modularize ttm concepts
> as much as possible, so that drivers can flexibly pick&choose the bits
> they need. We're slowly getting there (but definitely not yet there if
> you need to manage discrete vram I think).

Yes, completely agree. It's just that nobody had time for that.

Especially the different memory pools should be cleaned up and moved 
into a common DRM functionality or even into the DMA or directly the MM 

E.g. an interface like: I'm device X and need memory which is 
cached/uncached/wc please allocate something for me.


More information about the dri-devel mailing list