On Wed, May 14, 2003 at 03:57:18PM +0100, Matt Sealey wrote:
> If I understand you right here, Mesa will store all the data for me so I
> can fill the data out when I need it - so I don't need to hook the Color3f
> and etc. functions at all
Yes, the vtxfmt stuff is an optimisation, bypassing mesa (and in the codegen case,
replacing the glFoo function with assembler that outputs the data directly into dma)
> i.e. when it's ready to be committed to the hardware Mesa calls my driver and
> says "push that to the hardware". But where is that? Only on glFlush()?
Where you register a pipeline with _tnl_install_pipeline is where mesa
calls in with the data.
Look at the pipeline stages the stage inputs, outputs etc. These are what
drives which pipeline stages are used, and what data is created / was provided
by the client, is needed because of the state etc.
The radeon starts with the t&l stage. If radeon_run_tcl_render returns false
(i.e something the TCL hardware doesn't support) it'll go into a number of
other stages _tnl_vertex_transform_stage, and similarly named normal, lighting,
fog, gen texcoord etc etc that do what you'd expect with the data filling out
more of the VB structure.
The outputting of data uses the template headers (xc/extras/Mesa/src/tnl_dd/)
included in things like radeon_tcl.c which emit various data (elts, vertices),
in various sizes (if you look you'll see it's a table of functions indexed by
vertex format) to various places (direct into dma, or into arrays etc) - the
headers use things like #define HAVE_TRIANGLES 1, and macros you define
before including the header to alter their behaviour. These are probably what
you're looking for to create your different apple arrays?
As Keith said, the vb output in the other drivers might be a closer fit - it
might make more sense to look at a driver that has less colours and sizes - the
Mesa 4.0 radeon driver was more like the other drivers, before the T&L stuff,
maos, vtxfmt and codegen stuff was added.
Other options, step through it in debug, as I describe below, nothing much goes
to the hardware in the radeon case for most of this stuff until it needs to, so
long as you don't step on a LOCK_HARDWARE call (you probably can if you ssh
into the machine?). I found it helped tie some of the pieces together if you
step through a 'hello triangle' program (the RADEON_NO_<foo> env variables are
useful to watch the none tcl/codegen paths with the same code). Compiling
things like radeon_tcl.c with -E to remove the layer of abstraction the tmp.h
headers add might help too.
> When it runs out of buffer space?
The actual "sending to the hardware" and the above are, in a sense,
The radeon driver accumulates as much as it can before it actually goes to the
hardware - but at the same time it's designed to be able to flush to hardware at
any point, so as you say, running out of buffer space or the usual gl will
trigger an actual flush to hardware, most of the above I've described though is
just accumulating the data as the hardware will see it, often in the memory
space of the card, without actually telling the card to process it.
 you've got to consider atomicity wrt other contexts, you can't send state
to the card, and later send vertices that depend on that state, if another
client can send in between.