Meteorhead

A different type of 'vision'

Discussion created by Meteorhead on May 29, 2011
Latest reply on Jul 2, 2011 by williammorgan27
DirectX become something new

Hi!

Forgive me for the longer post, but it takes a few lines to make my point. This is some sort of a suggestion, or just a word of thought how thnigs could look according to meóy ideas.

I have read two different statements about graphics APIs hindering game development. One was from one of the spokespeople at Crytek, and the other was from Richard Huddy (link), developer relations manager at AMD. To summarize the issue was that developers (and you must assure me in this, as I am OpenCL developer mainly, just getting to know OpenGL) that in lead game engine development it is a hurdle that on a console over 6 times more API calls make it through per frame as opposed to the PC, not to mention that console SDKs allow low level access to the HW, which allows innovation in the graphics engine. These were the two arguments behind the slogen: make the API go away!

Of course there is a need for APIs, just on a different level, somewhat lower. DirectX was created to offer a unified, vendor independant way of programming graphics. It was all nice, up until the GPUs got too strong for the CPU to translate and convey API calls to the graphics driver. Lower lever, less translation would allow more calls, and access to intimate HW features. What would happen if both AMD and NV would create a low-level graphics API similar to CUDA and CAL as in the GPGPU frontline. (Let's not talk about CAL being hidden from developers for a moment) OpenCL programmers all know that both CUDA/CAL are the means to access the vendorspecific HW features, and as such OpenCL is a port to CUDA/CAL, it is translated almost as it is to those features. Why not do the same with graphics? Why not create a similarily low-level API to access the GPU from a graphics point-of-view, and have DirectX and OpenGL serve as a port to these APIs? We have seen something similar some 13 years back and it was called Glide (by 3dFx). It was an API that was driven by the HW. If a new HW feature came, Glide gave a function to access it. NV purchased 3dFx, the owner of the Voodoo frontline, and along with it SLI architecture (which the basics was developed by 3dFx, a little history). Some years later NV released CUDA, which was similarily a vendorspecific API to access their HW, and it was a major success.

If graphics developers would welcome the fact that they access low-level HW for graphics purposes, why not? Large developers like Blizzard, Valve, etc. could surely allow themselves to have two seperate render engine developer groups (which is always at most 5-10 people in a project). One specialised on the NV API, and one on the AMD API? Smaller studios who cannot afford so many programmers simply write DirectX/OpenGL code, which is somewhat suboptimal to the vendorspecific ones, but still performs well. (Same is done with GPGPU. If you want big magic, you use CUDA/CAL, if you want portability and good cross-vendor programming and compiler optimizations suffice, than you use OpenCL)

It is somewhat annoying, how a consoles still running GeForce 8900 still look just as good as a PC game, with GPUs at ~5TeraFlops. This is a joke, really. OpenCL does kernel compilation once during init, and after not so many kernel calls are needed (4-10 max per frame/iteration) and depending on the use, realtime is not even a goal (scientific HPC). If one wishes to use OpenCL for physics and AI in a game, still 10 types of kernels will surely be enough, and that works just fine. DX API translations are done more often, and as such consume a lot more useful CPU/BUS time. I would really welcome games that look a whole lot better, and seeing new techniques that utilize the HW to the fullest.

Now let me ask the developers: would this be a favorable course of events?

Outcomes