<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Apr 15, 2014 at 2:16 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="HOEnZb"><div class="h5">Courtney Goeltzenleuchter <<a href="mailto:courtney@lunarg.com">courtney@lunarg.com</a>> writes:<br>
<br>
> On Tue, Apr 15, 2014 at 1:18 PM, Eric Anholt <<a href="mailto:eric@anholt.net">eric@anholt.net</a>> wrote:<br>
><br>
>> 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<br>
>> 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<br>
>> 384*320=122880<br>
>> >> bytes, 30 pages), then puts it into a power-of-two-sized BO (131072<br>
>> bytes,<br>
>> >> 32 pages). Because it's Y tiled, we attach a 384-byte-stride fence to<br>
>> it.<br>
>> >> When we memset by the BO size in Mesa, between bytes 122880 and 131072<br>
>> 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>
>> 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>
>><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>
>> 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>
>><br>
><br>
> Why not? I understand that it's not useful to touch pixels beyond 115200,<br>
> but from the data structure, we were given 131072 bytes to work with. Why<br>
> shouldn't memsetting the entire allocated space be a safe operation?<br>
<br>
</div></div>If you drm_intel_bo_map() and write 131072, you'd be fine. If you<br>
drm_intel_bo_map_gtt() on the tiled buffer and your fence readdresses<br>
your writes beyond 131072, you're not fine.<br>
</blockquote></div><br>I'm curious, what would it have cost to reserve the pages necessary to cover both cases?</div><div class="gmail_extra"><br></div><div class="gmail_extra">The issue caused by this particular overwrite was hard to pin down. In our test case the failure was intermittent. We could see that memory was getting corrupted but nothing else had run between the last time we checked and things were good and when they went bad (building the dlist in glxgears).<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>