tag:blogger.com,1999:blog-36137506.post8055963583465966796..comments2024-02-09T15:22:59.181+01:00Comments on Tagebuch eines Interplanetaren Botschafters: Debugging a GPU VM faultNicolai Hähnlehttp://www.blogger.com/profile/18235566517992076346noreply@blogger.comBlogger2125tag:blogger.com,1999:blog-36137506.post-51404162768458115372015-12-19T22:01:32.825+01:002015-12-19T22:01:32.825+01:00fwiw, as far as tracing down which draw was triggi...fwiw, as far as tracing down which draw was trigging a hang, w/ freedreno I have used scratch register writes, writing incrementing counter value to a scratch reg before draws, etc.. dumping the scratch register values on hang.. I do insert extra WFI's to kill some of the pipelining in the CP, but doing a flush after every draw completely changes the behaviour of things with a tiler so frequently not a good option for me. And then to map back to draw # in apitrace I'd hacked up:<br /><br />http://lists.freedesktop.org/archives/apitrace/2015-August/001112.html<br /><br />I need to revisit that and convert to khr_debug still... there are patches on mesa-devel which plumb that through to the gallium driver so it can insert the frame # msgs from apitrace in the cmdstream embedded in a CP_NOP packet.<br />Robhttps://www.blogger.com/profile/00061851853178706566noreply@blogger.comtag:blogger.com,1999:blog-36137506.post-88987434396779538532015-12-19T18:10:48.309+01:002015-12-19T18:10:48.309+01:00I didn't understand much but at least i apprec...I didn't understand much but at least i appreciated to read about how it's done and how much that goes into fixing a bug like this.<br />I need to learn more about graphic stacks.Anonymoushttps://www.blogger.com/profile/13956017318315549226noreply@blogger.com