[PATCH 1/2] drm: Add DRM_CAP_PRIME_SCANOUT.

[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?


> 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