Well, digging out the G400 docs, I've negated my own argument: > It is a trade-off of a definite outcome versus a roll of the dice. We > are trading a 100% chance of an inconvenience to users, for a > less-than-100% chance that the blob in any particular case is a > program-without-source and is thus hampering the freedom of the user. (C) Matrox: There are two major advantages to use the WARP. The WARP is completely programmable and it can do complex computations in parallel with the graphic engine and the CPU. The format and interpretation of the information that is sent to the WARP depend on the micro- code. For the purpose of 3D interfaces, the micro-codes are used to setup triangles into the graphic engine, hence, the information is interpreted as vertex information. With the WARP running, the driver just has to setup the graphic engine with the type of primitive to draw (texture format, Z compare, alpha blend...) and send vertex information to the micro- codes. The micro-codes (or pipes) that are distributed in this DDK are those in use in the current G200/G400 Direct3D/MCD/ICD drivers. These pipes can be the starting points of a driver that use the WARP. To have a completely optimized driver and because each 3D interface are different, the WARP pipes would need to be redesign for each specific uses. So the mga microcodes are programs, no further argument on that angle. Now the question is whether they were generated from a higher level language or from an assembler. If they were generated from a higher level language, they are definitely headed for non-free. If they are generated from an assembler, it is possible to construct an assembler and accompanying listing that directly maps a set of mnemonics to the required instructions. Maybe it isn't the ORIGINAL source, but it is _a_ source. I think I'll be doing some footwork on this one. -- Ryan Underwood, <nemesis@icequake.net>
Attachment:
signature.asc
Description: Digital signature