-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Patrick McFarland wrote:
> Even if we violate precision/range stuff, being able to accelerate simplistic > shaders would be quite useful. Its better than not having a software > implementation of the shader pipeline. The problem is that most shaders that use ARB_fp or NV_fp aren't simplistic enough. It would be a *lot* of work to benefit 1% of real-world shaders. > Also, what stops you from splitting up a shader, and running the peices back > to back over multiple passes? Can't you emulate longer shaders doing that? So, I looked into this really deeply in the past for other things. The problem is it gets *very* hard to deal with framebuffer blend modes. If you have an arbitrary triangle list, triangles in the list may overlap. If you have a framebuffer blend mode other than dst=src, you can't multipass it (generally) without breaking up the triangle list and sending one triangle at a time. It would not surprise me at all if the performance there was close to that of a good software implementation. This, BTW, is what ATI's "fbuffer" in all about. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFC5/SSX1gOwKyEAw8RAlgoAKCLWrewHelrWjXFlaRZjzJ4ITdZ4gCeM9x5 7jYZbOZ/I0mduOG9O19zzlY= =RibU -----END PGP SIGNATURE----- ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf -- _______________________________________________ Dri-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/dri-devel
