On 8/20/06, Jack Carroll <[EMAIL PROTECTED]> wrote:
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.
Check out the exokernel model. Exokernel is what DRM/DRI does today. Each of the DRM kernel drivers has a completely different IOCTL interface. The kernel DRM driver for the ATI R200 looks nothing like the Intel i925 driver. Mesa is a complete software implementation of OpenGL. But Mesa is designed so the software functions can be overlaid with functions that implement hardware acceleration. Each DRM driver has a corresponding userspace DRI library. These libraries overlay Mesa functions with hardware accelerated functions. For example the intel_dri module contain hardware texture functions that make calls into the intel DRM kernel module. If the intel_dri module isn't loaded you will fallback to software implementations of the same functions. The result of this is that there is a single public user space API, OpenGL. But all of the kernel modules for each video card are different. Nobody except Nvidia puts the whole OpenGL stack into their device driver. The DRM kernel modules are thin layers that provide safe access to the hardware from unprivileged apps. For example the DRM drivers check the commands being sent to the GPU to keep apps from misusing the DMA hardware to read memory that is not theirs. Nvidia has the OpenGL stack in the device driver because they ported their WIndow drivers to Linux. Under Vista the rules have changed and they have to move their code to user space. -- Jon Smirl [EMAIL PROTECTED] _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
