Re: [Chromium-users] Tilesort generates needed network traffic?

[Brian P. <bri...@tu...>]

James Supancic wrote:
> I am trying to figure out how this all fits together. Right now I know
> so little about the interactions between the various components that I
> can't begin to figure out how to fix things.
> 
> I have been looking at the packer source code, I can't figure out how
> the buffer to write to is set?

crPackSetBuffer.

> I see macros that write data, and I see
> a macro to grab the packer context. From the packer context the
> functions are able to get a pointer a buffer. Normally write functions
> take some kind of stream identifier, but Chromium appears to use a
> global variable rather than a function argument. This makes tracking
> down exactly how the buffer to write to gets set a bit tricky. Do you
> have any idea how I can figure out were it is getting set?

You're right that a global var for the current packer context is used. 
  When built thread safe, it's a per-thread pointer.


> I am not sure how much of the problem I am experiencing has to do with
> the state tracker. I don't think we should have to send anything at
> all to a Render SPU if the window being rendered to is not on that
> SPUs server.

You don't have to send anything if the primitive you're rendering 
doesn't interesect the Render SPU's window (in terms of projected 
window coordinates).


> I can't be sure, as I am very confused about how the
> buffer to be written gets selected, but it looks as if the SwapBuffers
> command is being sent to all Render SPUs unconditionally in
> tilesortspu_SwapBuffers rather than to just the Render SPUs that have
> the Render window on them?  Is there a technical reason for this, or
> has no one got around to optimizing it yet?

That's intentional.  Recall that you can make a whole chain of SPUs. 
Some SPUs depend on getting SwapBuffer calls.  If we omitted some 
SwapBuffer calls, we'd cause trouble for those other SPUs.  The VNC 
SPU is an example.


> How does the State Tracker interact with the rest of Chromium? To me
> it appears as if it is used to track the difference between the OpenGL
> state on the tilesort SPU and the OpenGL state on the Render SPU. Does
> it do anything else? To me it appears that the State Tracker is simply
> something else uses to keep track of the state defences, it looks as
> if something else is actually making the choice to not send something
> to some Render SPUs and then using the State Tracker to keep track the
> the results of this choice? If this is correct, what code is actually
> making this choice?

That's basically correct.  The tilesort bucketing code determines 
which crservers need to receive any given primitive.  Before sending 
the primitive, the state differencer is invoked to update each 
crserver with whatever state it needs to become up-to-date.

Some good background material is the original WireGL white paper and 
the Chromium paper from SIGGRAPH '02 (I think).  You should definitely 
read those.  I think there's also some Stanford papers detailing the 
state differencer and packer/unpacker.

-Brian