On Wed, 5 Apr 2017 at 20:14 Lucas Stach wrote: > Am Mittwoch, den 05.04.2017, 11:59 +0200 schrieb Daniel Vetter: > > On Wed, Apr 05, 2017 at 10:15:44AM +0200, Lucas Stach wrote: > > > Am Mittwoch, den 05.04.2017, 00:20 +0000 schrieb Christopher James > Halse > > > Rogers: > > > > > > > > > > > > On Tue, Apr 4, 2017 at 9:53 PM Daniel Vetter > wrote: > > > > > > > > On Tue, Apr 4, 2017 at 12:43 PM, Lucas Stach > > > > wrote: > > > > >> If I could guarantee that I'd only ever run on > > > > 4.13-or-later kernels > > > > >> (I think that's when the previous patches will land?), > then > > > > this would > > > > >> indeed be mostly unnecessary. It would save me a bunch of > > > > addfb calls > > > > >> that would predictably fail, but they're cheap. > > > > > > > > > > I don't think we ever had caps for "things are working now, > > > > as they are > > > > > supposed to". i915 wasn't properly synchronizing on foreign > > > > fences for a > > > > > long time, yet we didn't gain a cap for "cross device sync > > > > works now". > > > > > > > > > > If your distro use-case relies on those things working it's > > > > probably > > > > > best to just backport the relevant fixes. > > > > > > > > The even better solution for this is to push the backports > > > > through > > > > upstream -stable kernels. This stuff here is simple enough > > > > that we can > > > > do it. Same could have been done for the fairly minimal > > > > fencing fixes > > > > for i915 (at least some of them, the ones in the page-flip). > > > > > > > > Otherwise we'll end up with tons IM_NOT_BUGGY and > > > > IM_SLIGHTLY_LESS_BUGGY and > > > > IM_NOT_BUGGY_EXCEPT_THIS_BOTCHED_BACKPORT > > > > flags where no one at all knows what they mean, usage between > > > > different drivers and different userspace is entirely > > > > inconsistent and > > > > they just all add to the confusion. They're just bugs, lets > > > > treat them > > > > like that. > > > > > > > > > > > > It's not *quite* DRM_CAP_PRIME_SCANOUT_NOT_BUGGY - while the relevant > > > > hardware allegedly supports it, nouveau/radeon/amdgpu don't do > scanout > > > > of GTT, so the lack of this cap indicates that there's no point in > > > > trying to call addfb2. > > > > > > > > > > > > But calling addfb2 and it failing is not expensive, so this is rather > > > > niche. > > > > > > > > > > > > In practice I can just restrict attempting to scanout of imported > > > > buffers to i915, as that's the only driver that it'll work on. By the > > > > time nouveau/radeon/amdgpu get patches to scanout of GTT the fixes > > > > should be old enough that I don't need to care about unfixed kernels. > > > > > > > So given that most discreet hardware won't ever be able to scanout from > > > GTT (latency and iso requirements will be hard to meet), can't we just > > > fix the case of the broken prime sharing when migrating to VRAM? > > > > > > I'm thinking about attaching an exclusive fence to the dma-buf when the > > > migration to VRAM happens, then when the GPU is done with the buffer we > > > can either write back any changes to GTT, or just drop the fence in > case > > > the GPU didn't modify the buffer. > > > > We could, but someone needs to type the code for it. There's also the > > problem that you need to migrate back, and then doing all that behind > > userspaces back might not be the best idea. > > Drivers with separate VRAM and GTT are already doing a lot of migration > behind the userspaces back. The only issue with dma-buf migration to > VRAM is that you probably don't want to migrate the pages, but duplicate > them in VRAM, doubling memory consumption with possible OOM. But then > you could alloc the memory on addfb where you are able to return proper > errors. Hm. So, on a first inspection, this looks like something I could actually cook up. Looking at amdgpu it seems like the thing to do would be to associate a shadow-bo in VRAM for the imported dma-buf in the addfb call, then pin-and-copy-to the shadow bo in the places where the bo is currently pinned. Is this approach likely to be acceptable?