On Wed, 2021-10-13 at 14:50 +0200, Daniel Vetter wrote: > On Tue, Oct 12, 2021 at 05:34:50PM +0000, Zack Rusin wrote: > > > On the flip side that does mean that vmwgfx and i915 need to redo > > some > > code. For vmwgfx it's probably a net positive anyway as we've been > > using TTM for, what is really nowadays, an integrated GPU so maybe > > it's > > time for us to think about transition to gem. > > Aside, but we're looking at adopting ttm for integrated gpu too. The > execbuf utils and dynamic memory management helpers for pure gem just > aren't quite there yet, and improving ttm a bit in this area looks > reasonable (like adding a unified memory aware shrinker like we have > in > i915-gem). >
That would certainly be a big help. The situation that I want to avoid is having vmwgfx using TTM for what no other driver is using it for. > Also I thought vmwgfx is using ttm to also manage some id spaces, > you'd > have to hand-roll that. Yes, it's work either way, it's likely less code with GEM but we'd lose support for 3D on older hardware where our device did have dedicated VRAM. Nowadays memory management in our device is rather trivial: every GPU object is just kernel virtual memory. To allow our virtual device to write into that memory we send it an identifier to be able to name the object (we use id's but it could be just the kernel virtual address as integer) plus a page table because, of course, vmx can't read guest kernel's page tables so we need to map the kernel virtual address space to physical addresses so that the host can write into them. So mm in vmwgfx shouldn't require performance enhancing drugs to understand and drug usage while writing vmwgfx code should remain purely recreational ;) z
