Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.anu.edu.au!harbinger.cc.monash.edu.au!news.rmit.EDU.AU!news.unimelb.EDU.AU!munnari.OZ.AU!news.mel.connect.com.au!news.mira.net.au!news.vbc.net!samba.rahul.net!rahul.net!a2i!bug.rahul.net!rahul.net!a2i!genmagic!sgigate.sgi.com!fido.asd.sgi.com!tuolumne.asd.sgi.com!akin From: akin@tuolumne.asd.sgi.com (Allen Akin) Newsgroups: comp.graphics.api.misc,comp.graphics.algorithms,comp.windows.x.i386unix,gnu.misc.discuss,comp.unix.bsd.freebsd.misc,comp.os.linux.development.apps Subject: Re: Freeware community needs 3d library NOW Followup-To: comp.graphics.api.misc,comp.graphics.api.opengl Date: 27 Jun 1996 21:15:38 GMT Organization: Silicon Graphics, Inc., Mountain View, CA Lines: 151 Message-ID: <4qutlq$jcf@fido.asd.sgi.com> References: <4qlf04$7pj@guysmiley.blarg.net> <4qn08b$ntl@fido.asd.sgi.com> <4qt66a$nag@guysmiley.blarg.net> NNTP-Posting-Host: tuolumne.asd.sgi.com Xref: euryale.cc.adfa.oz.au comp.graphics.api.misc:651 comp.graphics.algorithms:29045 comp.windows.x.i386unix:20374 gnu.misc.discuss:26754 comp.unix.bsd.freebsd.misc:22285 comp.os.linux.development.apps:18126 In article <4qt66a$nag@guysmiley.blarg.net>, Brandon J. Van Every <vanevery@blarg.net> wrote: | Allen Akin (akin@tuolumne.asd.sgi.com) wrote: | | : I agree with you that there are many reasons to be dissatisfied with | : Direct3D. | | Actually, I don't have any opinions on Direct3d right now. As an API, | what do you see as the problems with it? This question merits a long discussion, but I'll have to limit it to a quick summary at the moment: It shows its origins as a device-support layer for a games API on machines without geometry acceleration. It's missing some features that are important for non-game applications. The execute buffer design places some expensive constraints on accelerators, and the fact that the data structure is exposed means it'll be hard to change. It will also be difficult for existing applications to use the execute buffer without copying and reformatting data taken from their own structures, which consumes both time and memory. The reliance on direct addressability of surfaces (controlled by the locking/unlocking mechanism) makes it difficult to build high-performance graphics systems with physically distinct memories. There are more. I apologize for the lack of detail, and I promise I'll write more as soon as I get the chance. I thought it would be better to post something immediately so that you get the flavor of what I have in mind, rather than wait several days to write something longer. | : ... Optimization of software-only renderers is | : underway at several sites... | | Could you please provide URL's of these sites? www.microsoft.com and www.sgi.com. There are three other sites involved, but I'm not sure whether they've announced their participation. This will be discussed at SIGGRAPH. | 1) OpenGL guarantees the order of rendering. There should be an | option to control whether there's a guarantee or not. I agree with you. To be honest, though, the case for this feature is not very strong. This guarantee simplifies application software significantly, and the amount of hardware and software required to maintain order is small and cheap compared to the other parts of a graphics system. This could change, of course. The PixelFlow folks can make a good case for deferred shading, and renderers like Talisman take advantage of other kinds of ordering. But at the moment, it's fairly clear that within two generations low-end machines should be able to match the performance (~10M tri/s) of current high-end machines without needing to relax the ordering constraint. | 2) OpenGL allows the user to switch cotexts at any time, even though | those context switches are typically enormously disruptive to system | throughput. The API user should be made very conscious of the fact | that context switching is expensive, and should not be allowed to just | do it whenever... | ...we should guard | against it in the API design itself. I agree with this goal, too, but I'd say OpenGL has already covered it. The designers were aware of the problem, and that's why the window-system glue for OpenGL performs context switches only when the user issues an explicit command. (And why that command isn't allowed in performance-critical situations.) The two alternatives that come to mind are to do context switches implicitly based on the parameters to each rendering command (as X11 does) or to disallow multiple contexts (which has a different set of performance problems of its own). Do you know of a better way? | 3) OpenGL implements way too many features that BOTH impede efficency | AND are not important to support in a large number of applications. ... This is a tough call. Nearly all of the features in OpenGL are there because they solve a problem for some interesting, significant application. If you remove a feature, then you make your API useless for a particular application. Remove enough features, and your API is useless for a very large number of applications. You mentioned stencilling, for example. I wasn't at SGI when stencilling was first supported, but today I see it's used for visual simulation (for rendering geometric decals, nearly-coplanar surfaces, and screen-door transparency), for mechanical CAD (for interference checking, capping planes, and polygon borders), for film/video image editing (interactively-specified mattes and cross-dissolves), and a bunch of other things. If we were to drop it, a lot of customers would miss it. So I guess if you want to restrict your API to a reasonably small set of applications, you can get by with fewer features. The goal of OpenGL was to be useful for a large set of apps, though. You're correct that this makes it harder to implement OpenGL well, but in the long run, we try to support just the features that have more benefit than cost. Those features tend to be useful in many areas, but their uses aren't necessarily obvious at first glance. | 4) The enormous number of OpenGL states also encorages "state driven" | code design... I'm not sure how to reply to this one. OpenGL is specified in a manner somewhat like a state machine, because it's important that the spec be clear and unambiguous for OpenGL implementors and for application developers. But you're free to handle the implementation any way you choose. SGI's implementations are usually a mix (true state machines for stuff that's implemented in hardware, traditional code for the stuff that's implemented in software). If you look at the geometry-processing microcode on an InfiniteReality, for example, you'll see textbook algorithms. | 5) OpenGL makes no guarantee that the lighting normal is the same as | the surface normal. I think Jon covered this one. You have to allow the lighting and surface normals to be different if you're approximating an underlying curved surface. | | 6) OpenGL has no provisions for pre-cached global diffuse shaded | vertices. Jon covered this one, too; just turn off lighting. If you want OpenGL to compute the lighting for you on the first pass, you can use the feedback mechanism. | 7) OpenGL has no pathways for "pre-accepted" geometry. A user's 3d | spatial database could potentially feed a large number of primitives | to the library, that do not require clipping or even accept/reject | testing. Microsoft proposed an extension to disable clip testing, but withdrew it after discovering that it didn't offer a significant performance improvement. So real-life measurements indicate that this isn't a high-priority issue. | 8) OpenGL has no facilities for tracking the delta's of a user's | motion, so as to determine things like "we've only changed the X | position," "we're only moving in the XZ plane," etc. This is pretty specialized stuff, and it seems to me that even the games developers aren't making much use of it anymore. (There are some other special cases, like recognizing textured walls and floors, that are worthwhile and can be handled transparently by the OpenGL implementation.) These ideas are still good possibilities for higher-level libraries, though. For example, a scene-management library like Reality Lab or Iris Performer could recognize that the viewpoint is moving in a plane and use an optimized visibility culling algorithm. Allen