OpenGL 4.4 and OpenCL 2.0 Specs Released 66
Via Ars comes news that the OpenGL 4.4 and OpenCL 2.0 were released yesterday. OpenGL 4.4 features a few new extensions, perhaps most importantly a few to ease porting applications from Direct3D. New bindless shaders have access to the entire virtual address space of the card, and new sparse textures allow streaming tiles of textures too large for the graphics card memory. Finally, the ARB has announced the first set of conformance tests since OpenGL 2.0, so going forward anything calling itself OpenGL must pass certification. The OpenCL 2.0 spec is still provisional, but now features a memory model that is a subset of C11, allowing sharing of complex data between the host and GPU and avoiding the overhead of copying data to and from the GPU (which can often make using OpenCL a losing proposition). There is also a new spec for an intermediate language: "'SPIR' stands for Standard Portable Intermediate Representation and is a portable non-source representation for OpenCL 1.2 device programs. It enables application developers to avoid shipping kernel source and to manage the proliferation of devices and drivers from multiple vendors. OpenCL SPIR will enable consumption of code from third party compiler front-ends for alternative languages, such as C++, and is based on LLVM 3.2. Khronos has contributed open source patches for Clang 3.2 to enable SPIR code generation." For full details see Khronos's OpenGL 4.4 announcement, and their OpenCL 2.0 announcement.
Update: 07/23 20:17 GMT by U L : edxwelch notes that Anandtech published notes and slides from the SIGGRAPH announcement.
Better Article (Score:5, Informative)
There's a better article here:
http://www.anandtech.com/show/7161/khronos-siggraph-2013-opengl-44-opencl-20-opencl-12-spir-announced [anandtech.com]
Re: (Score:1)
The author of that Anandtech story wrote the following in response to a question about the feature gap between DX11.2 and OpenGL 4.4;
At a high level the two are roughly equivalent. With compute shaders in OpenGL 4.3 there is no longer a significant feature gap for reimplmenting D3D11 in OpenGL. I didn't cover this in the article since it's getting into the real minutia, but 4.4 further improves on that in part by adding a new vertex packing format (GL_ARB_vertex_type_10f_11f_11f_rev) that is equivalent to one that is in D3D. Buffer storage also replicates something D3D does.
Glad to see OpenGL at parity, or close to it, with Microsoft's 3D stack. One wonders if that is due to the huge growth in OpenGL utilization by mobile platforms, even though those often use only embedded OpenGL profiles.
Re: (Score:2)
Glad to see OpenGL at parity, or close to it, with Microsoft's 3D stack. One wonders if that is due to the huge growth in OpenGL utilization by mobile platforms, even though those often use only embedded OpenGL profiles.
Well, that depends on what level you're talking about. At the bottom level is of course the hardware, which will have the exact same features so on the top level declaring an API that does the same is not that hard. The hard part is everything in the middle, which is why OpenGL is now up to version 4.4 while Mesa (the open source implementation) still only supports version 3.1 from March 2009, so that "feature parity" OpenGL version is only available using proprietary blobs. What the packing formats and suc
Re: (Score:2)
Re: (Score:1)
I've been a pro-DX11 guy, but GO OpenGL. Nice. I hope some new Linux Steam game comes out to make use of this stuff soon(tm).
I've been a pro OpenGL guy forever but only because I found it easier to play with and more open but we all knew DirectX was massively better at this stuff for years. I've spent the last 3 months relearning everything i know to go from 1.x to 3.3 to 4.0 code. It actually is very fun to throw weeks to years worth of work away as l realize i'm years behind and of course it is extremely powerful on all the levels DirectX is now with respect to talking to a GPU. It still is sort of like banging your head on
Re: (Score:3)
They're essentially at parity because they're matching, for the most part, the features of the underlying hardware. It's a weird give-and-take - Microsoft likes to dictate features, but their DirectX team is smart enough (now) to dictate features that at least one of the GPU companies is already implementing - essentially, they ask Nvidia what they're adding, ask AMD what they're adding, then add both of them to Direct3D and tell them both to implement it (and since they're both watching each other's moves
Re: (Score:2, Insightful)
If you can't understand C, you have no business touching the GPU or even calling yourself a programmer.
Re:OpenCL (Score:4, Insightful)
Nothing wrong with C, but you don't really need to limit your self to it just because the code is running on the GPU. Have a look at C++ AMP for example.
Re: (Score:1)
It's true that it's not C, but the way it's designed make it look like C.
Re: (Score:2)
Of course I understand C. I just DONT_WANT_TO_DEAL_WITH_INT_CONSTANTS, when modern type safe enums exist, and other pointless annoyances that are conventional in C.
Re: (Score:2)
There's nothing magical about type safety, you know, except for the confidence that the setting your assigning relates at all the value you're using.
Re: (Score:2)
Constants aren't type safe.
Re: (Score:2)
They can be in C++11: strongly typed enums.
Re: (Score:2)
Sorry, what I first meant was that #defined macros in C are not at all typesafe (which is the claim the GGG[G*]P was ignoring), but also that not all "ints" should be considered compatible. While it may be syntactically correct and safe to add "int milesPerGallon" and "int averageAgeOfRockStars", semantically it's nonsense. Defining these as distinct types of "miles" and "years" would enable the type system to save a developer from making that mistake.
Re: (Score:2)
Re: (Score:2)
You can completely circumvent this problem by simply writing correct code.
Well, I'm sure super human awesome coders like yourself can. The rest of us fallible mortals enjoy having tools to automatically catch mistakes without adding any overhead or verbosity. I'll bet you "simply write correct code" so there's no need to test before pushing it to the production server, right?
Re: (Score:2)
Re: (Score:2)
Exactly *how much* free time do you have on your hands?
I have literally no idea what you are talking about. You were decrying type safety because you could "simply write correct code".
If that's possible, then there is no reason to ever test anything because it will "simply be correct".
And yeah, I do test stuff before pushing it to production servers, though no, I do not use C these days.
Re: (Score:2)
Anyway, optimal memory access patterns for GPUs are completely different, so you'd better change your loops.
Re: (Score:2)
OpenCL requires a lot of boilerplate code to initialize resources and whatever. But the code is a lot more machine portable than CUDA.
Re:OpenCL (Score:4, Insightful)
Except for the fact that CUDA only works on nvidia devices, and OpenCL works on everything...
Re: (Score:1)
And who cares what is best if you can't use it?
Re: (Score:2)
Don't care. CUDA is better.
Define "better".
Re: (Score:3)
In my experience CUDA is not any faster than OpenCL. Frameworks don't solve the problem properly. There are a lot of debugging tools for OpenCL my guess is you did not look hard enough. You can run OpenCL programs without installing all the cruft required to do CUDA development since the driver will compile and run code by itself. This means a lot of people don't bother looking for tools but they are out there.
Re: (Score:2)
The gpuocelot project [google.com] has been able to run CUDA in non-NVIDIA hardware for some time now, including x86 CPUs and AMD GPUs.
Too bad the CUDA compiler often segfaults on ordinary C++ libraries even when they are host-only (in which case nvcc is supposed to just forward it to GCC). Hopefully the LLVM-based compiler for OpenCL 2.0 won't be as buggy.
Re:OpenCL (Score:4, Informative)
There are also several mobile devices (smartphones, tablets) running ARM which have OpenCL support and zero CUDA support. Not to mention that it is also a web standard namely WebCL.
Re: (Score:2)
Why can I run a kernel for CUDA in 3 lines of code but I need 2000 lines for running an opencl one?
You need to use clut, just like you would use glut with OpenGL.
Re: (Score:2)
If you can't understand C, you have no business ... even calling yourself a programmer.
So I guess the hundreds of other programming languages don't count?
It's like calling yourself an international businessman and not knowing English. Yes, those hundreds of other programming languages actually don't count in this case.
Re: (Score:3)
No side effects is *key* in being able to parallelize things. Because you can trust that the same input will *always* give the exact same output.
Actually, that's mostly irrelevant. That could be useful for memoization, but it's not a sufficient condition for parallelization - if you take it to the logical conclusion, you're asking for nothing more than a computer that is reliable, which is an assumption you do for most computer programs, so you're asking for a very weak property. The key to parallel computing is the associativity of individual operations. Other properties that are of lesser help are commutativity, idempotency (basically the thing yo
Re: (Score:3)
Well, let's look at the use cases for OpenCL right now:
* Scientific computing, at levels from workstations to supercomputers
* Games that need to offload stuff too parallel for the CPU to handle, or for code that needs to run on the GPU as the output will be used by other GPU code (streaming texture decompression is a common task).
* Video transcoders, encoders and decoders
* Bitcoin miners (obligatory Bitcoin reference: check!)
All of those are fields where performance is a very high priority - in some cases,
Re: (Score:2)
it's tough because massively multi-threaded programming is intrinsically difficult.
Only in weak programming paradigms.
Re: (Score:2)
the important question (Score:1)
Re: (Score:1)
If you use an NVidia card, yesterday, it seems: https://developer.nvidia.com/opengl-driver [nvidia.com]
On the other hand, AMD only publised catalyst drivers for OpenGL 4.3 today.
Conformance tests developed along with spec (Score:2)
NVidia not that important. (Score:3, Interesting)
NVidia, who own the 50% of the GPU market
Not even close NVidia has 18% of the GPU market with Intel at 61.8% and AMD at 20.2%. NVidia is less prolific than you think. Basically 80% of the market can implement it without Nvidia. I don't think they want to do that.
Citations needed! (Score:1)
NVidia, who own the 50% of the GPU market...
Just where did you get that data point!? Most everything I've seen retail wise has Intel graphics inside while few come with NVidia's stuff, and those that do come at a premium price.