From: Brian P. <br...@tu...> - 2002-01-29 23:24:52
|
I've been digging into a problem that Karl Rasche reported with the multicontext-1 branch related to the readback SPU. It's led me on an adventure through almost every bit of the Chromium code. I think I'm finally finding the cause(s). My investigation has turned up some questionable design issues. First, the packspu appears to have an unneeded dependency on the state tracker. The state tracker is apparently just being used to store OpenGL's client-side state. Greg, is this a correct assessment? The main issue is that client-side OpenGL state isn't really being handled correctly. It's important to remember that OpenGL has a clear division between client and server-side state (it's pretty clear with GLX, but kind of blurry with WGL). Chromium also is client/server oriented so there's some commonality here. Parameters like vertex array sizes, datatypes, pointers and pixel pack/unpack parameters should never ordinarily be sent over the network. They should only be necessary on the client side. Thus, I think these parameter should be handled by the pack SPU without relying on the state tracker. Some of the changes I propose include: - renaming the CRClientState struct to CRVertexArrayState, since that's what it really is, and it corresponds to the GL_CLIENT_VERTEX_ARRAY_BIT attribute group. - pull the CRPackState structure out of CRPixelState because pixel-store and pixel state are independent things (ala GL_CLIENT_PIXEL_STORE_BIT and GL_PIXEL_MODE_BIT) - Bundle CRVertexArrayState and CRPackState into a new CRClientState structure which can be reused outside of the state tracker. - Keep a private CRClientState structure in the pack SPU to replace the dependency on the state tracker. Once this is all done, I think my problems in the crserver will go away. The problem there is that the crserver itself uses the state tracker (to serialize the input streams) and if the crserver loads a pack SPU then things blow up because the pack SPU also uses the state tracker. When we do 'MakeCurrent' we're pulling the rug out from under one thing or the other. I think the code on the trunk is working out of luck. The code on the multi-context branch is a little more sophisticated in its context/state management and exposes the above problem for the first time. Comments are appreciated but I think I'll start on these changes right away and see where they lead. -Brian |