Christopher Nelson <[EMAIL PROTECTED]> writes: >> So... what's the "interesting" stuff in the driver that they're trying >> to protect? Texture management? > > I think the 'interesting' stuff is the nuts and botls of sending data, > because I think they're afraid someone will reverse-engineer their board > from that info and turn around a cheaper model that does the exact same > thing.
I'm not sure how that follows though. There's no reason for an erstwhile competitor to use the same hardware interface -- the very existance of the "driver layer" means that you don't need to emulate the hardware-level protocols to compete. In any case, a GUI these days is an immensely complicated piece of hardware, you can't just throw together a fly-by-night company to churn out clones of it. I imagine that the clues about hardware implementation secrets given by the bit-level interface are weak at best. I could be wrong of course -- and that's exactly my question: what sort of things are these drivers implementing? What I'm thinking is that the various resource-management issues are what's at issue here. Texture memory management is the thing that comes to mind, but maybe the task of juggling pipeline/threading resources is done in the driver too? [However if the issue were only protecting such algorithms, then there would still be no reason to hide the hardware interface details.] -Miles -- "Unless there are slaves to do the ugly, horrible, uninteresting work, culture and contemplation become almost impossible. Human slavery is wrong, insecure, and demoralizing. On mechanical slavery, on the slavery of the machine, the future of the world depends." -Oscar Wilde, "The Soul of Man Under Socialism" -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]