On Mon, Apr 10, 2017 at 5:03 AM, Christian König <christian.koenig@xxxxxxx> wrote: > Am 10.04.2017 um 10:52 schrieb Michel Dänzer: >> >> 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.stach@xxxxxxxxxxxxxx >>>> <mailto:l.stach@xxxxxxxxxxxxxx>> 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 >>>> <daniel@xxxxxxxx <mailto:daniel@xxxxxxxx>> wrote: >>>> > > > >>>> > > > On Tue, Apr 4, 2017 at 12:43 PM, Lucas Stach >>>> > > > <l.stach@xxxxxxxxxxxxxx >>>> <mailto:l.stach@xxxxxxxxxxxxxx>> 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? > > > Good question. The crux is that you need to match certain bandwith and > latency limitations or otherwise you get a flickering picture. > > If I understood the documentation correctly that should even work with dGPUs > in theory, but nobody is testing/validating this. > > Long story short I wouldn't try it without feedback from the hardware/DC > guys. They are the designated experts for this. It's only been validated on APUs. Alex > > Regards, > Christian. > >> >> >>> 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. >> >> > > _______________________________________________ > dri-devel mailing list > dri-devel@xxxxxxxxxxxxxxxxxxxxx > https://lists.freedesktop.org/mailman/listinfo/dri-devel _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
