> > is a patch to blit the contents of the batchbuffer to another memory > space, and compare them before submitting the batchbuffer for the hardware > to consume.. > > so on my 965, starting X using a batchbuffer allocated non-cached in TT > space, I get to see this: > index: 0 0000: src 00000000 dst 54000004 daddr f8e36000 > index: 0 0001: src 00f00010 dst 00f00010 daddr f8e36004 > [drm:i915_execbuffer] *ERROR* batchbuffer not hit hardware yet 56 > > Where it looks like the first dword of the batchbuffer got lost somewhere > in the ether, now this could be a) a bug in the code, or b) a bug in my > test code... > > I'd appreciate the ppl who are familiar with intel hw have a look and > seeing if they can spot anything I missed.. > > This is on 965 where I believ the mi_flush with 0 is what I want, I think > on other chips the mi_flush may need a value passed in.
I think I fixed it by issuing an mfence before the blit, will play about a bit more.. Dave. ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
