Re: [PATCH RFC 00/24] Lima DRM driver

From: "Christian König" <christian.koenig@amd.com>
To: Daniel Vetter <daniel@ffwll.ch>
Cc: Simon Shields <simon@lineageos.org>,
	devicetree@vger.kernel.org, Connor Abbott <cwabbott0@gmail.com>,
	Marek Vasut <marex@denx.de>,
	Neil Armstrong <narmstrong@baylibre.com>,
	Andrei Paulau <7134956@gmail.com>,
	dri-devel <dri-devel@lists.freedesktop.org>,
	Vasily Khoruzhick <anarsoul@gmail.com>,
	Qiang Yu <yuq825@gmail.com>, Erico Nunes <nunes.erico@gmail.com>
Subject: Re: [PATCH RFC 00/24] Lima DRM driver
Date: Thu, 24 May 2018 11:53:54 +0200	[thread overview]
Message-ID: <8e50b92d-6475-3f54-998d-fe6a4bd783b6@amd.com> (raw)
In-Reply-To: <CAKMK7uFHpX12RKJewZmSBnTgpcAvr9OpLgyYL__RGQW7vqkJYQ@mail.gmail.com>

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 
subsystem.

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

Regards,
Christian.
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel