Hi, > Stuf like driver load/unload, suspend/resume, runtime pm and gpu reset are > already supre-fragile as-is. Every time we change something in there, a > bunch of related things fall apart. With vgt we'll have even more > complexity in there, and I really think we need to make that complexity > explicit. Otherwise we'll always break vgt support for host systems by > accident when working on upstream. So in my experience being explicit with > these depencies massively reduces maintaince headaches longterm. I think that makes sense. vGT can leave alot of the lowlevel work such as power management to i915 then, so we don't duplicate that code in vGT and i915. Stacking vGT on top of i915 also makes it alot easier to have it a runtime option (just an additional kernel module you load when you need it). Other way around vGT would be a hard dependency for i915, even if you don't use it (you could compile it out probably, but distro kernels can't do that if they want support vGT). Another note: Right now the guest display can only be sent to one of the crtcs. Long term I want more options there, such as exporting the guest display as dma-buf on the host so it can be blitted to some window. Or even let the gpu encode the guest display as video, so we can send it off over the network. I suspect that is also easier to implement if i915 manages all resources and vGT just allocates from i915 what it needs for the guest. cheers, Gerd _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
