John Carmack, of DOOM, Wolfenstein, and Quake fame, has spoken out on the issue of Direct3D vs OpenGL in an interview with the folks at bit-tech. Check out the article here. Note that Carmack is still using OpenGL in his game engines because of cross-platform compatibility reasons, but prefers Direct3D’s more modern API.
It’s sad to see OpenGL in such a state of disrepair that even a contributor (id Software) to the specification denounces the standard.
It’s almost weekend, and time for a lighthearted post on the two realtime 3D computer graphics libraries that are available on Windows in 2011: OpenGL and Direct3D. The reason I mention the year is simply because of the fact that two years from now, this information will be as untrue as the Wikipedia article* on this matter due to rapid hardware and software developments. But for now, let’s bash it out.
Apparently, the DirectX team has had a blog since late April of this year it’s just not very popular I guess.
They’ve posted a shipload of information over the last couple of months, so if you’re like me and had no idea this existed, you’ll have quite some reading to catch up to. It’s mostly about Windows 7 and the new graphics APIs (Direct2D, DirectWrite, etc.) but it’s interesting nonetheless.
Today the August 2009 DirectX SDK was released on MSDN, strangely enough the August SDK was released in September.
This release contains the first official release of Direct3D 11 (RTM), which was previously only a technical preview. According to the release notes, this version of Direct3D 11 will only work on the RTM version of Windows 7, not on the RC and Beta versions. So I guess only vendors and MSDN subscribers will be able to develop software until Windows 7 hits the retail market.
There’s also the issue of pure Direct3D 11 hardware not being sold yet but that should be right around the corner if the SDK is here.
Looking at the few mentioned features on the page (tessellation, multithreaded rendering, compute shaders, Shader Model 5), I’d say OpenGL is in big trouble if they want to catch up.
This weekend I took some time out to reformat my development computer in preparation for Windows Vista. I used Vista before but switched back to XP x64 in less than a week’s time. But heck, after a year and a Service Pack, I was willing to take the chance with Vista.
I wanted to take advantage of the DirectX 10 features Vista exposes since they’re not available on XP but was kind of disappointed with the performance of the API in Vista. It seems to me that the samples provided in the DirectX SDK simply run much slower than on XP.
Granted, I bought the most budget oriented GPU that supports DX10 (Geforce 8500GT 512VRAM) but that was simply because of the reason that I want my projects to be able to run on the lowest budget hardware possible while still being able to access DX10-like features. Dell, in fact, offers the 8400 on their laptops and budget desktop PCs, which is a fair share of the market and should be targeted.
Vista itself seems pretty solid so far; it certainly responds better than a year ago and supports all of my hardware and development tools (VS 2008, AQTime, Intel C++ compiler, etc). The big test will be OpenGL: Will it also have performance drops or stay the same? I’ll see tonight.
OpenGL 3.0 seems to become more and more of a promise that’s bound to be broken; like a friend who promises you to give back the money you loaned him, always tomorrow.
The expected API promises many new features, enhancements and is the first total rewrite of the existing OpenGL Standard. The API promises an interface compatible with the next generation of computer graphics programming and is set to compete with Microsoft’s DirectX 10.
Well, that’s the plan at least. OpenGL 3.0 has been delayed tremendously since its scheduled release in October of 2007. On October 30th of 2007, ARB member Barthold Lichtenbelt (NVIDIA employee) made an official announcement on the OpenGL.ORG forums claiming that the release date was postponed until further notice because “[the OpenGL Working group] don’t want to spend time fixing mistakes made in haste.”
The announcement settled fine with most of the OpenGL community since at least there was news. But after 7 months of neither news nor updates, some of the community is giving up on (or dismissing) the possibility of a new API at all.
But is it really possible to give up on OpenGL? The API is pretty much the only viable hardware accelerated option on platforms other than Microsoft Windows, and even on Windows many developers are reluctant to switch from XP to Windows Vista in order to take advantage of Direct3D 10.
The Khronos Group have been putting out updates on the other software which they maintain the standards of with the exception of their most popular/anticipated one, OpenGL.
So what does that mean? Either OpenGL is being actively developed on and public discussion is prohibited per NDA, or development has halted and there is reluctance in releasing the bad news. My hopes are up for the former option since the OpenGL API is without a doubt the most flexible Graphics API available today.
Of course, there is a third option which is quite scary and different. Khronos has been publishing information on a new API called OpenKODE which bundles several APIs in a DirectX-like manner of platform abstraction. Maybe the OpenGL API will become a part of this which would set back the development even more, but this is (as are the other options) a wild guess.
If there’s one thing to consider, it’s the fact that OpenGL is a standard (a definition), not an implementation. Which means that the actual source code for 3.0 would have to implemented by: A. the independent hardware vendors or B. the platform developers. So even if the OpenGL 3.0 API would be released today, the actual libraries wouldn’t be available yet since the implementation would be missing.
All in all, I think we’re still very far away from seeing a workable OpenGL 3.0 implementation that’s supported ‘cross-platform. For now we’ll just have to do with OpenGL 2.1 or Direct3D 10, which in many cases, is a limited set of options that’s impossible to choose from.
A common novice’s question in context with graphics programming is which API should I use?, Direct3D versus OpenGL or which API is better?. Getting familiar in the Graphics Programming world can be tough since many subjects don’t have definitive answers. This article attempts to clear up some of the mysteries surrounding the APIs and compare them as far as it is possible. The individual APIs discussed in this document are Direct3D, OpenGL and XNA. If you’re new to Graphics Programming in general, read the Graphics Programming article to get a clear understanding of what exactly these APIs do.
This article is not intended to explicitly tell you which Graphics API to use, rather it simply explorer the features and limitations of the APIs discussed.
About Graphics APIs
The following sections explain what a graphics API is, what it does and what influences a Graphics API. The points here are simplified to provide a basic understanding.
A Graphics API is not
The following two section define what a Graphics API is not. If you’re looking for the topics provided here, some suggestions are made for you to continue your search.
…a Game Engine
To be clear about what’s being discussed here: Direct3D, OpenGL and XNA are not game engines. A game engine is a library or program dedicated to delivering high performance interactive 3D graphics, sound, networking, etc. A Graphics API is simply a low-level mechanism to deliver visual content to a computer’s screen. Some examples of game engines are Delta3D, NeoEngine and the C4 Game Engine.
…a 3D Engine
While 3D Engines such as Ogre3D, Irrlicht, et al implement Graphics APIs, they usually provide access to higher-level functionality such as loading models, mathematical functionality and scene management. The graphics APIs don’t provide such functionality but allow the user to create the functionality themselves through API functions provided.
Graphics APIs Usage
After reading the previous section, you might wonder what a graphics API does since it doesn’t create games or manage a scene. Think of a Graphics API as a way to talk to your graphics hardware. A Graphics API allows you to tell your hardware to draw a pixel at location X in a human understandable format.
The Difference between the APIs being the syntax of the way you talk to the hardware. To draw a pixel, API A might require you to type DrawPixel(left, top); while API B requires you to say PutPixel(left, top);. Another difference might be the way the API is initialized and made functional in the context of the code.
The Display Driver’s Role
The display driver’s role is to translate API and operating system functions into a hardware interpretable format. To understand how the process works, here’s a simplified list with the steps involved from the program to the hardware:
Program sends an instruction to the API
API sends the instruction to the Display Driver
Display Driver sends the instruction to the operating system
The operating system sends the instruction to the CPU
The CPU sends the instruction to the graphics hardware
Display drivers require to be updated every now and then. This is because the driver is the intermediary piece between the API and the hardware and is a piece of software, which like all software might contain bugs. Another reason for these updates might be because of added or updated functionality for a specific Graphics API.
Without the presence of a display driver or nonsupporting hardware, an API will likely fall back to a software implementation which means that all API routines will be executed by the CPU. This means that hardware acceleration will not be supported and the execution times are likely to be much higher.
API Image Quality
Contrary to popular belief, APIs rarely (if ever) affect the quality of the final image. To understand why, one must envision the different APIs talking to the same piece of hardware. When API A says DrawPixel(x,y); the hardware receives this as an instruction in machine code and executes this. When API B says PutPixel(x,y); the same instruction will be executed with the exact same machine code.
If a difference in image quality does exist, it is most likely due to the way the display driver interprets the command sent and transforms it into machine code for the graphics hardware to consume or because an API performs an automated transformation beyond the user’s control.
When comparative images show up, it is best to avoid arguments and simply ignore the statements being made since APIs have no control over how the hardware display an image. The only factors in the image quality are the quality of the artwork, the ability of the hardware and the amount of hardware integration (the amount of hardware functions) the graphics API provides.
API Performance
While image quality barely plays a role when considering an API, different APIs can certainly have performance differences. This is usually because of the amount of abstraction occurs between the API and the hardware. Abstraction simply means the amount of functional layers between the API and the hardware. Performance leans heavily towards the amount of code that’s being processed, so in many cases more code equals lower performance.
Introduction to the APIs
The OpenGL API
The OpenGL API is certainly the oldest graphics API between the three discussed in this article. Conceived in 1992 by Silicon Graphics as an open standard for graphics hardware instructions across multiple platforms, it has proven to withstand the test of time being virtually implemented on all major operating systems.
The Direct3D API
The Direct3D API is a proprietary graphics interface for Microsoft platforms such as Microsoft Windows and the Xbox platforms. It was conceived in 1995 for the Windows 95 operating system as part of the Windows Game SDK, which was later renamed to DirectX. Direct3D currently handles all 3D and 2D instructions within the DirectX SDK.
The XNA Framework
The XNA Framework is the youngest of the APIs discussed here, being released in 2007. XNA is an interface built on top of the DirectX SDK and provides high-level Object Oriented functionality for video games. XNA is currently only available in the C# programming language since it’s a managed library based off the Microsoft .NET framework. XNA currently only works on the Microsoft Windows and Xbox 360 platforms.
Comparing the APIs
Cross-Platform Support
When a program will solely run on a single platform, the choice between APIs is usually fairly clear. But it is likely that a product, whether it be a video game or professional software, has to be supported on various platforms.
Currently, the OpenGL API is the only API supported on most major platforms including Microsoft Windows, various Linux distributions and Macintosh. The OpenGL API cannot be operated on the Xbox and Xbox 360 platforms, but can be used on the PlayStation 3 platform.
The Direct3D API will only run on Microsoft platforms such as the Xbox, Xbox 360 and Microsoft Windows but can be emulated on Linux platforms through Wine which reroutes Direct3D API calls to the OpenGL API.
The XNA Framework is currently only supported on Microsoft platforms that can run the .NET framework which is limited to Microsoft Windows XP, Windows Vista and the Xbox 360.
Ease of Use
All three APIs are fairly simple to use with XNA being the simplest API and Direct3D being the most complex API in terms of code syntax. Since Direct3D and OpenGL are both native C libraries, the interface provided does not implement any classes or namespaces.
XNA on the other hand is strictly a .NET platform enabled Framework which means that it cannot be used by native languages, only by managed languages but implements classes and namespaces. XNA also includes a myriad of helper functions and libraries and is fully compatible with the .NET framework.
This means that while OpenGL and Direct3D both are closer to the hardware and can be ported to a higher level language, the time it takes to develop an OpenGL or Direct3D application will be higher than that of an XNA application. The trade-off is explained in the next section.
Performance
Since OpenGL and Direct3D are C-based APIs, they are closer to the hardware and implement fewer levels of abstraction. This means that the performance differences between Direct3D and OpenGL are minimal. Any significant performance differences are likely to be the result of the way the display driver interprets the API commands.
The XNA Framework on the other hand is a .NET library which invokes native Direct3D calls to be used on the virtual machine in which the .NET Framework operates. This high level of abstraction can cause performance issues and it is recommended to use the XNA Framework solely for lower performance applications.
Features
APIs are usually limited by the amount of features they implemented at the time of release. This causes the developers of the API to update the API, increase the version number and release a newer version. DirectX/Direct3D is limited by such restrictions, yet updated versions of the SDK are being release routinely every three months.
The OpenGL API includes an extension mechanism which allows independent hardware vendors or end-users to implement their own features whenever a driver is released or with a next generation of graphics cards.
The XNA Framework is based on Direct3D version 9 and can only include the functionality provided by this API. If a newer version of Direct3D is released, the XNA Framework will have to implement the new functionality afterwards. This causes the library to be one to several versions behind current standards.
Support
The OpenGL API is a community supported and developed product and currently has a new version scheduled for 2008, OpenGL 3.0. The OpenGL API is not often updated, 2.1 being the latest version from 2006 and development has fallen behind schedule as OpenGL 3.0 was supposed to be released in 2007.
The DirectX API is both community supported and professionally supported. Professional support requires at least an MSDN subscription to access the support features. A new version of the DirectX API is released every three months.
The XNA Framework is also both community and professionally supported, similarly to DirectX. XNA releases are announced in advance but doesn’t have a set update schedule.
Popularity
The Direct3D API is extremely popular with Windows and Xbox platform developers where the gross of the game development occurs. Since Direct3D is developed by Microsoft, it lends itself well towards Microsoft’s platforms.
The OpenGL is popular amongst both professional graphics developers and game developers, although its usage in video games has declined somewhat since the early 2000’s. It is the only available option on non-Microsoft platforms for hardware accelerated graphics.
The XNA Framework is very popular with hobbyist programmers and lends itself well towards learning how the concepts of both 3D and 2D programming works. Yet, only a few professional titles have been released using the XNA Framework.
Licensing
An important aspect of releasing software are the license restrictions which an API might implement. Both the OpenGL and Direct3D APIs have a licensing model which allows a developer to use the APIs in a commercial product without restrictions.
To release commercial software which implements the XNA Framework 2.0, a license agreement must be agreed upon between the developer and Microsoft which prohibits the usage of the network code provided by the XNA framework. The XNA Game Studio may not be used to create commercial titles for Xbox 360 but commercial Windows titles may be released. To distribute titles on the Xbox 360 platform, a $99.00 fee must be paid in order to be able to access the functionality provided by the XNA Creator’s Club.
There has been a firestorm of discussions on the topic of “Is Direct3D 10 on Windows XP Possible?” This article will attempt to provide an answer to this hot topic. The answer has already been provided by Microsoft’s officials on several occasions but regardless of the manner in which DirectX 10 functions in Vista, would the functionality provided in Direct3D 10 be possible to implement? The official answer is a resounding no for the entire DirectX API, but what about Direct3D 10 which would be the only API of interest here?
What’s the argument?
Like any Direct3D version, Direct3D 10 is an API which abstracts a pre-defined set of functionality (as much as the API supports) of the underlying hardware. Ever since Direct3D 10 came out however, the minimum hardware capabilities were defined by the API rather than the hardware. This was a way to eliminate the old DEVCAPS (Device Capabilities) struct found in Direct3D 9 and below and to push a certain level of standardization or conformance.
If we take a close look at the features presented in Direct3D 10, which is easy since it’s predefined (non-expandable), we’ll notice shortly that none of the features are limited to Vista; neither are they unique to Direct3D in general:
Unified Architecture (programmable pipelines)
Shader Model 4: HLSL Pixel Shader v4.0, Vertex Shader v4.0
Geometry Shaders
Texture Arrays
Predicated Rendering
Instancing 2.0, which is a redo of the previous Microsoft Geometry Instancing
When a notice is made that these features were already available under Windows XP through OpenGL 2 and up, attention will most likely be redirected towards the WDDM, which is the Windows Display Driver Model, unique to Windows Vista.
What’s WDDM?
WDDM (Windows Display Driver Model) is a Windows Vista-only Windows Driver Model for IHVs (Independent Hardware Vendors) to base their display drivers on. WDDM allows the developers to take advantage of several new functions not available in the old XPDM Windows XP Display Driver Model, namely:
Virtualized Video Memory:
Allows the Operating system to (optionally) utilize system RAM if the Video RAM (VRAM) is insufficient.
Application requires a to push some data to VRAM via D3D API calls:
D3D10 User-Mode abstract layer handles event and triggers:
The Kernel-Mode WDDM interface determines:
If VRAM is not full, push onto VRAM stack, else:
Push onto RAM stack.
If the application needs to pop the memory from the stack, it doesn’t have to determine where to pop it from since WDDM handles this process. The stack push/pop terminology is used solely for simplifying the example and doesn’t denote the actual inner workings of the WDDM in any way since this is indeterminable.
GPU Threading:
A GPU process runs as a thread on the GPU and allows CPU-like multi-threading on a regular CPU. This means that you can spaw multiple Direct3D processes on a single GPU, thus WDDM must support the following item on this list.
GPU Interruptibility:
Allows process interruption, which means that you can switch from one GPU process to another without the process losing its context and resources.
Direct3D Surface Sharing:
Allows for a different process to access a D3D10 surface. This is necessary for the DWM (Desktop Window Manager) to function properly to allow for a final Desktop composition.
Other Features:
Allows for a Display Driver restart on failure without requiring a total reboot.
The Main Problem
Since the functionality introduced in WDDM is Kernel-Mode, there is no chance this could be implemented into Windows XP unless a total rewrite of the XPDM is initiated. The reason for this is that developers don’t have access to the underlying hardware directly, only through the usage of APIs such as Direct3D or OpenGL. This conversion of XPDM, naturally, will not happen since Windows XP is being deprecated in favor of Windows Vista.
While there have been attempts at porting Direct3D 10 / DirectX 10 over to Windows XP, this will always continue to be the main problem.
Alternative Solution
Using Direct3D 10 as it is provided in Windows Vista in Windows XP is impossible. Yet there is a possibility to achieve the same graphics quality on hardware that supports it on Windows XP; by using the OpenGL API instead. OpenGL allows the developer to access the same functionality provided by Direct3D 10 by using so-called IHV provided extensions but that’s an entirely different article. Also, note that this would only provide the same features which Direct3D provides and none of the WDDM functionality unless you find a way to emulate the Kernel-Mode functionality in User-Mode in Windows XP.
Over the last week I’ve been annoyed with the capabilities of the Intel 945GM chipset. While this chipset is not widely supported in graphics development, it’s a common chipset that Intel has to offer that comes standard with a bunch of PCs. So I’ve unhooked my Graphics card and attempted to run some of my code through this GPU.
Direct3D seems to work fine, pretty fast too. Pixel Shader version 2.0 seems to be supported through hardware, and Pixel Shader 3.0 through a software device. Now, you’d expect that the OpenGL implementation would have the same capabilities, or at least Pixel Shader 2.0 through hardware.
Turns out that the OpenGL version on this device is OpenGL 1.4 with to my knowledge no support for fragment shaders (GL_FRAGMENT_PROGRAM_ARB). I wonder why this is. The hardware capability is available, why not make use of it?
Valve’s hardware survey at the time of this post still reports that 22,183 people out there have the Intel (ialmrnt5.dll) driver. If so many gamers are using Intel’s chipsets, you can expect the regular end user base to be much larger. Why not give them some updates? Please? :o)
Quite recently I released a small article discussing if you (as a developer) should upgrade to Vista to take advantage of DirectX 10 functionality only available in Windows Vista. Quite simply the answer was “yes” in my article. As a developer you should always take advantage of new technologies, specially if that technology will replace an existing technology.
HotHardware.com has released an article more aimed towards the end-user than the developer which discusses the State of DirectX 10. In this article both performance and image quality are evaluated to give a fair estimation.
It’s 13 pages long but worth the read, check it out at HotHardware.com.
Recently I’ve created a post about how id Software will no longer use OpenGL as their primary graphics API for game development. Here’s John Carmack’s response to the rumors:
There is certainly no plans for a commercially supported linux version of Rage, but there will very likely be a linux executable made available. It isn’t running at the moment, but we have had it compiled in the past. Running on additional platforms usually provides some code quality advantages, and it really only takes one interested programmer to make it happen.
The PC version is still OpenGL, but it is possible that could change before release. The actual API code is not very large, and the vertex / fragment code can be easily translated between cg/hlsl/glsl as necessary. I am going to at least consider OpenGL 3.0 as a target, if Nvidia, ATI, and Intel all have decent support. There really won’t be any performance difference between GL 2.0 / GL 3.0 / D3D, so the api decision will be based on secondary factors, of which inertia is one.
Somehow I keep getting back on this topic. Maybe it’s because of the excitement that was involved with the features promised by the idTech 5 engine as presented in the earlier QuakeCon demo.
Today was one of those exciting days for me. I just finished watching a two part video commentary on the development aspect of idTech 5 that was posted on GameSpy. A third video is an interview with John Carmack on the changes that will be occurring within id Software and other issues. The two commentary videos feature commentaries by John Carmack and Matt Hooper from id Software.
Keep in mind that the “lag” that you might notice is because you’re viewing a technical demo of an unfinished product. Another thing that might be worthy to notice is that the OpenGL API is no longer being used as primary graphics API, yet the company is moving towards DirectX as their primary API.
The first video is presented by John Carmack and is about the development of idTech 5 and Rage. The backdrop for this video is pretty much continuous, so you might want to look away to avoid insanity. He speaks about graphics development, Enemy Territory: Quake Wars and other things that might be interesting to developers.
The second video introduces Matt Hooper as a secondary host and talks more about the tools and assets given to the level designers and artists in idTech 5. For an unreleased product, it looks amazing. There seems to be a great (if not massive) improvement over older tools such as GtkRadiant by having a more intuitive user interface. But you can judge for yourself below by watching the videos attached to this post.
The third video announces a new “game” or adaptation of the existing Quake 3 code base and create a free to download online game, hear all about it in the third video.
Edit: as of 2023, it seems that these videos have been lost to the ravages of time.
As a developer (and gamer) you always want the latest gadgets and DirectX 10 seems to be one of these gadgets that you just “need to have”.
But does it justify spending much money for an upgrade?
What does DirectX 10 have that DirectX 9 doesn’t? According to some technology demos - not so much. Ok, some special effects but what about the rest? A game isn’t made out of SFX (although it seems to become a trend).
It turns out that DirectX 10 isn’t only about special effects but defines a new style of next generation technology. Video Card manufacturers are forced to use optimized pathways to support the new industry standard resulting in very fast hardware such as the Geforce 8 series (8800 GTX, 8800 GTS).
One of these features is WDDM which stands for Windows Display Driver Model. WDDM is basically a resource manager for graphics processes. One example of what WDDM does is this: In XP when you switch from one Direct3D application you will receive a DEVICE_LOST exception, which basically means that you can’t run two processes from one GPU. Your application crashes and you’ll have to write X amount of handlers dealing with the exception. According to Microsoft this is now a thing of the past.
Since the Vista desktop is a 3D environment you’d loose your application everytime you minimize. This has now been eliminated. Each GPU process is its own thread (just like in regular programming) meaning that you can have X amount of 3D processes running without the need for special handlers.
Also in the same category is improved crash handling that comes with DirectX 10.
Ok, so that’s neat but I’ll need more to be convinced to switch to DirectX 10 hardware and Windows Vista.
Another feature of WDDM is that if you run out of video memory WDDM can virtualize your System’s memory for video processes. Which - in theory - sounds very cool, but I don’t know if this would cause slowdowns.
Here’s a list of new features
Shader Model 4
Texture arrays
DirectSound is gone, XACT is its replacement
Less load on the CPU - GPU tasks really get processed by the GPU this time
Unified Pipeline Architecture - the Programmable Graphics pipeline (SM 4.0)
No object limit - There is no software limit to how many objects you can add to your scene. The only factor in this is your graphics hardware
Geometry Shaders
Instancing 2.0 - An optimized version of the Instancing technology found in Geforce 6 series up and Radeon 9500 and up
So as a developer is it worth it to upgrade to Vista and DirectX 10 hardware? In my opinion, yes. This is simply the new generation of computer graphics, just because you have to upgrade doesn’t mean is’t evil.
Remember when you upgraded from your TNT 2 card to a Geforce? Same thing. Yet this time the improvements revolve more around the pipeline than the actual quality of the image.
In November of last year, NVIDIA released its latest flagship graphics card chipset, the 8800 / G80. This chipset featured the first full featured DirectX 10 support ever conceived and was (still is at the moment) the only DirectX 10 card on the market.
So when will the other giant, ATi, catch up? According to rumor, ATi is planning to release its latest chipset (R600) in the first quarter of 2007, more precisely an early March launch.
But did ATi push its launch too far back or did NVIDIA jump the bullet on this one? Some say that ATi is holding back for a reason so they can improve their technology and beat NVIDIA performance wise. Others say that ATi didn’t expect NVIDIA to launch this early and is trying to throw together a product too fast. The latter, I personally don’t believe.
ATi has been a major player in graphics technology for a while, so it would be a strange decision to underestimate DirectX 10 and continue focusing on their X1900 technology. I think we can safely assume that ATi is preparing its product to perform to the fullest and maybe be waiting for better software support in Vista - something that NVIDIA has been lacking.
Also, what good is a DirectX 10 card if there are no DirectX 10 games out yet? Again, some say that the 8800 is simply “the best DirectX 9 card out there that happens to have DirectX 10 support.” Yet according to hardware tests on TomsHardware.com, the ATi X1950 XTX stands above the card with full head and shoulders.
So what can we expect in the near future from these two graphics giants? In my opinion (Nostradamus style), ATi will launch the R600 chipset and will make the G80 look like something from 1999 performance wise. The 8800 GTX will get a successor soon enough that will compete with the R600 and I think that ATi will get you more value for the money, as is happening with all AMD and ATi products lately (same company).
I was eagerly looking into buying a G80 or 8800 but I have a feeling I’ll be regretting it within the span of one month. After all, the G80 is already 4 months “old”.
