[Mesa-dev] gallium: Reduce trace_dump_box_bytes size by box->x.

Jose Fonseca jfonseca at vmware.com
Tue Jul 4 14:37:21 UTC 2017


On 28/06/17 17:54, Cherniak, Bruce wrote:
> 
>> On Jun 26, 2017, at 2:10 PM, Marek Olšák <maraeo at gmail.com> wrote:
>>
>> In my opinion, dumping resources isn't very useful. I think it would
>> be better to remove that completely.
> 
>  From Michel's response, sounds like dumping resources is useful, so... Back to my original
> question, is this a valid fix?  It prevents a crash that happens on occasion while running
> GALLIUM_TRACE.
> 
> I too would be interested in learning how to replay traces.  Would be very handy.
> 
> Thanks,
> Bruce
> 


Yeah, long time ago, the generated .xml traces could be replayed.

But the replaying was done on top of the "Python state tracker", which 
was repeatedly getting broken (even more than trace driver itself), and 
at some point after apitrace became good enough to replay OpenGL I gave 
up maintaining the Python state tracker and removed it:

 
https://cgit.freedesktop.org/mesa/mesa/commit/?id=afeaf1771d0ccbd2482c5ad7fa237c50b4d3921e

If we were to do this over again, I'd recommend eliminating Python state 
tracker from picture completely.  And instead simply implement the 
retrace logic in C.  Essentially we'd need a SAX parser that would 
consume the XML trace one call at a time (DOM would be simpler, and 
perhaps fine as first attempt, but would eat too much memory for large 
traces), create an object hierarchy describing the arguments (literals, 
structs, pointers), then for every possible call we'd have pretty much 
the reverse of trace pipe driver, ie, fetch and convert arguments from 
object hierarchy into the parameters that will be passed to

Similar to what apitrace does.  Another possibility would be to use 
apitrace format and .  But I think that would create just as many 
problems as it solves.  So probably's better to keep this separate from 
apitrace.


BTW, if I were to do this again I wouldn't use XML for trace driver. 
But rather JSON (or rather, a stream of JSON objects, 1 object == 1 
call) or UBJSON.


Jose


More information about the mesa-dev mailing list