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.