<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Apr 15, 2014 at 1:18 PM, Eric Anholt <span dir="ltr"><<a href="mailto:eric@anholt.net" target="_blank">eric@anholt.net</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">Kenneth Graunke <<a href="mailto:kenneth@whitecape.org">kenneth@whitecape.org</a>> writes:<br>
<br>
> On 04/14/2014 05:33 PM, Eric Anholt wrote:<br>
>> This manifested as rendering failures or sometimes GPU hangs in<br>
>> compositors when they accidentally got MSAA visuals due to a bug in the X<br>
>> Server.  Today we decided that the problem in compositors was equivalent<br>
>> to a corruption bug we'd noticed recently in resizing MSAA-visual<br>
>> glxgears, and debugging got a lot easier.<br>
>><br>
>> When we allocate our MCS MT, libdrm takes the size we request, aligns it<br>
>> to Y tile size (blowing it up from 300x300=900000 bytes to 384*320=122880<br>
>> bytes, 30 pages), then puts it into a power-of-two-sized BO (131072 bytes,<br>
>> 32 pages).  Because it's Y tiled, we attach a 384-byte-stride fence to it.<br>
>> When we memset by the BO size in Mesa, between bytes 122880 and 131072 the<br>
>> data gets stored to the first 20 or so scanlines of each of the 3 tiled<br>
>> pages in that row, even though only 2 of those pages were allocated by<br>
>> libdrm.<br>
><br>
> What?<br>
><br>
> I get that drm_intel_bo_alloc/drm_intel_bo_alloc_tiled might return a<br>
> drm_intel_bo where bo->size is larger than what you asked for, due to<br>
> the BO cache.  But...what you're saying is, it doesn't actually allocate<br>
> enough pages to back the whole bo->size it gives you?  So, if you write<br>
> bytes 0..(bo->size - 1), you'll randomly clobber memory in a way that's<br>
> really difficult to detect?<br>
<br>
</div>You have that many pages, really.  But you've attached a fence to it, so<br>
your allocated pages are structured as:<br>
<br>
+---+---+---+<br>
|   |   |   |<br>
+---+---+---+<br>
|   |   |   |<br>
+---+---+---+<br>
|   |   |   |<br>
+---+---+---+<br>
|   |   |<br>
+---+---+<br>
<br>
(except taller in this specific example).  If you hit the pixels in<br>
those quads, you'll be fine.<br>
<div class=""><br>
><br>
> There are other places where we memset an entire BO using bo->size.  For<br>
> example, your INTEL_DEBUG=shader_time code does exactly that (though it<br>
> isn't tiled).<br>
><br>
> Could we change libdrm to set bo->size to the actual usable size of the<br>
> buffer, rather than the bucket size?<br>
<br>
</div>The pages containing pixels you asked for go to 122880, and the BO is<br>
131072, but the pixels you asked for have a maximum linear address of<br>
384*320=115200.  Which value are you thinking is the "actual usable<br>
size"?  We certainly shouldn't have been memsetting more pixels than<br>
115200.<br></blockquote><div><br></div><div>Why not? I understand that it's not useful to touch pixels beyond 115200, but from the data structure, we were given 131072 bytes to work with. Why shouldn't memsetting the entire allocated space be a safe operation?</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>_______________________________________________<br>
mesa-stable mailing list<br>
<a href="mailto:mesa-stable@lists.freedesktop.org">mesa-stable@lists.freedesktop.org</a><br>
<a href="http://lists.freedesktop.org/mailman/listinfo/mesa-stable" target="_blank">http://lists.freedesktop.org/mailman/listinfo/mesa-stable</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div dir="ltr">Courtney Goeltzenleuchter<br><div>LunarG</div><div><img src="http://media.lunarg.com/wp-content/themes/LunarG/images/logo.png" width="96" height="65"><br>
</div></div>
</div></div>