On Sat, Mar 01, 2003 at 03:11:06PM -0800, Linus Torvalds wrote: | | ... you have to understand a | wide range of different issues (you can't just understand hardware, you | also have to have some understanding of OpenGL). | ... | Look at the size of a 3D driver today, and _especially_ look at how it | actually needs at least three totally separate parts - the generic OpenGL | part, the card-specific part, and the kernel part. None of which are in | any way independent from each other (the generic OpenGL part should be, | but as can be seen from what both Nvidia and ATI have done, it ends up | being tied into the low-level driver _anyway_ because of issues like | feature reporting).
This is largely because there's a *much* greater emphasis on performance in the 3D world than in the 2D world. There's too much competitive advantage to be gained by exposing hardware peculiarities and by avoiding certain kinds of abstraction. For example, it's usually too expensive (in terms of call overhead and data transfer/reformatting) to use layering as technique for driver implementation. 3D systems tend to have "vertical" modules rather than layers -- selected execution paths are mapped as closely to the hardware as possible. This means that there's a lot of device-dependent code starting right underneath the API, and consequently less code shared between drivers. Graphics programmability eliminates layering altogether and moves application logic very close to the hardware, at least until the Wheel of Reincarnation spins again. :-) | A simpler, more direct, infrastructure to the low-level driver might help. | I suspect that is why MS started doing D3D in the first place... There were two key factors that led to D3D: A lack of technical understanding of 3D (leading some people at MS to claim that OpenGL could never be used for games), and a business model that required monopoly control of the API (in order to force the hardware to be commoditized). As Microsoft learned what it was doing wrong technically, D3D rapidly appropriated features and design concepts from OpenGL. Around DX7 it reached parity on the things that were necessary for gaming, and started to diverge rather than converge. D3D adopted programmability more quickly than OpenGL. There were many reasons for this, but a couple of interesting ones are (1) once D3D no longer had a target to copy, it was less clear which special-purpose functionality should be put into the API, so general-purpose programmability offered a way forward; and (2) Microsoft's business is based on product differentiation in software rather than in hardware. Once you get rid of the legacy stuff in OpenGL, drivers are pretty much the same level of complexity for OpenGL as for D3D. Which is one reason why several groups are able to use OpenGL subsets for embedded apps. Allen ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
