> > > So in mesa for swtcl cases we emit vertices to DMA, and set a driver > > > internal dma.flush hook, we also set > > > ctx->Driver.NeedFlush |= FLUSH_STORED_VERTICES; > > > > > > The driver has its FlushVertices pointed at the vbo_exec_FlushVertices > > > call. > > > > > > I'm not sure when this ever worked but I assume it did at one stage in > > > r100 driver since I haven't really changed this code flow, I'm > > > contemplating doing something like the below but maybe someone can > > > say when this all got broken. > > > > any insights? Keith? > > Hmm, it would seem like you'd need this if: > > a) you have a hw vertex buffer that you're incrementally extending as > new vertices arrive > b) you are delaying emitting the draw packet until you know how many > vertices you put in that buffer, and > c) you don't have any other mechanism to ensure that draw packet doesn't > attempt to span hw statechanges.
You wrote the original ;-), its the r100 swtcl code. I've just been pushing it around the place since, but yes, a, b, c all seem to be true. > IE. if you're optimistically trying to combine incoming primitives into > single draw packets, and don't have code to flush that in response to > state-changes, then this patch makes sense. > > If the above doesn't describe your situation, I don't think you want > this. > > However, even if it does, note that you'd be better off trying to figure > out when a *real* hardware statechange is about to happen before tying > off the old draw packet, as Driver.FlushVertices is going to get called > on every putative mesa statechange, many of which won't result in > hardware statechanges. > > In fact, thinking about it, if you flush on every call to this function, > you basically defeat the optimization it seems you're trying to > implement, because the incoming vertices you're trying to combine will > almost always have a mesa statechange between them -- there's no other > reason mesa would break them up, and Mesa already tries to combine > incoming application draws that aren't separated by statechanges. > > So if you do this, really you'd be just as well served with an eager > emit of the draw packet & forget about trying to be lazy. That probably makes more sense then, I should push the draw packet at a better place, what happens at the moment, is I get a state change without getting the flush, and emit a bunch of texture state that doesn't match the vertices I've already stuck in the vertex buffer, with the new kernel checker it detects the illegal state. Dave. ------------------------------------------------------------------------------ Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf _______________________________________________ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
