The PC gaming market is currently imploding in the face of competition from consoles. For the Mac to 'explode' it would have to take on console gaming directly. That's unlikely outside of the most optimistic fanboy fantasies.
That's not true. PC gaming is not imploding. That's a myth that console manufacturers want people to believe, to make it a self fulfilling prophecy.
As for OpenCL and games, I think the benefits are somewhat overstated: the compute units are typically unused for non-3D work, but when a game is running OpenGL, they are in use, typically running vertex and fragment shaders. I'd expect to see far more benefits from OpenCL in non-gaming applications.
Welcome to the boards Brad! I agree...why would I want OpenCL in gaming? I could be naive but gaming and parallel processing sound like an odd couple. I would think the dynamic nature of a game makes it difficult to break out components and tap the GPU effectively.
This is my biggest beef with the article: the author seems to not know what OpenCL is. Can you tell me how, exactly, you expect it to help out with games? It's a general compute language designed to make non-gaming algorithms run on the GPU with a CPU fallback when the GPU is busy (as it is when GL is typically running). CL use will require work to take advantage of it, not unlike the work you might dig for when planning multi-threaded code because you have to locate and identify algorithms that can run in discrete chunks on a separate processor.
OpenCL works with any program, and that includes games. It's advantage is in parallel programming, which is where most companies, including gaming developers are having some of their biggest difficulties in leveraging the new multi core machines.
By integrating the GPU with the multiple core CPU's, each processor will be able to do the functions it does best, integrating them all.
I think that Stubeck was saying that the games cost 3 times more than the PC equivalent...
Upon a re-read of his post, I agree that's what he said.
I've never seen that price differential though, so it just seems as though he was talking bout the computers themselves. I'll note that on my answer to him.
It will take some time for DirectX 11 to get off the ground. Win 7 won't be released until at least mid year, possibly later. Then it will take some time after that for adoption to get to a useful level. Developers will have to play with 11 before they write to it. We may not see any serious move to it until mid to late 2010, possibly even later, depending on how the adoption of Win 7 goes.
I guess that's what WARP is for, to provide a DX10/DX10.1/DX11 compliant renderer completely in software. I believe WARP and DX11 is already out in beta in the latest DirectX SDK so developers can try it even if no DX11 hardware is available.
From the reports that Intel's Core i7 can achieve higher fps in WARP than Intel's IGPs in hardware, it makes me wonder whether Intel should be proud or not.
Quote:
Originally Posted by melgross
OpenCL has a very good shot here.
I think that Apple should do what MS has done over the years, and simply pay some big game developer to bring one or more of their major games to the Mac and find out if users are interested.
Wasn't it reported that Newell wanted Jobs to pay him $1 million to bring Half Life 2 to Mac? Steve Jobs probably didn't respond well to that.
But yeah, maybe now that Bungie is free, Apple could do something to entice them back to Mac. Or Ensemble Studios which had many of their games come to Mac and who Microsoft is letting go. I guess Apple tried this with EA too, but that seemed to have quieted down now.
I guess that's what WARP is for, to provide a DX10/DX10.1/DX11 compliant renderer completely in software. I believe WARP and DX11 is already out in beta in the latest DirectX SDK so developers can try it even if no DX11 hardware is available.
From the reports that Intel's Core i7 can achieve higher fps in WARP than Intel's IGPs in hardware, it makes me wonder whether Intel should be proud or not.
As far as I know, that's true. But developers are a conservative lot. They won't want to pour too much money into something unless they decide it's worth it.
Quote:
Wasn't it reported that Newell wanted Jobs to pay him $1 million to bring Half Life 2 to Mac? Steve Jobs probably didn't respond well to that.
But yeah, maybe now that Bungie is free, Apple could do something to entice them back to Mac. Or Ensemble Studios which had many of their games come to Mac and who Microsoft is letting go. I guess Apple tried this with EA too, but that seemed to have quieted down now.
Something like that.
Apple has enough money to buy EA if they wanted to, or any other company. At least to take a stake in one. They are all small, and cheap. Apple should have their own games division like MS does, at least to get the ball rolling with a couple of major hits.
OpenCL works with any program, and that includes games. It's advantage is in parallel programming, which is where most companies, including gaming developers are having some of their biggest difficulties in leveraging the new multi core machines.
By integrating the GPU with the multiple core CPU's, each processor will be able to do the functions it does best, integrating them all.
How does DirectX compare?
DirectX and OpenGL are comparable - they are 3D graphics APIs that use the GPU. OpenCL and CUDA are comparable - they are compute APIs that use the GPU for more generalized tasks. DirectX and OpenCL are not comparable in the same way that OpenGL and CUDA are not - they do different things, albeit with the same piece of hardware.
Here's the thing: the GPU is not a magical wonderland of unlimited resources. If you're *already* using OpenGL (or DirectX) for your 3D games, OpenCL (and CUDA) are of more limited use. If you are *not* using the GPU already, then OpenCL and/or CUDA can help a great deal, not unlike making use of SSE or Altivec, albeit more generalized and useful. OpenCL's benefit will come primarily from apps that are already CPU-bound, don't rely on the GPU and could benefit from "one more core".
Brian's example pushes the case a little hard to make the point, although it certainly wasn't easy. Under Leopard, there is a new HID API that provides a lot of the same functionality as DirectInput does so the point is mostly moot now.
Is it easy to use and properly documented? One major problem I had with the old HID was that it was confusing, and the header files that the Apple docs suggest that I read lacked comments explaining the meaning or intent of the entries.
Here's the thing: the GPU is not a magical wonderland of unlimited resources. If you're *already* using OpenGL (or DirectX) for your 3D games, OpenCL (and CUDA) are of more limited use. If you are *not* using the GPU already, then OpenCL and/or CUDA can help a great deal, not unlike making use of SSE or Altivec, albeit more generalized and useful. OpenCL's benefit will come primarily from apps that are already CPU-bound, don't rely on the GPU and could benefit from "one more core".
I thought nVidia's big CUDA push in games was hardware PhysX acceleration, trying to push the idea that the GPU can handle physics faster than a CPU. Granted the GPU may already be heavily loaded, but couldn't a developer take a small fps hit say 10% to offload some physics processing onto the GPU? Since the GPU does physics faster than a CPU, you'd probably free up a proportionally larger amount of CPU cycles for other things like a more advanced AI. It might be a worthwhile tradeoff.
Is it easy to use and properly documented? One major problem I had with the old HID was that it was confusing, and the header files that the Apple docs suggest that I read lacked comments explaining the meaning or intent of the entries.
The "old" HID should never have been used directly - the 'HID Utilities" library Apple provided as sample code was a nice, easy-to-use wrapper around it which we used (and which negates a lot of Brian's 3000 lines).
The new HID is essentially the HID Utilities library cleaned up and provided in OS form. There's a technote on it here. That technote is a little bit of a headache to read, so I'd suggest checking out the sample code, particularly this app.
The usage is not unlike DirectInput on the PC: you query IOHID for the attached devices, pick out the ones you want to use, enumerate the elements on those devices and query those elements for their status. There's calls to hook all that into your run loop as an optional convenience, which makes the API appear more complicated at first glance than it really is. I suspect you'll find it's simple enough to deal with once you dig in.
I thought nVidia's big CUDA push in games was hardware PhysX acceleration, trying to push the idea that the GPU can handle physics faster than a CPU.
It isn't that the GPU is faster at it than the CPU, it's that the GPU can do it at all, so why not let it?
There are two caveats right now: one is that the G80-class hardware (the GeForce 8000 and up) are the only cards Nvidia provides that can cope with a generic compute library on the GPU. When the GPU is busy (or not capable), everything has to fall back to the CPU. The second is that fillrate-intensive games (those running extensive fragment shaders or using multisampling, for example) rob the GPU of most of its spare horsepower. There's a UT3 benchmark out there with PhysX that shows this - as the resolution goes up, the PhysX offloading goes down. The UT3 test I saw didn't make use of multisampling, which has a large impact as well.
The "old" HID should never have been used directly - the 'HID Utilities" library Apple provided as sample code was a nice, easy-to-use wrapper around it which we used (and which negates a lot of Brian's 3000 lines).
The new HID is essentially the HID Utilities library cleaned up and provided in OS form. There's a technote on it here. That technote is a little bit of a headache to read, so I'd suggest checking out the sample code, particularly this app.
The usage is not unlike DirectInput on the PC: you query IOHID for the attached devices, pick out the ones you want to use, enumerate the elements on those devices and query those elements for their status. There's calls to hook all that into your run loop as an optional convenience, which makes the API appear more complicated at first glance than it really is. I suspect you'll find it's simple enough to deal with once you dig in.
I think maybe the book in question might have predated the publication of HID Utilities.
HID Utilities always looked like a mess to me. I'm not seeing much better by looking at the tech note or the code to this HID Calibrator either. main.c is 872 lines.
I think maybe the book in question might have predated the publication of HID Utilities.
HID Utilities have been around since at least 2004, the book came after.
Quote:
HID Utilities always looked like a mess to me. I'm not seeing much better by looking at the tech note or the code to this HID Calibrator either. main.c is 872 lines.
Don't take the "Wil Shipley" line-counting approach and conflate comments, white-space and robust error checking in with raw functionality. The API itself is fairly concise: the example code (in a departure from a lot of samples) attempts to do everything and account for every error. In practice, you'll have maybe a few dozen lines, particularly if you use Cocoa for the dictionaries instead of the CoreFoundation APIs.
DirectX and OpenGL are comparable - they are 3D graphics APIs that use the GPU. OpenCL and CUDA are comparable - they are compute APIs that use the GPU for more generalized tasks. DirectX and OpenCL are not comparable in the same way that OpenGL and CUDA are not - they do different things, albeit with the same piece of hardware.
Here's the thing: the GPU is not a magical wonderland of unlimited resources. If you're *already* using OpenGL (or DirectX) for your 3D games, OpenCL (and CUDA) are of more limited use. If you are *not* using the GPU already, then OpenCL and/or CUDA can help a great deal, not unlike making use of SSE or Altivec, albeit more generalized and useful. OpenCL's benefit will come primarily from apps that are already CPU-bound, don't rely on the GPU and could benefit from "one more core".
DirectX has long been one of Microsoft's crown jewels. By dragging their feet on OpenGL support in Windows - for a long time "OpenGL" was synonymous with "broken or laggy at best" for gamers - MS won a significant position of leverage for itself in graphics. Simply put: the nascent 3D accelerator market of 3DFX, Matrox, ATI and Nvidia formed in DirectX's image. Why? The usual Windows parlay trick courtesy of Microsoft.
If you wanted to sell hardware, you had to support DirectX. If you wanted to win rave reviews, you had to optimize for it like hell.
Apple were wise to pick OpenGL. Apple needed hardware acceleration for Quartz and essentially there was no alternative by then. Console makers also helped OpenGL's relevance by using it when they went 3D in the late 90's. Microsoft responded with the Xbox for obvious competitive reasons as the artlcle describes.
But the GPU industry is still DirectX at its core. Look at the ads or reviews of any card and see how much is made of which DirectX technologies are supported, and how fast. This is what lies at the heart of the game industry's continuing disregard for the Mac (Steam anyone?) and the horrible lateness of Mac compatible drivers.
If OpenCL and OpenGL do unite and take on DirectX's position of age old dominance, this will be very interesting indeed.
I'm not even a gamers anymore, but I know that the consequences of this could be vast.
(Typed on iPod. Excuse the typos.)
Microsoft is going to need a major game change if they wish to prevent OpenGL/CL from taking the cake.
1. Not only is Apple advancing more rapidly than any other computer vendor but they are especially popular with media & younger crowds. Anyone who knows marketing knows these are the groups you want on your side if you want to take over a market, especially kids.
2. XBox is a flop that has been kept barely alive by the Halo effect. PS3 blows the pants off XBox in performance & the Wii is outselling both consoles.
3. People don't buy computers for gaming anymore so the market for who cares about advanced pixel shading or other key Direct3D features is rapidly shrinking & becoming niche. All the money for gaming is shifting towards portables & this is rapidly pushing game developers into the world of OpenGL.
4. Visual Studio has long been in a league of it's own, but the developer tools coming together in XCode is rapidly advancing & becoming more & more comparable to Visual Studio.
5. Developers preference can help guide a product but ultimately it is money. The market has already begun the shift & what will happen is the gaming industry will slowly follow at first & then at some point the developers will get a good kick in the rear (either by company heads or by drop off in sale of their product). You will see a sudden & rapid burst in development towards OpenGL.
Microsoft knows all this & this is why they jumped into consoles & why Halo is probably not the last title that they buy & then lock down to their systems. They have never known how to compete on the technology level, but they have always been good at locking in vendors & manufacturers & then squeezing out the competition. Those tactics don't work anymore in todays society, especially since many younger technologists are tired of it & don't want anything to do with Microsoft.
The only thing that could stop this train now would be for Apple to make some horrible blunder that would completely shut them down, & I just don't see that happening. They've long ago passed the point of small company that could disappear overnight.
I don't know: the last market stats show things being Wii first (by an ample margin), XBox as comfortably second and PS3 third and falling even further back unless its pricing changes.
As I see it, OpenCL is not going to help OpenGL one bit. If anything, there is the risk of it meaning more overhead. OpenCL's real promise is not in gaming but everywhere else where the GPU and other resources are at idle. Also, OpenCL is not going to magically turn apps into multithreading beasts, the same way CUDA doesn't. "Human decision required" here.
OpenGL needs to be a true DirectX counterpart for game developers to decide they can target it and do multiplatform programming. These hopes were dashed with that last iteration after a year of promises.
So I don't think Microsoft has too much to worry about.
I worked on Apple's OpenGL team for a year alongside 4 of the people simultaneously working on OpenCL. A lot of the GL team's work was enabling CL to gain better access to the GPU. Suppose for the moment that I failed to understand a single thing about it and enlighten me.
2. XBox is a flop that has been kept barely alive by the Halo effect. PS3 blows the pants off XBox in performance & the Wii is outselling both consoles.
In terms of market share and performance, it's actually the Xbox 360 that is pulling ahead of the PS3 this generation with sales nearly 2:1 over the PS3 using the November 2008 NPD numbers. In raw numbers, the 360 outsells the PS3 and PS2 combined in the US. The Wii is, as you note, miles above.
Quote:
3. People don't buy computers for gaming anymore so the market for who cares about advanced pixel shading or other key Direct3D features is rapidly shrinking & becoming niche. All the money for gaming is shifting towards portables & this is rapidly pushing game developers into the world of OpenGL.
Agreed about not buying computers for gaming. That said, the main API on the main gaming platform - the Xbox 360 - is DirectX. The PS3 has a stripped down OpenGL ES library, but for best performance developers use Sony's proprietary API, not OpenGL.
Quote:
Microsoft ... have never known how to compete on the technology level, but they have always been good at locking in vendors & manufacturers & then squeezing out the competition.
Microsoft has indeed competed on the technology level with DirectX, and done it well. As for console exclusives, in no way is Microsoft alone here: Sony has also snapped up or purchased rights from developers for Playstation exclusives. Naughty Dog (Crash Bandicoot, Jak/Daxter and Uncharted) comes immediately to mind.
I worked on Apple's OpenGL team for a year alongside 4 of the people simultaneously working on OpenCL. A lot of the GL team's work was enabling CL to gain better access to the GPU. Suppose for the moment that I failed to understand a single thing about it and enlighten me.
Oh, I think you know what it is, but you are just discussing it at its simplest level here. I'm pointing out that it's much more than that.
Just a simple description from the Khronos Group will suffice to show what my statement means overall:
Quote:
OpenCL 1.0 at a glance
OpenCL (Open Computing Language) is the first open, royalty-free standard for general-purpose parallel programming of heterogeneous systems. OpenCL provides a uniform programming environment for software developers to write efficient, portable code for high-performance compute servers, desktop computer systems and handheld devices using a diverse mix of multi-core CPUs, GPUs, Cell-type architectures and other parallel processors such as DSPs.
Comments
The PC gaming market is currently imploding in the face of competition from consoles. For the Mac to 'explode' it would have to take on console gaming directly. That's unlikely outside of the most optimistic fanboy fantasies.
That's not true. PC gaming is not imploding. That's a myth that console manufacturers want people to believe, to make it a self fulfilling prophecy.
As for OpenCL and games, I think the benefits are somewhat overstated: the compute units are typically unused for non-3D work, but when a game is running OpenGL, they are in use, typically running vertex and fragment shaders. I'd expect to see far more benefits from OpenCL in non-gaming applications.
Welcome to the boards Brad! I agree...why would I want OpenCL in gaming? I could be naive but gaming and parallel processing sound like an odd couple. I would think the dynamic nature of a game makes it difficult to break out components and tap the GPU effectively.
This is my biggest beef with the article: the author seems to not know what OpenCL is. Can you tell me how, exactly, you expect it to help out with games? It's a general compute language designed to make non-gaming algorithms run on the GPU with a CPU fallback when the GPU is busy (as it is when GL is typically running). CL use will require work to take advantage of it, not unlike the work you might dig for when planning multi-threaded code because you have to locate and identify algorithms that can run in discrete chunks on a separate processor.
OpenCL works with any program, and that includes games. It's advantage is in parallel programming, which is where most companies, including gaming developers are having some of their biggest difficulties in leveraging the new multi core machines.
By integrating the GPU with the multiple core CPU's, each processor will be able to do the functions it does best, integrating them all.
How does DirectX compare?
I think that Stubeck was saying that the games cost 3 times more than the PC equivalent...
Upon a re-read of his post, I agree that's what he said.
I've never seen that price differential though, so it just seems as though he was talking bout the computers themselves. I'll note that on my answer to him.
It will take some time for DirectX 11 to get off the ground. Win 7 won't be released until at least mid year, possibly later. Then it will take some time after that for adoption to get to a useful level. Developers will have to play with 11 before they write to it. We may not see any serious move to it until mid to late 2010, possibly even later, depending on how the adoption of Win 7 goes.
I guess that's what WARP is for, to provide a DX10/DX10.1/DX11 compliant renderer completely in software. I believe WARP and DX11 is already out in beta in the latest DirectX SDK so developers can try it even if no DX11 hardware is available.
From the reports that Intel's Core i7 can achieve higher fps in WARP than Intel's IGPs in hardware, it makes me wonder whether Intel should be proud or not.
OpenCL has a very good shot here.
I think that Apple should do what MS has done over the years, and simply pay some big game developer to bring one or more of their major games to the Mac and find out if users are interested.
Wasn't it reported that Newell wanted Jobs to pay him $1 million to bring Half Life 2 to Mac? Steve Jobs probably didn't respond well to that.
But yeah, maybe now that Bungie is free, Apple could do something to entice them back to Mac. Or Ensemble Studios which had many of their games come to Mac and who Microsoft is letting go. I guess Apple tried this with EA too, but that seemed to have quieted down now.
I guess that's what WARP is for, to provide a DX10/DX10.1/DX11 compliant renderer completely in software. I believe WARP and DX11 is already out in beta in the latest DirectX SDK so developers can try it even if no DX11 hardware is available.
From the reports that Intel's Core i7 can achieve higher fps in WARP than Intel's IGPs in hardware, it makes me wonder whether Intel should be proud or not.
As far as I know, that's true. But developers are a conservative lot. They won't want to pour too much money into something unless they decide it's worth it.
Wasn't it reported that Newell wanted Jobs to pay him $1 million to bring Half Life 2 to Mac? Steve Jobs probably didn't respond well to that.
But yeah, maybe now that Bungie is free, Apple could do something to entice them back to Mac. Or Ensemble Studios which had many of their games come to Mac and who Microsoft is letting go. I guess Apple tried this with EA too, but that seemed to have quieted down now.
Something like that.
Apple has enough money to buy EA if they wanted to, or any other company. At least to take a stake in one. They are all small, and cheap. Apple should have their own games division like MS does, at least to get the ball rolling with a couple of major hits.
OpenCL works with any program, and that includes games. It's advantage is in parallel programming, which is where most companies, including gaming developers are having some of their biggest difficulties in leveraging the new multi core machines.
By integrating the GPU with the multiple core CPU's, each processor will be able to do the functions it does best, integrating them all.
How does DirectX compare?
DirectX and OpenGL are comparable - they are 3D graphics APIs that use the GPU. OpenCL and CUDA are comparable - they are compute APIs that use the GPU for more generalized tasks. DirectX and OpenCL are not comparable in the same way that OpenGL and CUDA are not - they do different things, albeit with the same piece of hardware.
Here's the thing: the GPU is not a magical wonderland of unlimited resources. If you're *already* using OpenGL (or DirectX) for your 3D games, OpenCL (and CUDA) are of more limited use. If you are *not* using the GPU already, then OpenCL and/or CUDA can help a great deal, not unlike making use of SSE or Altivec, albeit more generalized and useful. OpenCL's benefit will come primarily from apps that are already CPU-bound, don't rely on the GPU and could benefit from "one more core".
Brian's example pushes the case a little hard to make the point, although it certainly wasn't easy. Under Leopard, there is a new HID API that provides a lot of the same functionality as DirectInput does so the point is mostly moot now.
Is it easy to use and properly documented? One major problem I had with the old HID was that it was confusing, and the header files that the Apple docs suggest that I read lacked comments explaining the meaning or intent of the entries.
Here's the thing: the GPU is not a magical wonderland of unlimited resources. If you're *already* using OpenGL (or DirectX) for your 3D games, OpenCL (and CUDA) are of more limited use. If you are *not* using the GPU already, then OpenCL and/or CUDA can help a great deal, not unlike making use of SSE or Altivec, albeit more generalized and useful. OpenCL's benefit will come primarily from apps that are already CPU-bound, don't rely on the GPU and could benefit from "one more core".
I thought nVidia's big CUDA push in games was hardware PhysX acceleration, trying to push the idea that the GPU can handle physics faster than a CPU. Granted the GPU may already be heavily loaded, but couldn't a developer take a small fps hit say 10% to offload some physics processing onto the GPU? Since the GPU does physics faster than a CPU, you'd probably free up a proportionally larger amount of CPU cycles for other things like a more advanced AI. It might be a worthwhile tradeoff.
Is it easy to use and properly documented? One major problem I had with the old HID was that it was confusing, and the header files that the Apple docs suggest that I read lacked comments explaining the meaning or intent of the entries.
The "old" HID should never have been used directly - the 'HID Utilities" library Apple provided as sample code was a nice, easy-to-use wrapper around it which we used (and which negates a lot of Brian's 3000 lines).
The new HID is essentially the HID Utilities library cleaned up and provided in OS form. There's a technote on it here. That technote is a little bit of a headache to read, so I'd suggest checking out the sample code, particularly this app.
The usage is not unlike DirectInput on the PC: you query IOHID for the attached devices, pick out the ones you want to use, enumerate the elements on those devices and query those elements for their status. There's calls to hook all that into your run loop as an optional convenience, which makes the API appear more complicated at first glance than it really is. I suspect you'll find it's simple enough to deal with once you dig in.
I thought nVidia's big CUDA push in games was hardware PhysX acceleration, trying to push the idea that the GPU can handle physics faster than a CPU.
It isn't that the GPU is faster at it than the CPU, it's that the GPU can do it at all, so why not let it?
There are two caveats right now: one is that the G80-class hardware (the GeForce 8000 and up) are the only cards Nvidia provides that can cope with a generic compute library on the GPU. When the GPU is busy (or not capable), everything has to fall back to the CPU. The second is that fillrate-intensive games (those running extensive fragment shaders or using multisampling, for example) rob the GPU of most of its spare horsepower. There's a UT3 benchmark out there with PhysX that shows this - as the resolution goes up, the PhysX offloading goes down. The UT3 test I saw didn't make use of multisampling, which has a large impact as well.
The "old" HID should never have been used directly - the 'HID Utilities" library Apple provided as sample code was a nice, easy-to-use wrapper around it which we used (and which negates a lot of Brian's 3000 lines).
The new HID is essentially the HID Utilities library cleaned up and provided in OS form. There's a technote on it here. That technote is a little bit of a headache to read, so I'd suggest checking out the sample code, particularly this app.
The usage is not unlike DirectInput on the PC: you query IOHID for the attached devices, pick out the ones you want to use, enumerate the elements on those devices and query those elements for their status. There's calls to hook all that into your run loop as an optional convenience, which makes the API appear more complicated at first glance than it really is. I suspect you'll find it's simple enough to deal with once you dig in.
I think maybe the book in question might have predated the publication of HID Utilities.
HID Utilities always looked like a mess to me. I'm not seeing much better by looking at the tech note or the code to this HID Calibrator either. main.c is 872 lines.
I think maybe the book in question might have predated the publication of HID Utilities.
HID Utilities have been around since at least 2004, the book came after.
HID Utilities always looked like a mess to me. I'm not seeing much better by looking at the tech note or the code to this HID Calibrator either. main.c is 872 lines.
Don't take the "Wil Shipley" line-counting approach and conflate comments, white-space and robust error checking in with raw functionality. The API itself is fairly concise: the example code (in a departure from a lot of samples) attempts to do everything and account for every error. In practice, you'll have maybe a few dozen lines, particularly if you use Cocoa for the dictionaries instead of the CoreFoundation APIs.
DirectX and OpenGL are comparable - they are 3D graphics APIs that use the GPU. OpenCL and CUDA are comparable - they are compute APIs that use the GPU for more generalized tasks. DirectX and OpenCL are not comparable in the same way that OpenGL and CUDA are not - they do different things, albeit with the same piece of hardware.
Here's the thing: the GPU is not a magical wonderland of unlimited resources. If you're *already* using OpenGL (or DirectX) for your 3D games, OpenCL (and CUDA) are of more limited use. If you are *not* using the GPU already, then OpenCL and/or CUDA can help a great deal, not unlike making use of SSE or Altivec, albeit more generalized and useful. OpenCL's benefit will come primarily from apps that are already CPU-bound, don't rely on the GPU and could benefit from "one more core".
OpenCL is quite a bit more than that.
DirectX has long been one of Microsoft's crown jewels. By dragging their feet on OpenGL support in Windows - for a long time "OpenGL" was synonymous with "broken or laggy at best" for gamers - MS won a significant position of leverage for itself in graphics. Simply put: the nascent 3D accelerator market of 3DFX, Matrox, ATI and Nvidia formed in DirectX's image. Why? The usual Windows parlay trick courtesy of Microsoft.
If you wanted to sell hardware, you had to support DirectX. If you wanted to win rave reviews, you had to optimize for it like hell.
Apple were wise to pick OpenGL. Apple needed hardware acceleration for Quartz and essentially there was no alternative by then. Console makers also helped OpenGL's relevance by using it when they went 3D in the late 90's. Microsoft responded with the Xbox for obvious competitive reasons as the artlcle describes.
But the GPU industry is still DirectX at its core. Look at the ads or reviews of any card and see how much is made of which DirectX technologies are supported, and how fast. This is what lies at the heart of the game industry's continuing disregard for the Mac (Steam anyone?) and the horrible lateness of Mac compatible drivers.
If OpenCL and OpenGL do unite and take on DirectX's position of age old dominance, this will be very interesting indeed.
I'm not even a gamers anymore, but I know that the consequences of this could be vast.
(Typed on iPod. Excuse the typos.)
Microsoft is going to need a major game change if they wish to prevent OpenGL/CL from taking the cake.
1. Not only is Apple advancing more rapidly than any other computer vendor but they are especially popular with media & younger crowds. Anyone who knows marketing knows these are the groups you want on your side if you want to take over a market, especially kids.
2. XBox is a flop that has been kept barely alive by the Halo effect. PS3 blows the pants off XBox in performance & the Wii is outselling both consoles.
3. People don't buy computers for gaming anymore so the market for who cares about advanced pixel shading or other key Direct3D features is rapidly shrinking & becoming niche. All the money for gaming is shifting towards portables & this is rapidly pushing game developers into the world of OpenGL.
4. Visual Studio has long been in a league of it's own, but the developer tools coming together in XCode is rapidly advancing & becoming more & more comparable to Visual Studio.
5. Developers preference can help guide a product but ultimately it is money. The market has already begun the shift & what will happen is the gaming industry will slowly follow at first & then at some point the developers will get a good kick in the rear (either by company heads or by drop off in sale of their product). You will see a sudden & rapid burst in development towards OpenGL.
Microsoft knows all this & this is why they jumped into consoles & why Halo is probably not the last title that they buy & then lock down to their systems. They have never known how to compete on the technology level, but they have always been good at locking in vendors & manufacturers & then squeezing out the competition. Those tactics don't work anymore in todays society, especially since many younger technologists are tired of it & don't want anything to do with Microsoft.
The only thing that could stop this train now would be for Apple to make some horrible blunder that would completely shut them down, & I just don't see that happening. They've long ago passed the point of small company that could disappear overnight.
As I see it, OpenCL is not going to help OpenGL one bit. If anything, there is the risk of it meaning more overhead. OpenCL's real promise is not in gaming but everywhere else where the GPU and other resources are at idle. Also, OpenCL is not going to magically turn apps into multithreading beasts, the same way CUDA doesn't. "Human decision required" here.
OpenGL needs to be a true DirectX counterpart for game developers to decide they can target it and do multiplatform programming. These hopes were dashed with that last iteration after a year of promises.
So I don't think Microsoft has too much to worry about.
OpenCL is quite a bit more than that.
I worked on Apple's OpenGL team for a year alongside 4 of the people simultaneously working on OpenCL. A lot of the GL team's work was enabling CL to gain better access to the GPU. Suppose for the moment that I failed to understand a single thing about it and enlighten me.
2. XBox is a flop that has been kept barely alive by the Halo effect. PS3 blows the pants off XBox in performance & the Wii is outselling both consoles.
In terms of market share and performance, it's actually the Xbox 360 that is pulling ahead of the PS3 this generation with sales nearly 2:1 over the PS3 using the November 2008 NPD numbers. In raw numbers, the 360 outsells the PS3 and PS2 combined in the US. The Wii is, as you note, miles above.
3. People don't buy computers for gaming anymore so the market for who cares about advanced pixel shading or other key Direct3D features is rapidly shrinking & becoming niche. All the money for gaming is shifting towards portables & this is rapidly pushing game developers into the world of OpenGL.
Agreed about not buying computers for gaming. That said, the main API on the main gaming platform - the Xbox 360 - is DirectX. The PS3 has a stripped down OpenGL ES library, but for best performance developers use Sony's proprietary API, not OpenGL.
Microsoft ... have never known how to compete on the technology level, but they have always been good at locking in vendors & manufacturers & then squeezing out the competition.
Microsoft has indeed competed on the technology level with DirectX, and done it well. As for console exclusives, in no way is Microsoft alone here: Sony has also snapped up or purchased rights from developers for Playstation exclusives. Naughty Dog (Crash Bandicoot, Jak/Daxter and Uncharted) comes immediately to mind.
I worked on Apple's OpenGL team for a year alongside 4 of the people simultaneously working on OpenCL. A lot of the GL team's work was enabling CL to gain better access to the GPU. Suppose for the moment that I failed to understand a single thing about it and enlighten me.
Oh, I think you know what it is, but you are just discussing it at its simplest level here. I'm pointing out that it's much more than that.
Just a simple description from the Khronos Group will suffice to show what my statement means overall:
OpenCL 1.0 at a glance
OpenCL (Open Computing Language) is the first open, royalty-free standard for general-purpose parallel programming of heterogeneous systems. OpenCL provides a uniform programming environment for software developers to write efficient, portable code for high-performance compute servers, desktop computer systems and handheld devices using a diverse mix of multi-core CPUs, GPUs, Cell-type architectures and other parallel processors such as DSPs.