[PATCH 1/2] drm: Add DRM_CAP_PRIME_SCANOUT.

[Alex Deucher]

On Mon, Apr 10, 2017 at 5:03 AM, Christian König
<christian.koenig at amd.com> 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 at pengutronix.de
>>>> <mailto:l.stach at 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 at ffwll.ch <mailto:daniel at ffwll.ch>> wrote:
>>>>      > > >
>>>>      > > >         On Tue, Apr 4, 2017 at 12:43 PM, Lucas Stach
>>>>      > > >         <l.stach at pengutronix.de
>>>>      <mailto:l.stach at 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.

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