Brian Paul wrote: > On 1/3/08, Ian Romanick <[EMAIL PROTECTED]> wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Since it looks like the TG folks are knee-deep in the fragment shading >> side of things, I'm going to start tackling the vertex processing. I'm >> looking at the vertex processing code in Gallium, and I honestly can't >> make heads or tails of it. I grok some of the individual bits, but the >> bigger picture escapes me. > > Don't feel bad, it's not exactly simple stuff. > > >> Could someone give me an overview of what happens when an app calls >> glDrawElements, for example? > > glDrawElements basically maps to the pipe->draw_elements() method. > Before it's called though, the state tracker code needs to tell the > gallium context two things: > > 1. The vertex format (which attributes, number of components and > datatypes). This is described with the pipe_vertex_element type and > calls to pipe->set_vertex_element(). > > 2. The location of the vertex arrays in memory (in buffer objects). > The Mesa vbo module puts the array data into VBOs and the state > tracker tells the gallium context about the buffers with the > pipe_vertex_buffer type and calls to pipe->set_vertex_buffer(). > > > When pipe->draw_elements() is called that dispatches into the device > driver. If you have full TnL hardware, you'll basically use the > vertex format/buffer info to program the hardware and let it rip. > > For non-TnL hardware, the 'pipe/draw/' utility module comes into play. > It does sw-based vertex transformation, primitive assembly, clipping, > etc. emitting screen-coord points/lines/triangles at the end. > > The draw module transforms 4 vertices at a time (like we do "quads" of > fragments) to allow SOA (or AOS) processing. > > There's also a vertex cache/buffer (32 verts, I think) and primitive > (point/line/tri) cache for efficient primitive assembly, etc. > > When the prim cache (or vertex cache) is full, we begin rendering a > batch of primitives (points/lines/tris) by passing them through the > "prim pipeline" which is a sequence of stages like clipping, > front-back face determination, culling, glPolygonMode, > glPolygonOffset, etc. The last stage of this pipeline (which actually > renders the prim) is not in the 'draw' module. It's provided by the > device driver (see sp_prim_setup.c or cell_render.c, for example). > > Does that help? Maybe I should put this into a comment... >
Better still, put it into the wiki... Keith ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Mesa3d-dev mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
