<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Tue, Apr 4, 2017 at 9:53 PM Daniel Vetter <<a href="mailto:daniel@ffwll.ch">daniel@ffwll.ch</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Tue, Apr 4, 2017 at 12:43 PM, Lucas Stach <<a href="mailto:l.stach@pengutronix.de" class="gmail_msg" target="_blank">l.stach@pengutronix.de</a>> wrote:<br class="gmail_msg">
>> If I could guarantee that I'd only ever run on 4.13-or-later kernels<br class="gmail_msg">
>> (I think that's when the previous patches will land?), then this would<br class="gmail_msg">
>> indeed be mostly unnecessary. It would save me a bunch of addfb calls<br class="gmail_msg">
>> that would predictably fail, but they're cheap.<br class="gmail_msg">
><br class="gmail_msg">
> I don't think we ever had caps for "things are working now, as they are<br class="gmail_msg">
> supposed to". i915 wasn't properly synchronizing on foreign fences for a<br class="gmail_msg">
> long time, yet we didn't gain a cap for "cross device sync works now".<br class="gmail_msg">
><br class="gmail_msg">
> If your distro use-case relies on those things working it's probably<br class="gmail_msg">
> best to just backport the relevant fixes.<br class="gmail_msg">
<br class="gmail_msg">
The even better solution for this is to push the backports through<br class="gmail_msg">
upstream -stable kernels. This stuff here is simple enough that we can<br class="gmail_msg">
do it. Same could have been done for the fairly minimal fencing fixes<br class="gmail_msg">
for i915 (at least some of them, the ones in the page-flip).<br class="gmail_msg">
<br class="gmail_msg">
Otherwise we'll end up with tons IM_NOT_BUGGY and<br class="gmail_msg">
IM_SLIGHTLY_LESS_BUGGY and IM_NOT_BUGGY_EXCEPT_THIS_BOTCHED_BACKPORT<br class="gmail_msg">
flags where no one at all knows what they mean, usage between<br class="gmail_msg">
different drivers and different userspace is entirely inconsistent and<br class="gmail_msg">
they just all add to the confusion. They're just bugs, lets treat them<br class="gmail_msg">
like that.<br class="gmail_msg"></blockquote><div><br></div><div>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.<br><br></div><div>But calling addfb2 and it failing is not expensive, so this is rather niche.<br><br></div><div>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.<br></div></div></div>