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

[Christopher James Halse Rogers <chris@cooperteam.net>]

[-- Attachment #1.1: Type: text/plain, Size: 2852 bytes --]



On Wed, Apr 5, 2017 at 4:27 PM, Daniel Vetter <daniel@ffwll.ch> wrote:
> On Wed, Apr 05, 2017 at 12:20:46AM +0000, Christopher James Halse 
> Rogers wrote:
>>  On Tue, Apr 4, 2017 at 9:53 PM Daniel Vetter <daniel@ffwll.ch> 
>> wrote:
>> 
>>  > On Tue, Apr 4, 2017 at 12:43 PM, Lucas Stach 
>> <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.
> 
> "I'll only run on i915" sounds like a rather risky assumption. You're 
> sure
> no one will install ubuntu on e.g. rasperry with Eric's shiny new 
> pl111
> driver?
> 
> I really think that if you want to rely on this, backporting the 
> fixes is
> perfectly fine.

Oh, no! I mean *check* that I'm running on i915, and only use the 
no-copy path if I am.

Backporting the patches would indeed be sensible. I guess I should have 
CC: stable'd at the time.

[-- Attachment #1.2: Type: text/html, Size: 3203 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel