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... -Brian ------------------------------------------------------------------------- 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
