<html> <head> <meta http-equiv="Content-Type" content="text/html; charset=Windows-1252"> <style type="text/css" style="display:none;"></style> </head> <body dir="ltr"> <div id="divtagdefaultwrapper" style="font-size:12pt;color:#000000;font-family:Calibri,Helvetica,sans-serif;" dir="ltr"> <p>Hi Bruce,</p> <p><br> </p> <p>Sorry for the delay. I finally had a bit of time to take a look at your original patch on <a href="https://lists.freedesktop.org/archives/mesa-dev/2017-February/142817.html" class="OWAAutoLink">https://lists.freedesktop.org/archives/mesa-dev/2017-February/142817.html</a> , and it's definitely an improvement.</p> <p><br> </p> <p>But a more straightforward way to do this is to, rather than adjusting for x,y,z after the fact, simply calculate the strict blob size, as in:</p> <p><br> </p> <p></p> <div><span style="font-family: "Courier New", monospace;"> size = util_format_get_nblocksx(format, box->width ) * util_format_get_blocksize(format)</span></div> <div><span style="font-family: "Courier New", monospace;"> + (util_format_get_nblocksy(format, box->height) - 1) * stride</span></div> <div><span style="font-family: "Courier New", monospace;"> + (box->depth - 1) * slice_stride;</span></div> <div><br> </div> <p>This should get the right results regardless any of x,y,z or stride or slice_stride is zero or not. <span style="font-size: 12pt;">It does require that height & depth to never zero, but I think that's always the case already.</span></p> <p><span style="font-size: 12pt;"><br> </span></p> <p><span style="font-size: 12pt;">I noticed something even worse: we were not considering buffer transfer box as bytes. Fixing this would also fix the issue I belive.</span></p> <p><br> </p> <p>I posted a patch with the above for review.</p> <p><br> </p> <p><span style="font-size: 12pt;">Jose</span><br> </p> <p><br> </p> <div style="color: rgb(0, 0, 0);"> <hr style="display:inline-block; width:98%" tabindex="-1"> <div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" color="#000000" style="font-size:11pt"><b>From:</b> Cherniak, Bruce <bruce.cherniak@intel.com><br> <b>Sent:</b> Wednesday, July 5, 2017 16:38<br> <b>To:</b> Jose Fonseca<br> <b>Cc:</b> Michel Dänzer; Marek Olšák; ML mesa-dev<br> <b>Subject:</b> Re: [Mesa-dev] gallium: Reduce trace_dump_box_bytes size by box->x.</font> <div> </div> </div> <div><br class=""> <div> <blockquote type="cite" class=""> <div class="">On Jul 4, 2017, at 9:40 AM, Jose Fonseca <<a href="mailto:jfonseca@vmware.com" class="">jfonseca@vmware.com</a>> wrote:</div> <br class="Apple-interchange-newline"> <div class=""> <div class="">On 29/06/17 11:02, Michel Dänzer wrote:<br class=""> <blockquote type="cite" class="">On 29/06/17 01:54 AM, Cherniak, Bruce wrote:<br class=""> <blockquote type="cite" class=""> <blockquote type="cite" class="">On Jun 26, 2017, at 2:10 PM, Marek Olšák <<a href="mailto:maraeo@gmail.com" class="">maraeo@gmail.com</a>> wrote:<br class=""> <br class=""> In my opinion, dumping resources isn't very useful. I think it would<br class=""> be better to remove that completely.<br class=""> </blockquote> <br class=""> >From Michel's response, sounds like dumping resources is useful, so...<br class=""> </blockquote> FWIW, after my previous post it occurred to me that resource dumping<br class=""> might not be necessary after all; dumping transfers might be sufficient<br class=""> for a replayable trace.<br class=""> Adding José, I hope he can clarify.<br class=""> </blockquote> <br class=""> Right, to preserve ability to replay, it should suffice to serialize the write transfers.<br class=""> <br class=""> Of course, this ignores the issue of persistent mappings. To handle persistent mappings the trace driver would need to, on every draw, walk over every bound buffer and see if any was changed by keeping a shadow memory, or some other trick mentioned on <a href="https://github.com/apitrace/apitrace/issues/232" class="">https://github.com/apitrace/apitrace/issues/232</a><br class=""> </div> </div> </blockquote> <div><br class=""> </div> With regards to averting the crash that I experience in trace_dump_box_bytes when tracing certain applications, what is the best path forward?</div> <div>I can keep my patch (or a patch that stubs this function altogether) handy for local application, but that doesn't help anyone else out.</div> <div><br class=""> </div> <div>Thanks,</div> <div>Bruce<br class=""> <br class=""> <blockquote type="cite" class=""> <div class=""> <div class="">Jose<br class=""> </div> </div> </blockquote> </div> <br class=""> </div> </div> </div> </body> </html>