<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sat, Jul 8, 2017 at 12:18 PM, Matt Turner <span dir="ltr"><<a href="mailto:mattst88@gmail.com" target="_blank">mattst88@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Sat, Jul 8, 2017 at 11:05 AM, Jason Ekstrand <<a href="mailto:jason@jlekstrand.net">jason@jlekstrand.net</a>> wrote:<br>
> On July 7, 2017 1:52:54 PM Chris Wilson <<a href="mailto:chris@chris-wilson.co.uk">chris@chris-wilson.co.uk</a>> wrote:<br>
><br>
>> Quoting Jason Ekstrand (2017-07-07 21:37:29)<br>
>>><br>
>>> The reason we were doing this was to ensure that the kernel did the<br>
>>> appropriate cross-ring synchronization and flushing.  However, the<br>
>>> kernel only looks at EXEC_OBJECT_WRITE to determine whether or not to<br>
>>> insert a fence.  It only cares about the domain for determining whether<br>
>>> or not it needs to clflush the BO before using it for scanout but the<br>
>>> domain automatically gets set to RENDER internally by the kernel if<br>
>>> EXEC_OBJECT_WRITE is set.<br>
>><br>
>><br>
>> Once upon a time we also depended upon EXEC_OBJECT_WRITE for correct<br>
>> swapout. That was until I saw what you were planning to do for anv. Hmm,<br>
>> that puts the oldest kernel that might support anv as<br>
>><br>
>> commit 51bc140431e233284660b1d22c47de<wbr>c9ecdb521e [v4.3]<br>
>> Author: Chris Wilson <<a href="mailto:chris@chris-wilson.co.uk">chris@chris-wilson.co.uk</a>><br>
>> Date:   Mon Aug 31 15:10:39 2015 +0100<br>
>><br>
>>     drm/i915: Always mark the object as dirty when used by the GPU<br>
><br>
><br>
> I think we're probably ok there.  We have a hard requirement on memfd which<br>
> I think landed in 4.6 though I could be wrong about that.<br>
<br>
</span>No. memfd_create was added in 3.17.<br>
</blockquote></div><br></div><div class="gmail_extra">Bah.  I don't know why 4.6 is stuck in my brain as being important but it is. :-/  In any case, is there some way we can check for that commit?  Otherwise, I think the only real thing we can do is just hope you don't swap and accept corruption if you do. :-(<br><br></div><div class="gmail_extra">--Jason<br></div></div>