Programming the G-series WARP engine

[Wombat]

Then you should be glad you didn't have to deal with M on those

[runderwo]

I guess now my approach is going to be to apply known inputs to all the WARP registers, and then read each of the output registers in the raster interface after executing a single instruction, to try to deduce what it did. Problem being that I don't have an exhaustive list of the outside registers the WARP can write to, but I know some of them (from the DDK). This will also not help with instructions that do not write outside the pipe. But once I have figured out how to i.e. copy the value of WR0 to TMR* or AR* or DR*, then I can get back to my original plan, by having the microcode dump all its values outside the pipe so I can observe changes while single stepping.

[Nappe1]

hmmh...
interesting.
I didn't knew about WARP's ability to run microcode. (or being re-programmable via microcode interface.)

I wonder, what else Matrox did license with EMBM. (which was in fact, just an example of things that Pyramid3D's microcode programmable pixel shading unit was capable of...)

Pyramid3D had Vertex Unit, that was programmable. if we don't count the precision, it would have been pretty close VS 3.0 compatible. (32 KWords total program lenght, loops, conditional and unconditonal jumps, data can be fetched from anywhere...(even via PCI/AGP interface.))


naah... I am just imagining again. most likely there's not even connection between these two.

runderwo: In any case, though it is very unlikely that Pyramid3D and G400 would share some HW blocks, I can try to find Pyramid3D Hardware Refrence Guide. I should have it somewhere laying around... (it's pretty hefty document. IIRC, over a hundred pages.)

[Greebe]

naah... I am just imagining again. most likely there's not even connection between these two.

Should call it fanasizing... YET again

[runderwo]

Damn. I just got back to looking at this again. Not only are all of the WARP(s) internal registers write-only, but all of the registers the WARP program might write to are also write-only from the host! The plot thickens... The only way I can see to do anything at this point is to try to analyze the instructions through the contents of the frame buffer.

One vertex is taken as input to the WARP program, so I guess I can remove instructions one by one from the end of the program until finding that no triangle is output to the frame buffer (in wire frame mode). The last removed instruction probably then is an instruction for copying a WARP register to a drawing register. A "move" instruction might have the source and target registers fixed as part of the opcode, or in variable fields.

Once I can figure out what WARP instruction is needed to put an arbitrary WARP register's value into the drawing engine's vertex registers, then I will be able to observe the execution of the (trojaned) WARP program in the frame buffer, because the drawing engine won't have any idea that it is drawing a pixel that will be grabbed from the fb and interpreted by my analysis program as a numeric value.

I doubt this will work, but it will be fun to try anyway. I don't think there is any other way to figure out what it's doing. The only ways I can observe what the WARP has done is through the few WARP status registers we have been given, and through the frame buffer data that is eventually produced by the drawing engine based on the output of the WARP. Both of those methods suck, unfortunately.