On 05/04/17 08:21 PM, Christian König wrote: > Am 05.04.2017 um 13:13 schrieb Christopher James Halse Rogers: >> On Wed, Apr 5, 2017 at 8:14 PM Lucas Stach <l.st...@pengutronix.de >> <mailto:l.st...@pengutronix.de>> 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 >> <dan...@ffwll.ch <mailto:dan...@ffwll.ch>> wrote: >> > > > >> > > > On Tue, Apr 4, 2017 at 12:43 PM, Lucas Stach >> > > > <l.st...@pengutronix.de >> <mailto:l.st...@pengutronix.de>> 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? >> >> >> At least some nouveau and AMD devs seem to think that their hardware >> is capable of doing it. Shrug. > > Wow, wait a second. Recent AMD GPU can scanout from system memory, > that's true.
Even discrete GPUs, or only APUs? > But you need to met quite a bunch of special allocation requirements to > do this. > > When we are talking about sharing between AMD GPUs, (e.g. both exporter > and importer are AMD hardware) than that might work. > > But I think it's unrealistic that an imported BO (created by an external > driver stack) will ever meet those requirements. Indeed. Also, none of the GPUs supported by the radeon driver support this. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
