Ian Romanick wrote:
sentance Monday!) On the flip side, I believe that all the Parhelia related chips are programmable-pipeline only (i.e., no fixed function hardware). Even if Matrox did release all the required documentation, the Mesa infrastructure isn't far enough along to /properly/ support it.
Actually I don't agree with the last bit. There's not much missing from mesa in that regard.
There's two ways to handle this sort of hardware. You can either have a ton of pre-compiled bits of code (for the GPU) to implement various parts of the pipeline. Those pre-compiled bits get pulled together depending on the state-vector. The other way is to pull together code depending on the state-vector and compile it at run-time.
Right now Mesa can do the first method. IMO, that doesn't /properly/ support the hardware. One of the nice things about the way Mesa is architected is that the burden of implementing new functionality falls on Mesa. Going the first route shifts that burden to the device-specific code.
The current situation with Mesa and programmable-pipeline only hardware is a lot like the situation was with Mesa 4.x and TCL hardware. It's doable, but it's not idea. That's all I was trying to say before.
------------------------------------------------------- This SF. Net email is sponsored by: GoToMyPC GoToMyPC is the fast, easy and secure way to access your computer from any Web browser or wireless device. Click here to Try it Free! https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/g22lp.tmpl _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
