TeslaRel410/sda4/DPL3/VRENDER/VWE.DOC

Thoughts on a floating-point less pxpl5 board for VWE.
------------------------------------------------------

I am not proposing we build anything like this - however, to throw YET MORE
SMOKE into VWE's equation, I told them we could do it, dead fucking easy.

Advantages - they get to use the DEC pc board they are so keen on, at
around $3k. Thus no PC, no floating-point front end, so a big cost saving.

Downside - the Alpha is very, very loaded. It will have to handle audio
to the Soundblaster, and networking. It will also need to transform, light
planarize and binitize all the polygons. Its effectively  a RenderWare
solution with accelerated scan-conversion. But hell, its an even playing
fieldif Kubota are doing this, and pxpl5 will EAT their fill rate.

We need to push a ton of triangles down the wire into the pxpl5 back-end.
How much of a processor will this consume?

The really cheap approach to this (and possibly quickest) is to ignore all
DMA solutions. If we use a modern processor with 256k or 1M of secondary
cache, we will access the coefficients much faster via the processor
than via a DMA engine, because we dont need to write the coefficients into
uncacheable RAM. We just write them to memory (probably in cache), and later
the processor picks them out of memory to push down the wire. If our average
hit-rate is 3, we will get 2 guaranteed cached accesses to each polygon drawn.

Assume VWE's core primitive is a z-buffered, flat-shaded, textured quad.
These consume 48 32-bit words each. How much bus bandwidth (and hence
processor time) does this consume?

(NB - I dont yet optimize quads or flat polys - their frame rate will go up
by I estimate 50% if I do, so we will once again see 30Hz on the tanks-in-the
trench demo).

Assume a generic modern processor with a 64-bit bus at 40MHz, single-cycle
writes into a FIFO. To render 1000 flat-shaded textured quads, hit rate of 3,
takes us 1000x3x48/2 bus cycles, or 72000 cycles, or 1.8 mS at 25 nS per
cycle. Assume we can read the internal cache 64 bits at a time in 1 cycle,
and write the FIFO in 1 cycle, we need 2 cycles per 64-bit word written, so
we actually consume 12% (1.8 x 2 mS per 30 mS frame) of the processor's time.
Taking losses and looping into account,
knock this up to 15% - we have 85% of the processor available after we have
eaten up these cycles doing memcpys to a FIFO.

The horrible question is, is it worthwhile doing this stuff in an interrupt
process, or should we just poll very frequently? Either solution boils down
to FIFO depth.

Assume we have 64-bit FIFOs hung straight off the 64-bit bus,
and they are 2k locations deep. Each triangle takes up 24 locations in the
FIFO. If we take the full-on robot brainless approach, and use just half-full,
then when are flagged as being half-empty, there are at most 42 triangles
left in the FIFO, and we can push 42 more triangles into the FIFO. This will
take 42*24*2 cycles, or 50uS. So if we use up 10uS getting into the
interrupt service routine and another 10uS getting out (optimistic if
the i860 is anything to go by) we will be running at 70% efficiency using
interrupts to service the FIFO. The FIFO is emptied much much slower than it
is filled - each polygon takes a good 10uS to be rendered, so 42 triangles
will drip out in around 400 uS. This lets us think about using interrupts
sensibly - interrupt on almost empty (say 1/8th of the FIFO, or 10 triangles) -
this gives us 100uS to get in and service the thing before the FIFO empties.
Assume this takes 10uS, as before, we can now push around 74 triangles in
before the FIFO fills, which will take 72*24*2 cycles, or 86uS. The 20uS
dead time now leaves us running at 81% efficiency while pumping in triangles,
so the total time to pump triangles in is 85% * 0.81 = 69%. We therefore
have 69% of the processor available to do triangle processing. Bringing a
300k triangle processor down to 207k. Of course, if the interrupt times
are more like 5uS, we are up at 76%, or 228k. Doing the thing via polling
brings in issues like - how often should we poll to guarantee not letting
the FIFO empty? With the interrupt approach, dropping 72 triangles at a
time into the FIFO, we will service 42 interrupts per frame (at 1000 polys,
hit rate of 3). This will eat up in total 0.84 mS of dead time, assuming
10uS in, 10uS out. How many times will we have to poll to kill that much
time? If we assume that polled latency is higher than interrupt latency,
lets look for half empty. Then we can drop 42 triangles at a time into
the FIFO. The time taken to exhaust 42 triangles into the IGC is around
420uS. So we would need to guarantee that we poll more frequently than that.
Maybe a hardware timer at microsecond resolution would work? But if we
are using a 3rd party motherboard we cant guarantee such hardware. So
we would need to poll as we entered each object, and every patch,
and every few triangles inside the patch. Assume a very low-latency and
lightweight interrupt service routine is in place, to set a shared variable
on the half-empty interrupt happening. Then the cost of polling is a single
cached read and conditional branch - assume 4 cycles per triangle is the
net cost, then if we are rendering 1000 triangles per scene, the total
cost is 4000 cycles per frame, plus say a few hundred for the per-object
and per-patch checks. If we do 5000 cycles per frame on a 100MHz processor,
the total cost is 50uS. If the low-latency interrupt handler costs 1uS in
and 1uS out, it executes 72 times per frame, adding 144uS. If each call
to the FIFO function costs 2uS in and 2uS out, (due to register saves +
restores), it gets executed 72 times per frame, so another 288uS goes. So
the total per-frame cost of polling is 50+144+288=488uS. This is not that
dissimilar to the interrupt service time of 840uS. Of course, if the
lightweight service routine could come in at 0.5uS, and the function call
at 1.5uS, we get down to 338uS. This is just 1% of the frame time.

It looks very much like we may have a viable solution, but only if we
can drop FIFOs at the wide, high-speed bus end.


Out of interest, how much time is eaten up feeding PCI with numbers?

Assume 32-bits wide, 40MHz, we need per frame to pass 1000*3*48 32-bit words
to the PCI interface. This takes up 3.6 mS, just over 10% of the frame time.
If we assume the processor is totally unable to proceed during these cycles,
then that is how much real time we lose pushing polygons down the wire,
around 11%. So we would still have 89% of our processor left, or 267k
triangles from our mythical 300k processor. Maybe this approach is more
viable anyway? We only need 1/2 the FIFOs, there is no demultiplexing at
the IGC end, no need to double-align as we write down the wire, and the
hardware cost is lower. As an engineering (i.e non-VWE approach) it is a bit
deadly? Rendering 10k triangles per frame at 15Hz (i.e delivered 150k, hardware
at the red line) will eat up 1/100th sec, or 15% of the frame time. Actually,
still not that desperate, mainly because as the frame rate drops the ratio
gets less bad, and as the triangles per frame goes up, the hit rate goes
down - the 1/100th sec assumed a hit-rate of 1.

Conclusions?

If we want to pull out a really cost-effective entertainment
board, with a minimal build cost, minimal build complexity, and minimal
royalty payments to UNC (we pay percentage of list price, not percentage of
EMC component!) it pays to NOT put our own floating-point front end on it.
To really keep costs down AND keep general purpose, we can feed triangles
down PCI without really breaking the bank. We should be able to build this
board for around $2k? Maybe less, I'm not up on the current costings. So VWE
could get a $4k board, and we would be doubling our money rather than getting
20 sodding percent gross margin. Ok, the total revenue would be lower, but
the board would be attractive to other entertainment weenies. And of course
it could be programmed in OpenGL (or some crappy subset of it) rather than
weenie-o-PAZ, since all the geometry is instantly accessible to the host.
With a 100MHz Pentium it would make a terrific entertainment platform.
Kubota are offering VWE their next-generation vapor-o-matic for Q1, at I
suspect around $4k, maybe $5k. Certainly they claimed that Kubota had a
significant price differential over us. If we want this business we have
to offer VWE this board, shipping by Q1 (!). Which probably means we cant
do it.