<div dir="ltr">On 2 July 2013 12:03, Chris Wilson <span dir="ltr"><<a href="mailto:chris@chris-wilson.co.uk" target="_blank">chris@chris-wilson.co.uk</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Tue, Jul 02, 2013 at 12:00:48PM -0700, Paul Berry wrote:<br>
> On 28 June 2013 15:39, Chris Wilson <[1]<a href="mailto:chris@chris-wilson.co.uk">chris@chris-wilson.co.uk</a>> wrote:<br>
><br>
> On Fri, Jun 28, 2013 at 03:23:31PM -0700, Ben Widawsky wrote:<br>
> > This series originated from the request from Paul, "can you enable<br>
> page<br>
> > faults"? �After some though and discussion, we came up with 3 debug<br>
> features to<br>
> > implement:<br>
><br>
> The issue lies in that the CS and EU units like to prefetch 128 bytes<br>
> and will cross page boundaries. Userspace is rather lax in providing the<br>
> extra page (or preventing the read past the end of its bo) and so<br>
> without adding a sentinel page behind every bo you quickly generate<br>
> false positives. (Unless you also run a fixed userspace).<br>
><br>
> If you are prepared to fix userspace, tweaking the kernel not to install<br>
> scratch pages everywhere is trivial.<br>
><br>
> Mesa already adds the necessary padding to EU programs to ensure that<br>
> prefetch won't cause a page fault, and because of its "stack and heap"<br>
> model for batch buffers, CS prefetching shouldn't cause a page fault<br>
> either.� I don't know whether the 2D drivers do something similar, so they<br>
> might potentially need fixing.<br>
<br>
</div>You do not on the BLT ring, and have not done historically. The EU is no<br>
longer padded. We have been purposely lax in this area.<br>
<div class="HOEnZb"><div class="h5">-Chris<br></div></div></blockquote><div><br></div><div>You're right--I didn't realize that we removed the EU padding, and I wasn't thinking about the BLT code.<br></div></div>
</div></div>