>My worry is that batch->bo is not constant for the construction of a single >execbuf2. > If intel_batchbuffer.c runs out of room inside the batch->bo, it will > allocate a new one and continue building it.
That will be ok, but if the (fd, GEM BO handle) changes, there is a serious issue. > I'm just mentioning that may not be the same handle as some of the earlier > state calls. This is a serious issue; sighs. The Logger will not miss any GPU state (since that is handled at ioctl interception time), but it will get the GL/GLES call ID's royally hosed because the api call markers will be on the log associated to that (old) (fd, GEM handle) pair. Futz. The solution is to add another function to the driver interface that the driver calls when it "migrates" stuff from one BO to another (i.e. when it grows a batchbuffer to fit in that last draw call). Good catch on that, I had utterly forgotten that the batchbuffer split lets i965 "grow" the batchbuffer to fit in that one last call. All the stuff I have run on it so far have not hit that, but there will be loads where it gets hit. I will fix this ASAP. -Kevin _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
