Re: Supported Video Cards under Free Software
Christopher Nelson <chris@cavein.org> 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"
Reply to: