I'm nearing the end of a two week break from work and as I spent the first week and a half back in my home town seeing friends I figured that it would be a good time to do some programming stuff now that I'm back.

I've been intrested in OpenCL for some time so I decided that today would be a good time to get the AMD APP SDK installed and see about doing some work with it. However as my intrests tend to be graphical in nature I need something to display the output with... it was about here that I should have turned back but, like a fool, I decided to carry on regardless.

Now, after the Longs Peak/OpenGL3.0 snafu a few years back I've been using DX exclusively in my own graphical efforts, the problem is while AMD expose an extension to interop with D3D10 no extension is forthcoming for D3D11 it seems, which means that unless I want to use D3D10 (not really...) it looks like I'll have to use OpenGL to do any visualisation.

On the face of it that doesn't seem too bad, there is very tight interop between CL1.1 and GL so they look like the natural pairing... or would if not for OpenGL.

When I left OpenGL a few years back things were pretty simple; you construct a 'dummy' context to get at certain extensions and then use wgl functions to get at an OpenGL2.x context with some extended functionality. OK, not the easiest thing in the world but it was pretty straight forward; in fact you didn't even need to do that because you could just request a context and get whatever the hardware supported.

So, today I fire up OpenGL Extension Viewer to get a look at the state of the OpenGL driver from AMD. When it finishes doing it's "thing" I'm presented with a window and at the top a drop down box with "Forward Context 4.0" in it and a report that my card supports OpenGL4.0 with the only extension missing from 4.1 being a debug one. Extension numbers are also given in another window with the key ones being 17 AMD, 3 AMDX, 93 ARB and 63 EXT extensions.

I then decided to take a look at the content of the drop down box and found it populated with;

• ATI Radeon HD5800 Series
• ATI Radeon HD5800 Series (Forward Context 3.0)
• ATI Radeon HD5800 Series (Forward Context 3.2)
• ATI Radeon HD5800 Series (Forward Context 3.3)
• ATI Radeon HD5800 Series (Forward Context 4.0)

So, for the hell of it I clicked on the top one, just to see whats going on... and what do I discover; that one is a full 4.1 context with the missing 4.1 extension supported! It also has more extensions supporting 71 EXT and 97 ARB extensions.

The significant difference between the first entry and the next 4 is that the first version is "4.1.10906 Compatibility Profile Context" and the latter 4 are all " Core Profile Forward-Compatible Context"

After some hunting about it would seem that the one which reports 4.1 is the 'compatibilty' context aka everything as you were, where as the others are 'core profile' only aka all the old stuff removed (or not... see below). The fact that it was that hard to find out what the hell was going on is never a good sign, part of that could well be layed at AMD's feet for poor naming and also raises the question of why they don't have a 4.1 'core' as well considering they have the missing function supported somewhere?

Also, don't get me started on the 'ARB_compatiblity' extension (which is present in the 'core' profiles) which effectively undoes all the 'core' stuff and just makes the whole point of profiles a great big bundle of stupid.

At least on this point MS got it right with DX11; drop everything and don't leave any room for people to use the 'old' methods.

Of course, it doesn't stop there, the context creation for versions 3.0 of OpenGL and above read like a bad joke and somewhat hint that things got rushed and have created another mess. The short version; OpenGL3.0 created a new way to create contexts with profiles, it was then realised that the 'ARB_compatibility' extension caused problems as users couldn't ask NOT to have it, so they added a 'compatibility' profile in addition to 3.0's core and only requiring the implimention of 'core'. Of course as we've discovered the 'core' profiles provided by AMD (and I dare say NV too) give you the 'ARB_compatibility' extension anyway so nothing has changed!

Arrrggh...

So, now you can ask for a compatibility profile if you want, but you might as well ask for 'core' as that the extension anyway and I dare say by now enough people have coded against it that removing the extension from future GL is never going to happen.

But, that shouldn't really bother someone writing GL code; it's just an added problem for newbies and IHV to deal with (which I find amusing as I was sure this was meant to make things easier for both parties...), everyone else can just write to the GL4.x spec and be done with it.

So, as we are in Window's world this requires some extension work to get at the new stuff and BAM! we run right into another piece of OpenGL 'ugh'ness; go grab an extension wrangler, include the header into a project and wait for whatever intellisense system you use to catch up... now, you tell me via intellisense alone which are 'core' functions and thus 'fast path'... oh, that's right, there is no 'pure' header.

Call me lazy if you like but a lot of my code time is spent using intellisense via VAX so speed up my coding, however when your headers expose every type, enum, function and define ever created for OpenGL.. well, that does not make life easier for me nor the hypothetical newbie mentioned earlier.

Now, if you want to make your own headers it should be a "simple" matter of passing the .spec files on the OpenGL webside; the problem is there is no sane way of extracting GL4.x+ and compatible extension in any sane manner. Really what is required here is a 'clean' set of .spec files which deals only with GL4.x+; heck in an ideal world one for each version of GL would be useful that way people could generate their own headers based on their target GL version and be done with it. No cruft, no non-core functionality, just a striped down OpenGL header and supporting extensions.

Not that we have this, no what seems to exist right now are zombie functions which while apprently 'gone' are back from the dead in all profiles, changing methods of context creation which depends on certain extensions being present and header files bloated with the history of OpenGL.

So annoyingly, for me at least, because of the continuing uselessness of the ARB and supporting IHVs and ISVs with regards to their treatment of OpenGL OpenCL remains an intresting but closed book for me. Which is a shame because I see some real potential in OpenCL, AMD's Fusion processors and extensions such as GL_AMD_multi_draw_indirect.

It's sad to see how little this has changed in the last 3 years...