Re: [PATCH 1/2] drm: Add DRM_CAP_PRIME_SCANOUT.

["Christian König" <christian.koenig@amd.com>]

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@pengutronix.de
>>> <mailto:l.stach@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
>>>      <daniel@ffwll.ch <mailto:daniel@ffwll.ch>> wrote:
>>>      > > >
>>>      > > >         On Tue, Apr 4, 2017 at 12:43 PM, Lucas Stach
>>>      > > >         <l.stach@pengutronix.de
>>>      <mailto:l.stach@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?

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.

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@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel