On 28/06/17 17:54, Cherniak, Bruce wrote:
On Jun 26, 2017, at 2:10 PM, Marek Olšák <mar...@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
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
