Slashdot Mirror
OpenGL 2.0: Chasing DirectX
MJ writes "Is
OpenGL 2.0 All That? Hopefully you will be able to answer that yourself after reading this article from XtremePcCentral. They have cool looking leap frog graphics with lots of arrows and a quote from John Carmack, what else could
you ask for? Robert Richmond does a great job of delving into this
subject. Carmack says, 'The implementation went very smoothly, but I did run into the limits of
their current prototype compiler before the full feature set could be
implemented. I like it a lot. I am really looking forward to doing research work
with this programming model after the compiler matures a bit. While the shading
languages are the most critical aspects, and can be broken out as extensions to
current OpenGL, there are a lot of other subtle-but-important things that are
addressed in the full OpenGL 2.0 proposal.'"
OpenGL is similar to a PORTION of DirectX (Direct3d)...
OpenGL does not provide any other of DirectX's functionality...
Here's the article so we can ease up on the server:
Future Look: OpenGL 2.0 Preview by: Robert Richmond Preview Date: November 11, 2002
OpenGL has been a primary component of three dimensional rendering technology since its inception in 1991. OpenGL is implemented in a wide variety of applications, ranging from professional design software to multimedia presentations to interactive games. Currently available as version 1.4, OpenGL has proven to adapt with the evolution of graphics hardware, though it's age is becoming starkly apparent as compared to Microsoft's latest DirectX D3D technology. In hopes of revitalizing the decade old standard, 3Dlabs recently offers a new approach outlining the features of a possible OpenGL 2.0 revision. The concept of a proposal as compared to a standard needs to be clearly defined for the purposes of this preview article. The OpenGL 2.0 topicalities presented here are based upon a discussion text and early developmental engineering from 3Dlabs. Many vendors usually submit discussion texts and/or proposals during the OpenGL ratification process, then an appointed governing committee will analyze the various aspects of the given information before reaching an agreement about the final published standard. Since the OpenGL 2.0 development process is still in finalization stages, the information presented within this text will likely undergo multiple changes before a final OpenGL 2.0 specification is adopted for widespread industry use.
About 3Dlabs
3Dlabs has been a long-time contributor to the OpenGL community by providing advanced 3D hardware solutions to the professional marketplace. 3Dlabs graphics accelerators are commonly utilized for computer-aided design, multimedia development, and special effects rendering. 3Dlabs technology can also be found in many non-PC devices like military aircraft and personal cell phones. 3Dlabs is a wide market corporation with operations currently in Alabama, California, Massachusetts, Texas, Washington, Germany, Japan, and the United Kingdom.
OpenGL 1.x Limitations
The bulk of graphics development was centered on 2D rendering until 1997. The only areas of computing utilizing 3D technologies before this time were generally in the extremely high-end professional markets, such as CAD or virtual reality. The mid-90's release of desktop-oriented 3D accelerators like 3dfx's Voodoo or Rendition's Verite ushered in the concept of affordable 3D graphics for most mainstream PC users. Nearly a half decade later, desktop 3D video cards now include options like cube mapping, hardware transform/lighting, and programmable vertex/pixel shading. The OpenGL interface has evolved along with these new rendering features, but today's OGL 1.x does have substantial room for improvement as the next generation of video chipsets could finally outpace the capabilities of this venerable standard.
For example, the popular OpenGL 1.3 API suffers from several major limitations, especially in regards to extending the base programming interface to include additional rendering options. The base OGL 1.3 specification documentation is approximately 284 pages of programming conventions and theory, while nVidia's extension documentation needed to implement options like per-pixel shading is well over 500 pages in length. The concern over efficient programming is clearly apparent once one factors in proprietary extensions from other corporations like ATI, Matrox, STMicro, and the vast number of other companies currently offering OpenGL compliant drivers.
The age of OpenGL 1.x is the primary contributor to these limitations, as hardware has evolved at such a rapid pace over the past few years. System that were once considered to offer high performance only a couple of years ago are now entry-level configurations at best. The rapid development of hardware plays a significant role, as many manufacturers are adding OpenGL extensions without any real inter-corporate centralization in order to release products by usually grossly misrepresented retail availability deadlines.
Worst yet, it appears OpenGL is following nearly the same development paradigm as DirectX. DX7 was the last fixed-function D3D interface, with the current DX8 standard being devised around poorly coordinated implementations of programmable rendering options. DX8 offers v1.2 programmable options, while DX8.1 offers a slightly improved v1.4 programmable feature set. This development schedule can wreak havoc on developers and hardware engineers. For example, the GeForce-3 supports v1.2, but the Radeon 8500 supports v1.4. In can be expected that programmers will likely opt for the lowest common denominator when coding, thus it is suspect whether some of these staggered options will ever be included in software released in the near future. Only with the release of DirectX 9 does Microsoft plan to offer a hardware independent programmable interface.
Some developers have proposed extensions to OpenGL 1.x to add programmable rendering options including various extensions which may not be compatible with hardware from another manufacturer. Efforts are also being established to institute a generalized extension set for programmable shading, though these are still largely hardware dependant, thus they will not work with all OpenGL implementations. The goal of 3Dlabs' OpenGL 2.0 initiative is to create an uniform standard with a hardware independent shading language that functions with nearly all OpenGL compliant graphics accelerators.
OpenGL 2.0 Envisioned
3Dlabs hopes to address several key issues with its OpenGL 2.0 approach. OpenGL needs to evolve into an easier to code interface format with optimizations for memory management and timing control for increased performance potential. Another issue to be addressed is how to deploy generalized programmable shading routines which are hardware independent. The overall predominate concern is maintaining complete backwards compatibility with OGL 1.x standards while retaining the functionality of the new standard's advanced rendering options.
3Dlabs has received positive support from many facets of the graphics engineering community. Universities like Stanford are already hard at work on extended OpenGL rendering routines which support some of the v2.0 conventions. Most hardware manufacturers and software vendors are also expressing overwhelming support, as an improved OpenGL standard could lead to better graphics and performance with less development overheard and greater product turnaround times. Regardless of those involved, 3Dlabs is working towards a future OpenGL 2 interface without any imposed royalties or operating system limitations in hopes of establishing a wider market base.
OpenGL 2.0 Explained
The 3DLabs approach is to first extend software through utilization and public promotion of certain OpenGL 2 standards, then gradually move code towards a "pure" OpenGL 2.0 environment. However, unlike DirectX 8, all OpenGL rendering conventions should be available for those seeking a pure OGL implementation at release, instead of staggering the releases in various subset revisions. As stressed earlier, the ultimate final goal is to reach a streamlined programming interface which offers hardware independency.
Each of the programmable processor pipelines (software and/or hardware) essentially eliminate and/or replace a significant portion of current OpenGL conventions. The programmable vertex processor replaces the current options for transform, lighting, normalization, texture coordinate generation, and fog rendering. The fragment processor replaces the current operations for smooth shading, texture access, texture application, alpha testing, and pixel transfers. The pack/unpack processor included capabilities for flexible pixel formatting during memory move operations to create a coherent and consistent stream of pixel data to the rendering pipeline. The clear benefits of these programmable options are increased performance and image quality by removing the dependence upon fixed functions of static T&L pipeline routines. The associated rendering conventions for each of these advanced routines are unified through a comprehensive C-based programming language with special detail added for vector and matrix processing operations.
3Dlabs also implements a new data buffer mechanism to be utilized for enhancement of the programmable rendering interface. The buffer is used to enable multiple-pass fragment programs with full stream processing support. Usage examples include multiple outputs from a single fragment routine, intermediate result storage, multi-spectral imaging, and acceleration of back-end rendering by reducing the time needed for read-back of floating-point images by the host bus. Additionally, the buffer space is accessible through either spatial or FIFO memory operations.
Today's OpenGL 1.x provides no real direct control over when or where objects are stored or deleted within the memory address range. OGL 1.x also provides no direct control over memory copies or address fragmentation. 3Dlabs plans to implement a new management routine to allow for improved timing control over memory operations. The OGL 2.0 proposal sets policies and priorities for all datasets with timing estimates provided for each task. Additionally, all pinned policy operations allow the application to control memory store/delete and packing operations.
John Carmac's Opinion
"Given the good first impression, I was willing to go ahead and write a new back end that would let the card do the entire Doom interaction rendering in a single pass. The most expedient sounding option was to just use the Nvidia extensions that they implement, NV_vertex_program and NV_register_combiners, with seven texture units instead of the four available on GF3/GF4. Instead, I decided to try using the prototype OpenGL 2.0 extensions they provide.
The implementation went very smoothly, but I did run into the limits of their current prototype compiler before the full feature set could be implemented. I like it a lot. I am really looking forward to doing research work with this programming model after the compiler matures a bit. While the shading languages are the most critical aspects, and can be broken out as extensions to current OpenGL, there are a lot of other subtle-but-important things that are addressed in the full OpenGL 2.0 proposal.
I am now committed to supporting an OpenGL 2.0 renderer for Doom through all the spec evolutions. If anything, I have been somewhat remiss in not pushing the issues as hard as I could with all the vendors. Now really is the critical time to start nailing things down, and the decisions may stay with us for ten years.
A GL2 driver won't give any theoretical advantage over the current back ends optimized for cards with 7+ texture capability, but future research work will almost certainly be moving away from the lower level coding practices, and if some new vendor pops up (say, Rendition back from the dead) with a next-gen card, I would strongly urge them to implement GL2 instead of proprietary extensions."
John Carmac Lead Programmer ID Software
Final Thoughts
OpenGL 2.0 is still in its development stages, though 3Dlabs does offer some insight into the new features needed for this aging standards to maintain acceptance within the graphics marketplace. As noted earlier, the concepts and ideas presented here are only preliminary at best. The information gathered for this article was obtained through various discussion overviews published by 3DLabs and associated companies. It appears 3DLabs and other developers are steadily moving forward with development of a new and exciting OpenGL standard that strives to offer the best compatibility with sustained performance across the widest variety of hardware configurations available.
With the long history of slow moving approavals for the OpenGL community, I hope that politics doesn't take over and bring the approval system back to a crawl after Version 2 is released.
Nah, I just got the impression that MJ just cut'n'pasted directly from HardOCP. Word for word. I kid ye not.
The continued success of OpenGL is vital for the survival of Linux on the desktop.
Remember that Apple and the Mac OS rely on OpenGL for graphics. That combined with continued interest in OpenGL on the PC side for CAD and the like -- not mention Carmack and Co. -- should keep OpenGL around as a viable alternative.
Ooh, a sarcasm detector. Oh, that's a real useful invention.
That's past-tense. He hated Direct3D back when Direct3D blew goats (DirectX5? I can't remember) 5 years ago. MS listened to his complaints and vastly improved the API.
(full quote, for the parent is at Score: 0)
It shouldn't make any difference. Since C++ is a superset of C, you can use OpenGL just fine with it (and if you can't find one of the 092384092389 C++ wrappers for OpenGL out there, you can always wrap it up yourself). At the same time, COM has always been available to C code as well as C++ code, so you can use DX in C as well (it's just very ugly). In either case, I don't think the native language of the library should make a difference -- COM is supported by many languages (some requiring that the COM object support the IDispatch automation interface, but I believe DX already does that, and if it doesn't you can wrap that yourself or find bindings that somebody has already done), and thus DX is available (C, C++, VB, Delphi, Java, and all of the managed code langauges). OpenGL is written in C, which means it's easy for developers to write bindings for other languages (C++, perl, python, ruby, etc).
The moral of the story is that any properly designed library will be available across languages, so don't let the library tie you into a language you don't know or like.
You can use DirectX in C if you want. It's a little bulkier, but certainly manageable. This link describes the biggest change you'll have to deal with when going from C++ to C with DirectX. The example from that page goes like this:
g_pDP->Initialize( NULL, DirectPlayMessageHandler, 0 );
To make the same method call from C, use the following syntax. The conventional name for the vtable pointer is lpVtbl.
g_pDP->lpVtbl->Initialize(g_pDP,NULL, DirectPlayMessageHandler, 0);
As for your question: no, I doubt it. The C vs. C++ thing isn't really a problem since nearly all modern compilers support both. They'd choose OpenGL over DX (or vice versa) for different reasons. If you were to build a 3-D engine, you could expose a C or C++ API using either library under the hood.
The cross-platform one is interesting if you're in the games business, since of the commercially viable platforms (i.e. Windows PC and the consoles - even if both of the Mac owners buy your game you'll never recover your costs), OpenGL is supported on precisely one of them, whereas Direct3D is supported on two (PC and Xbox).
GCL-GL.tar.gz: OpenGL/Mesa and Xlib bindings for GCL (Gnu Common Lisp).= &ie=UTF-8&oe=UTF-8&selm=MANN.96Dec12144405%40orasi s.vis.toronto.edu&rnum=1
http://groups.google.com/groups?q=gcl-gl&hl=en&lr
http://www.cs.toronto.edu/pub/mann/Software/Lisp/
Mesa is a "more free" version of SGI's OpenGL.
OpenGL on playstation2
OpenGL on the Xbox
This is a great quote from the article, turns out OpenGL is superior than Direct3D on the XBox.
FYI - WineX uses OpenGL to emulate DirectX! OpenGL is indeed critical.
The Raven
The Raven
Shader's are just the logical next step in the progression of the 3D pipeline from fully fixed function to totally programmable. In a fixed function pipeline, you've got specific steps that the data goes through. Ie:
e 4. asp
- App send OpenGL vertex data.
- Vertex data gets rotated, translated, and scaled according to the modelview matrix.
- The scene is project onto the screen using projection matrix.
- Triangles are constructed from projected vertex data.
- Triangles are broken down into scanlines, and color values are stored in the framebuffer based on a specific combination of material color, lighting, and texture information.
The OpenGL 2.0 programmable pipeline is different. In addition to the features of the fixed function pipeline you have additional steps.
- Verticies, instead of going through a fixed set of transformations, instead go through a shader program. The shader program manipulates the position of the vertex much more flexibly than a fixed transformation. For example, a vertex program could make the verticies of a flag move to simulate the waving of the flag in the wind. It can also do similar things for water or cloth.
- Pixels, instead of being colored according to a fixed formula involving material, lighting, and textured, are also run through a mini program. The pixel shader (also called fragment shader) is presented with a set of inputs (texture data, lighting information, material color) but has the freedom to access other data as well as do its own computations. This allows advanced effects like more realistic lighting, bump-mapping, basically anything you can program.
- Instead of having fixed conversions between different data formats, you have what are called pack/unpack processors. You can run mini programs on the pack unpack processors to flexibly translate between data formats without losing the benifet of hardware acceleration.
All of thse features allow far more advanced effects than what is possible with a fixed pipeline. For a look at exactly what effects are possible:
http://firingsquad.gamers.com/hardware/r300/pag
NVIDIA has a pixel shader design program you can check out.
Doom III uses pixel shaders for dynamic shadows, among other things.
A game called AquaNox uses pixel shaders extensively for water effects.
Unreal Tournament 2003 uses pixel shader as well.
A deep unwavering belief is a sure sign you're missing something...
IIRC, nvidia originally ported their drivers to linux for the high end cards that graphic designers use since a lot of movie rendering and CAD things are moving to Linux, and that's a VERY lucrative market. And from what I've heard, the FreeBSD port was a whim of a few employees, and wasn't THAT much work since they allready had the linux port, they just needed to tweak the kernel hooks.
Voxel primitives are there: 3D textures.
Radiosity and raytracing are difficult to put in hardware because they would require you to have a full description of the scene in memory. This flies agains a fundamental assumption of OpenGL that geometry may be streamed to the video card -- keep the state small. A scene description language that performs radiosity calculations should be a layer on top of OpenGL, not subsumed into it. OpenGL's design intent has always been "Provide a wafer-thin layer of sanity over the graphics hardware so that people can make things go really fast." It has never been "Make programming graphics easy." Making graphics programming easy is the job of other layers such as Crystal Space (games) or VTK (visualization).
For me, the coolest feature of OpenGL 2.0 is hardware independence. This means that an OpenGL 2.0 driver will work with any OpenGL 2.0 card; no more need for drivers specific to one video card. Vendors will probably implement all kinds of extensions in their hardware that do need specific drivers, but the basic functionality would Just Work (WOW). This may not matter much for game || app developpers, but it matters for the end user, especially when this end user is using some alternative operating system. I know that myriads of cards that do accelerated 3D don't do so under Linux, simply because no driver has been written for them. This is going to change once cards support OpenGL 2.0, and I am looking forward to that, as none of the cards I have worked (with accelerated 3D) last time I checked, even though all of them support OpenGL. Yes, I know some are going to say that I should have bought different hardware, or written a driver myself. You are right. I am cheap. I am lazy. I want OpenGL 2.0, cause then it'll Just Work (WOW). Cheers!
Please correct me if I got my facts wrong.
Correct. John Carmack made a post on slashdot which nulled many of the statements he had about earlier versions of DirectX.
The comment can be found here
I don't normally post to slashdot but having read some of the comments I just had to say something.
First thing: there's is a common misconception that DirectX is "light years" ahead of OpenGL. That couldn't be more false. There are quite a few things that you can do in OpenGL that you wouldn't be able to in DirectX. Here's a good example: GeForce register combiners.
On the other hand there is nothing DirectX (or more correctly Direct3D) can do that OpenGL can't. All of the functionality is present through extensions.
Main problem with OpenGL is not functionality - it's the extensions. Different graphics cards support different extensions that provide the same functionality but to get your code to run on both cards correctly you have to support both extensions.
The whole extensions mechanism is a mess really - it was a good idea while the number of extensions was small but these days there are way too many of them.
Another misconception (and I just can't see where exactly is this coming from) is that DirectX is faster than OpenGL. On nVidia cards at least DirectX is most definitley not faster than OpenGL. Run any game that supports both APIs and OpenGL is almost always faster. This is not noticable on really powerful systems but on slower ones OpenGL runs slightly faster. For that matter just look at all the abstraction present in DirectX - abstraction does not come for free, there is a performance cost - it's small but it's there. OpenGL on the other hand is nice and clean.
Not to mention that DirectX uses a lot more memory than OpenGL.
I also noticed someone saying that DirectX drivers are easier to implement. That is most certainly not true. I find it puzzling that there are so many graphics cards with bad OpenGL drivers because OpenGL drivers are relatively simple compared to DirectX ones. I'm guessing the main reason is that DirectX is more popular and hence better supported.
And to the guy who mentioned hardware independence, sorry to disappoint you but OpenGL 2 will not be any more or less hardware independent than OpenGL 1.x.
OpenGL is a standard just like DirectX, not a driver. That means that graphics card companies will still have to write OpenGL 2 drivers - there won't be one driver for all OpenGL 2 cards. Before you post something incredibly stupid again use your brain for a minute and think about it.
OpenGL is essentially a giant state machine. You issue a glTexture() command and now everything is drawn with that texture. Anything... from bound texture, to blending function, to rendering triangles vs. vertex arrays, is a state that can be changed. Whenever you render some fancy textured, lit, alpha-blended scene, with different materials (say, Quake 3), there are a LOT of potential state changes.
State changes are SLOW, and so anyone hoping to render mildly complex scenes had better find a better alternative to resetting the state for every object in the scene. Well, there is... lazily update the states (only change the states that need changing, instead of manually setting every one). You could even go one step further and sort how you render your objects based upon state, so as to cause the least number of changes possible.
Today, OpenGL drivers DO NOT KEEP TRACK OF THE STATE. They just merrily pass the state-changing function calls along. Thus, the programmer is forced to go through the tedium of creating some abstraction of OpenGL states, and tending to it themselves. This is frustrating boring work, there is no reason this shouldn't happen transparently!
VTK is (or at least was, last I heard) guilty of not managing states lazily. A professor around here was working on a project to render from VTK to a large tiled display, which he did by more or less replacing the opengl driver with his own custom tile-display creation. It just happened to lazily update states. The end result was the uber-demo-model displaying smoothly on the tiled display, while chunking along at 10-15 FPS on the actual computer monitor!
OpenGL implementations need to keep track of their rendering states, not just send the requests off to the card!
- spiff
And also (correct me if I'm wrong) I thought that OpenGL had to be integrated with the operating system. When MS dropped support, they effectively froze progress for OpenGL on that platform.
You are wrong. OpenGL drivers are just that, hardware drivers. Updating OpenGL on Windows is simply a matter of replacing a DLL. Microsoft's support or lack thereof simply means that those DLLs will have to be written by 3d parties.
> What 3D library does, say the PS2 and the Nintendo console use?
PS2 - (sarcasm) What! PS2 uses a 3D library?! (sarcasm off)
You write your *own*, or use a middleware solution: RenderWare, NetImmerse, etc. Sony only provides a bares bones library with basic functionality that sometimes the samples use.
GameCube - I forget the name of the API. It is OpenGL like, but not the same. I'll post a follow up when I get into the office, since I'm not the Gamecube programmer at work.
X-Box: A bastardized version of DirectX 8.0/8.1
> Their own in-house one?
Only if you got 6 to 12 months to write & optimize T&L code, Clipping, Stripping, Smart Batching, Advanced Filters, and a Mesh/Bone animation system!
> I'd guess OpenGL, because it's available on many platforms, and it's portable.
Guess again. I don't know of ANYONE shipping titles using OpenGL on the consoles.
X-Box - Why would you waste time trying to get OpenGL to work, when DirectX 8+ allows for your PC (DX) engine to be ported over in *days*. You can use OpenGL for testing, but you have to go thru some hoops to get it to work (when I heard last year)
GameCube - No need, since the existing API works just fine.
PS2 - While there is PSGL (OpenGL clone), OpenGL will NEVER run at full speed on the PS2 - due to missing *hardware* functionality: i.e. no stencil buffer, limited (some say broken) blending modes, etc. You need to go straight-to-the-metal to get optimal performance out the machine.
> It's a wise choice if you do console development on a workstation and if you can just cross-compile so it'll work on the console.
Ha! If it only were that easy. Sorry, I don't mean to sound pesimestic but I've seen way too many "the bug only happens on the PS2, but not the GameCube, X-Box, or PC. Argh" this year.
PS2 - The hardest parts are making efficient use of the 7 cpus, managing the 4 Megs of Video Memory (4-bit and 8-bit palletized textures help), managing a couple hundred megs of audio on disc thru the 2 Megs SPU (Audio Chip), smart streaming on the 2 Meg IOP, and keeping the VU's and GS well fed.
GameCube - making good use of A-RAM on the GameCube, etc. Again, not the gamecube programmer.
But yes, you're right. If you write your own middleware, the game code doesn't have change (much) for the various consoles.
I really hope OpenGL 2.0 revitalizes OpenGL, because it's a real pleasure to use, but I don't see OpenGL support on consoles at least until PS3, X-Box2. (Haven't heard anything on GameCube2)
Cheers
Many years ago (now), I worked on D3D at Microsoft. ,and 1.3 and below are nVidia. Pixel shaders prior to 1.4 are awkward, t say the least.
The constrasting APIs are quite different in their approach, but both have the same aim - that is, to enable 3D rendering on hardware devices. A few comments...
Extensibilty.
The only reason why D3D is not extendable is a decision made within MS. The underlying DDI (Device Driver Interface) supports extensions (I should know, since I designed it originally), but MS decided a long time ago not to expose them to the user. From the OpenGL perspective, you have to watch for 'proprietary' extensions that are, for licensing reasons, unlikey to be generally supported.This leads to a lot of vendor specific code.
Philosophy.
OpenGL, except for extensions, is very hardware transparent. You don't have to worry about capabilities, at least as far as the basic code goes. The driver (or more commonly library) emulates those things it does not do natively - as a result, OpenGL is more portable to new hardware than D3D is - in theory, an OpenGL implementation could be entirely software driven, and you wouldn't know it.
D3D, on the other hand, was designed originally to expose as much of the hardware as possible. In theory, this would allow software writers to only use those things that were really accelerated.
But as hardware has become more complex, the OpenGL model (with it's assumption that everything is fast) becomes more compelling.
User level code.
OpenGL runs at user level, and that gives it a significant advantage over D3D, which is a mix of user and kernel. Due to the lack of context switches, OpenGL can almost always beat an equivalent D3D implementation, no matter what batching of primitives D3D tries to do. In thoery, there is no reason why D3D could not run in the same way, but in practice the powers that be at MS have decided otherwise. I happen to believe this is a loss for MS, but who am I to decide.
Shaders.
This is the area of most contention between D3D and OpenGL. The D3D model is based (almost certainly) on the nVidia model, whereas the current OpenGL model is purely based on extensions. We get into awkward territory here, since the ATI and nVidia extensions are markedly different. This is exposed most obviously in the D3D pixel shader versioning, where PS 1.4 is ATI
Support.
Microsoft supports OpenGL beacaue it has to, not because it wants to. Back in the early days, there was a possibility that support would be dropped, but sensible (i.e. a few) people in MS knew that it was a requirement for those areas MS was most keen to be in - for example, Workstations.
The Future.
I have no doubt that both APIs will continue to be expanded, with D3D lagging slightly because of the afore mentioned differences. OpenGL 2.0 may resolve some of the conflicts, but given it's heritage (3Dlabs), it's possible that it may be further from the real major hardware (ATI and nVidia)than the extensions. As they say, it's impossible to please all the people all of the time.