Going Deeper: The DX11 Compute Shader and OpenCL/OpenGL

Many developers are excited about the added flexibility of the Compute Shader (also referred to as the CS). This addition to the pipeline steps further from a render-centric API and enables more general purpose algorithms. We see added flexibility in both the type of operations that can be preformed on data and the type of data that can be operated on.

In other pipeline stages, we see limitations imposed that are designed to speed up execution that get in the way of general purpose code. Although we can shoehorn general purpose algorithms into a pixel shader program, we don't have the freedom to use data structures like trees, sharing data between pixels (and thus threads) is difficult and costly, and we have to go through the motions of drawing triangles and mapping solutions onto this.

Enter DirectX11 and the CS. Developers have the option to pass data structures over to the Compute Shader and run more general purpose algorithms on them. The Compute Shader, like the other fully programmable stages of the DX10 and DX11 pipeline, will share a single set of physical resources (shader processors).

This hardware will need to be a little more flexible than it currently is as when it runs CS code it will have to support random reads and writes and irregular arrays (rather than simple streams or fixed size 2D arrays), multiple outputs, direct invocation of individual or groups of threads as per the programmer's needs, 32k of shared register space and thread group management, atomic instructions, synchronization constructs, and the ability to perform unordered IO operations.

At the same time, the CS loses some features as well. As each thread is no longer treated as a pixel, so the association with geometry is lost (unless specifically passed in a data structure). This means that, although CS programs can still use texture samplers, automatic trilinear LOD calculations are not automatic (LOD must be specified). Additionally, depth culling, anti-aliasing, alpha blending, and other operations that have no meaning to generic data cannot be performed inside a CS program.

The type of new applications opened up by the CS are actually infinite, but the most immediate interest will come from game developers looking to augment their graphics engines with fancy techniques not possible in the Pixel Shader. Some of these applications include A-Buffer techniques to allow very high quality anti-aliasing and order independent transparency, more advanced deferred shading techniques, advanced post processing effects and convolution, FFTs (fast Fourier transforms) for frequency domain operations, and summed area tables.

Beyond the rendering specific applications, game developers may wish to do things like IK (inverse kinematics), physics, AI, and other traditionally CPU specific tasks on the GPU. Having this data on the GPU by performing calculations in the CS means that the data is more quickly available for use in rendering and some algorithms may be much faster on the GPU as well. It might even be an option to run things like AI or physics on both the GPU and the CPU if algorithms that always yield the same result on both types of processors can be found (which would essentially substitute compute power for bandwidth).

Even though the code will run on the same hardware, PS and CS code will perform very differently based on the algorithms being implemented. One of the interesting things to look at is exposure and histogram data often used in HDR rendering. Calculating this data in the PS requires several passes and tricks to take all the pixels and either bin them or average them. Despite the fact that sharing data is going to slow things down quite a bit, sharing data can be much faster than running many passes and this makes the CS an ideal stage for such algorithms.

A while back we took a look at OpenCL, and we know that OpenCL will be able to share data structures with OpenGL. We haven't yet gotten a developer's take on comparing OpenCL and the DX11 CS, but at first blush it seems that the possibilities opened up for game developers and graphics processing with DX11 and the Compute Shader will also be possible with OpenGL+OpenCL. Although the CS can be used as a general purpose hardware accelerated GPU computing interface, OpenCL is targeted more at that arena and its independence from Microsoft and DirectX will likely mean wider adoption as a GPU compute language for general purpose tasks.

The use of OpenGL has declined significantly in the game developer community over the last five years. While OpenCL may enable DX11 like applications to be written in combination with OpenGL, it is more likely that this will be the venue of workstation applications like CAD/CAM and simulations that require visualization. While I'm a fan of OpenGL myself, I don't see the flexibility of OpenCL as a significant boon to its adoption in game engines.

Drilling Down: DX11 And The Multi-Threaded Game Engine So What's a Tessellator?
Comments Locked

109 Comments

View All Comments

  • Mr Roboto - Thursday, February 26, 2009 - link

    How about this for the Windows 7 release, a DirectX 9 Halo 2 Port For Windows 7 But Needs it DirectX 11 To Run!

    OK so there was and still is no reason that Windows XP couldn't have DirectX 10 or DirectX 11 right? These were just more strong armed tactics by Microsoft to force us to hand them our cash for an aborted OS. Like the 4 year old DirectX 9 Halo port that somehow needed DirectX 10 to run, LOL it still makes me laugh. Whoever though up that idea should be shot. Fucking idiots.

    So how many DX10 games have been released to this day? Ten? How many have been exclusively DX10 like MS wanted? The answer is one the four year old Halo.

    I hope MS continues to hemorrhage money and eventually goes out of business. Nothing would make me happier and it would spur innovation simply by them dying off.
  • MadBoris - Tuesday, February 10, 2009 - link

    Unfortunately the API will not be supported until consoles support it.
    Consoles now control game development technical design, thx to Microsofts sly ways.

    Until next gen consoles come out with the next DX API support then DX9 will still be the standard due to multiplatforming. We can barely get a developer to make the proper PC support changes in their multiplatform games, they aren't going to write seperate render paths unless MS pays them to, like with DX10.

    The only redeeming effect is the Nvidia 8800 GPU is one of the best GPU's I bought because it looks like it will last me many years.
  • vistaisfine - Friday, February 20, 2009 - link

    personally i hope windows LIVE grows. they need it to. its a slick system that works well. at least in dawn of war 2 and gta IV. i don't think your assesment of how quickly developers are adopting DX 10 is accurate. Alot of gaming companys go for a wide demographic and that usually means creating content that can scale depending on the hardware. the reason why there are so many dx 9 game is because the lowest common demoninator gamer runs a dx 9 card. People are finshing maxing out their AGP builds. (crazy as that sounds).
  • Mr Roboto - Thursday, February 26, 2009 - link

    Are you high? GFWL is an abomination. It has absolutely ruined GTA IV as well as all other games associated with it. It's a straight XBox port and it's total shit. There's no dedicated servers, no anti cheat mechanism, no easy way for matchmaking, constant disconnections, I could go on and on. It's very unfriendly and in typical fashion they treat something as trivial as save games as their own property. Go ahead try backing up your GTA IV save games folder and using them on another PC or game installation. It won't work because Microsoft either didn't think about it or more likely purposefully made it difficult because they think it belongs to them and they're in control of it.

    The only value GFWL has for MS (which I should have seen coming) is they're going to launch a digital distribution service. Punks. GFWL is so goddamn broken and yet they're going to try to sell games through it before it's even in decent form? Nice. You can bet they'll be ultra slow to in responding to critical bugs and spyware ready made to steal your info on launch day.

    Fucking garbage. You're settling for garbage. Valve knows how to do things, development, marketing, listening to their fan base, updating their games above and beyond what any other company would do. Even Steam isn't perfect and I'm not asking MS to become them (an impossibility) but Microsoft has a LONG way to come before they're even in the same conversation.

    I hope it crashes and burns even more than it already has because it's ported console junk.
  • jharper12 - Thursday, February 5, 2009 - link

    americunts... that's clever. You got us!! We're idiots! I can't believe we never realized it before! You sir, are pure genius.

    I just feel absolutely terrible that 43 other countries joined us in our latest war. I feel even worse that the entire world economy was brought down by our financial sector that represents about 1% of our $14.33 trillion GDP... I mean I truly feel awful that we are dragging everyone down with us. I wish I could do something about it, but it seems as though everyone believes "americunts are idiots" and then continues to follow us into oblivion. Sorry about that, I wish there was something I could do to help.

    Sincerely,
    Americunt
  • Matrix888 - Wednesday, February 4, 2009 - link

    I'll not be bother with the 2000 or so comments here and reply every one of them, but this is my 2 cents about VISTA:

    1) Drivers issues - there was some initial problem with drivers issues especially old hardware and lazy 3rd parties. But this wasn't MS fault. I've installed VISTA since day 1 and the only problem encountered was an X-FI driver from Creative...which isn't available until like 9 to 12 months later (and it's a beta!!!). Tell me which new O/S doesn't have drivers problem? Win98 was forever plagued with drivers problem, WIN XP suffers similar fate initially, but once the driver matures, it was ok. Hell i've waited for 1 year for an X-FI driver for Ubuntu 7....finally released and the next thing i did is upgrade to Ubuntu 8 (by the time the driver was releasead, UBuntu 8.1 is made available) and it bombs my X-FI.

    2) Memory hogging - another urban legend by people who have no ideas. VISTA does not works the same way like XP. What's the point of having idle memory and not used? VISTA pre-cache ur memory to make it better. 2GB of RAM ran just fine.

    3) You need a high spec PC for VISTA - BS. I've ran an Atom 330 PC with VISTA Premium with Aero on just fine. Even stress test it by opening tons of apps (including a Virtual PC running XP) and it multitask great with all your everyday apps...MS office, Firefox, e-mails, bit torrent etc....only 2GB RAM.

    4) Gaming performance suffers - if you have a moderately new hardware, you are not going to see any difference. I ran my games max settings at 1680x1050. Runs great.

    5) UAC? - Cmon. It's only because XP users never use any other OS like Linux or MAC/OS and they can't get this idea in their head it's for their own good. Linux and MAC/OS will prompts u administrator and password when u try to install something or do something funny. It is perfectly fine and u can always turn it off.

    So far, i really have minimal problem with VISTA. VISTA MCE makes a great front-end for HTPC and believe this, the start up is MUCH FASTER than XP. Sure a fresh XP will beat VISTA in terms of boot up time, but once you installed tons of apps into it, XP will slow like a turtle while VISTA will have minimal degradtion and you get response to your desktop much faster.

    I've finally migrated all my PCs and notebooks last year to VISTA and dump XP forever.

    I've no doubt Windows 7 will be great, but to me, it'll be nothing more than VISTA Edition 2. It'll be re-packaging to wow idiots who simply believe all those VISTA rumours without ever using it (or try to run it on a Pentium 3). Seriously, nobody ask you to install a 3.0 engine into a Japanese kei-car!!! :x

    For the rest of us, it'll simply be a moderate update of a already fantastic OS.

    Hasta La Vista!
  • volgagerman - Monday, February 2, 2009 - link

    One thing that hasn't been stated yet is that the success of any API is directly related to market forces and timing.

    DirectX 9.0c has been successfull largely for two reasons. One, it took advantage of the market shift that developers would target consoles first and port to PC second in order to extract the largest possible return on investment. Two, many of the gaming engines we enjoy today began their life with the release of DirectX 8. It took 3-4 years for those engines to be built, and they finally meshed with the feature set of DirectX 9, as it was an evolution over 8 and not a true revolution.

    DirectX 10 has not revealed any jaw dropping improvements in shipping titles over 9 because developers are still leveraging those engines for exploitation on the console market. They can easily up the visuals for a port to the PC by removing texture compression, upping resolution support and increasing texture sizes, but the major underlying changes to truly support 10 will not happen in the immediate term.

    That brings me to my next thought. From everything I've read, the next generation of consoles are targeted for release in the 2011-2012 timeframe. A true next-gen game engine takes at least 4 years to fully bake. That means Unreal Engine 4.0, Id Tech 6, next-gen Gamebryo are all now in development to be ready when those next-gen consoles hit. It's a safe bet they are leveraging DirectX 11 to its fullest. To go one step further, I would guess that market forces are not going to change in the future, and game developers will still target consoles first and PCs second. What that means in the 2011-2012 timeframe is a solid install base of DirectX 11 on even low-end PCs by that point. It would be a no-brainer to anticipate Microsoft leveraging it's latest and greatest API in the next generation XBOX. With market forces and timing in alignment, the next-gen gaming engines and the the next-gen consoles are set to take full advantage of DirectX 11. I will expect nothing less than revolutionary changes to the quality of gaming graphics in that time frame.

    Here's one final tidbit. If Microsoft takes Intel's bait and utilizes a 32nm modified version of the Larrabee project for a single chip CPU/GPU solution in the next XBOX, developers will have to shift gears yet again and prepare for a rendering model that is mostly software based. That is beyond DirectX 11 and will lead to even more revolutionary changes...Microsoft would no longer be constrained by the capability of their CPU/GPU, but by the efficiency of the software algorithms to achieve playable frame rates. I look forward to a future on consoles and PCs when a simple patch improves frame rates significantly. No hardware update required. :)
  • mechBgon - Monday, February 2, 2009 - link

    Touching on the "rejected" Vista:

    Valve's monthly user survey was updated today. WinXP lost 2.48% in just the last month, and Vista has gained 2.47% of that. The ratio of Vista to WinXP is now 1 to 1.91. I guess you could say Vista is "picking up Steam," ;) and rapidly, too.

    Ten months ago, this AnandTech thread also indicated (much to the OP's annoyance, I'm sure) that even then, the Vista adoption rate among AnandTech Forum users was already about 50%:

    http://forums.anandtech.com/messageview.aspx?catid...">http://forums.anandtech.com/messageview.aspx?catid...

    In light of the readership's tastes, also pretty clearly illustrated in the comments here, I suggest calming the anti-Vista rhetoric and not reading more into things than what's really there.
  • Hrel - Sunday, February 1, 2009 - link

    Do you think someone over there at anand could do an article explaining exactly WHY DirectX 10 can't be supported by XP? PLEASE!!!!!!
  • DerekWilson - Friday, February 6, 2009 - link

    because Microsoft chose to tie in driver specific features to DX10 that make a retrofit not technically possible. Microsoft could have chosen to spec out DX10 so that new hardware features were exposed while simply allowing for a new driver model, but they did not: they required the new driver model features.

    this stuff has to do with power management, threading, OS managed/virtual memory, hardware virtualization (sharing between software and even VMs), etc...

    Now that what DX10 is eternally locked into existence as is, porting back is not possible. We're in a similar boat with DX11.

    There is ZERO technical reason that microsoft couldn't have chosen at the outset to enable the Geometry Shader, to extend const/register limits, and to do all the other things that game developers actually use on Windows XP. It would have required hardware companies to implement a distinct WinXP DX10 driver and Vista DX10 driver, but now that can't be done.

    The /why/ of no DX10 on XP is that MS simply decided not to make that an option when developing DX10 and built in features extraneous to game development that require the Vista platform.

Log in

Don't have an account? Sign up now