On Sun, Aug 20, 2006 at 06:59:47AM -0400, Timothy Miller wrote:
> Oh, trust me. When it comes time to write Linux drivers for this
> thing, I'm going to have some complaints to make. There are things
> that I think are fundamental to getting good throughput from a
> graphics chip that I think may be difficult or impossible to support
> given the existing frameworks. Those frameworks will have to change.
>
> And that brings us to back to the problem of unchangable APIs. What
> if we forgot something? What do we do?
>
> Here's an example: Many drawing engines have an "I am completely
> done" interrupt. DMA hardware and software use that to set up the
> transfer for the next block of commands. In the mean time, the GPU is
> IDLE. Just sitting there wasting time. What if we wanted an
> interrupt that said "I'm nearly done; go ahead and set me up for some
> more commands"? The only drawing engine I know of that does this is
> the one I designed for Tech Source. If you were to base your API
> around existing GPU designs, you would be forever unable to take
> advantage of this unusual feature, and you'd lose out on a potentially
> significant performance boost.
The only way I can think of to resolve this paradox is to allow the
API to evolve only in discrete releases. Each released version could be
implemented in a kernel module with a different name.
That way, an API once released would be frozen for all time, and a
driver writer could write for that API with confidence that is would never
be forced into obsolescence or require updating because of kernel or X
changes.
A driver writer who needs features not included in that API would
write for a later API.
The kernel wouldn't become bloated, because Linux normally loads
only the modules it needs. Drivers are able to command specific modules to
load.
_______________________________________________
Open-graphics mailing list
[email protected]
http://lists.duskglow.com/mailman/listinfo/open-graphics
List service provided by Duskglow Consulting, LLC (www.duskglow.com)
