Results 1 to 13 of 13

Thread: ClanLib and OpenCL 1.1

  1. #1
    ClanLib Developer
    Join Date
    May 2007
    Posts
    1,766

    Default ClanLib and OpenCL 1.1

    As most of you are probably aware, there is a namespace confliction between OpenCL and ClanLib.

    i.e. The both use the "cl_" prefix

    To use OpenCL includes, we require:
    Code:
    #undef clFlush
    #undef clFinish
    #include <CL/opencl.h>
    And this breaking change:

    Modify API/Core/IOData/datatypes.h ...
    cl_int8 --> cl_int8bit
    cl_int16 --> cl_int16bit
    etc

    OpenCL defines it as:
    cl_uint CL_ALIGNED(32) s[8];

    Shall we change change ClanLib to use cl_int8bit etc? or otherwise?

    Committed to ClanLib 2.3 SVN, Examples/OpenCL/Basic "Added a simple OpenCL context creating example"
    Last edited by rombust; 07-18-2011 at 02:31 PM.

  2. #2
    ClanLib Developer
    Join Date
    May 2007
    Posts
    1,766

    Default

    The problems run much deeper than that

    For example:

    in OpenCL cl.h:

    Code:
    #define CL_RGB                                      0x10B4
    #define CL_RGBA                                     0x10B5
    #define CL_BGRA                                     0x10B6
    #define CL_ARGB                                     0x10B7
    #define CL_INTENSITY                                0x10B8
    #define CL_LUMINANCE                                0x10B9
    ClanLib contains:

    Code:
    	CL_RGB                            = 0x1907,
    	CL_RGBA                           = 0x1908,
    	CL_BGRA                           = 0x80E1,
    I think we have a couple of solutions

    1) Drop the OpenGL CL_, cl prefixes and use the GL_ and gl instead
    2) Use the clanGL1 technique of using the "CL1_ / cl1" prefix, and use "CL2_ / cl2" prefixes.
    3) Rename ClanLib to LibClan, thus "CL_, cl" will become "LC_, lc"
    4) Lobby khronos.org
    5) Rethink ClanLib objectives

    Options 1 and 2 still require cl_int8 etc being renamed, as it is a part of clanCore.
    Option 3 could confuse with unix environment variables.
    Option 4 is pointless, the companies in the working group have slightly more money than the ClanLib fund.

    I feel Option 1 is the best solution. But I do not know of the implications.
    The second best option is option 2.

    Any ideas?

  3. #3
    Lesser Knight
    Join Date
    Jan 2011
    Posts
    32

    Default

    1) Drop the OpenGL CL_, cl prefixes and use the GL_ and gl instead
    2) Use the clanGL1 technique of using the "CL1_ / cl1" prefix, and use "CL2_ / cl2" prefixes.
    3) Rename ClanLib to LibClan, thus "CL_, cl" will become "LC_, lc"
    Are you talking about changing every CL_ prefix over ClanLib sources or only prefixes of global defines and constants?

  4. #4
    ClanLib Developer
    Join Date
    May 2007
    Posts
    1,766

    Default

    Point 1 and 2, would only be:
    API/GL/opengl_defines.h (all this file)
    API/GL/opengl_wrap.h (#define clCullFace CL_OpenGL::functions->cullFace etc)

    Point 3 would be the entire ClanLib. I dislike that idea. I would have to change lots of code that uses ClanLib. Also users that do not use OpenCL would not be very happy doing lots of rework with no gain.

  5. #5
    ClanLib Developer
    Join Date
    May 2007
    Posts
    1,766

    Default

    SVN Commit:
    Code:
    BREAKING CHANGE:
    Renamed cl_int8-->cl_char, cl_int16-->cl_short, cl_int32->cl_int, cl_int64->cl_long.
    
    Applied OpenCL's cl_platform.h to ClanCore, as it contains useful standard datatypes for aligned variables. Also it prevents OpenCL and ClanLib namespace clashes.
    
    Note: cl_int8 now represents 8 cl_int's with 32 byte alignment.
    
    See forum for more information
    I feel that everyone will agree, this is a correct commit.

    Athough it is a breaking change, it is minor. Not a single example required modification.

  6. #6
    ClanLib Developer
    Join Date
    May 2007
    Posts
    1,766

    Default

    svn commit:

    Code:
    BREAKING CHANGE:
    The clanGL and the clanGL1 target now use the GL_ prefix for standard OpenGL definitions.
    The clanGL and the clanGL1 target standard OpenGL datatypes now use the GL prefix. 
        For example, CLint was changed to GLint
    I feel that everyone will agree, this is a correct commit.

    OpenGL users expect to be able to use GL_RGBA.

    This will avoid most namespace clashes with OpenCL.

  7. #7
    Lesser Knight
    Join Date
    Jan 2011
    Posts
    32

    Default

    By the way, why doesn't ClanLib have any namespace wrapper from the very beginning of it's development, like std or boost?

  8. #8
    ClanLib Developer
    Join Date
    May 2007
    Posts
    1,766

    Default

    SVN Commit:

    Code:
    BREAKING CHANGE:
    The clanGL target OpenGL calls now use the standard gl prefix (from the cl prefix).
     For example, clBindBuffer is now glBindBuffer
    (Removed the opengl_gl.h convenience wrapper, it is not longer required)
    That has fixed the namespace conflict. And it should be more natural to users moving to ClanLib who already have an OpenGL background

  9. #9
    ClanLib Developer
    Join Date
    May 2007
    Posts
    1,766

    Default

    Quote Originally Posted by user View Post
    By the way, why doesn't ClanLib have any namespace wrapper from the very beginning of it's development, like std or boost?
    This has been discussed many times on ClanLib's IRC ( #clanlib at irc.freenode.net )

    I was not in the discussion, but for what I remember, the reasons are:
    ("we" == ClanLib developers who modify the library.)
    1) We do not like having to type ClanLib::DoThis()
    2) We do not like having to put "using namespace ClanLib" everywhere
    3) We know everything that it prefixed with CL_ is ClanLib
    4) "using namespace ClanLib" is the same as having the code in the global namespace.

    For reference, in the CODING_STYLE:

    Code:
    7. STL and variable names.
    
    Do NOT use the "using namespace std;" command. Not in API header or in source
    files. You may be the world champion in STL, but for us other mortals its NICE
    to be able to read what is STL and whats not.

  10. #10
    ClanLib Developer
    Join Date
    Sep 2006
    Location
    Denmark
    Posts
    547

    Default

    To be honest I am not what I prefer. It really sucks Khronos chose to use the CL prefix and I too would prefer to keep the prefix in clanlib. And yes lobbying megacorps is a waste of time in this regard.

    The real question is whether we have any choice long term. Eventually we might start to use OpenCL ourselves and since our project is closely related to what they do I suspect we will continue to run into name clashes. If we must change the prefix I would probably prefer something like clan::PixelBuffer, clan:isplayWindow and so on. Using 'cl' as our namespace will probably just cause similar trouble in the future.

    The good news is that a simple search/replace for CL_ with clan:: will probably work fine for 95% of all projects. The bad news imo is that such a change would require a new major release - and it would make it more difficult to apply patches backwards in the tree.

    I am not sure how you concluded that using the standard headers for OpenGL would work for projects wanting to use direct OpenGL calls. Isn't the standard headers in Windows still OpenGL 1.6 or something? Similar types of problems for the other platforms if I recall correctly.

  11. #11
    ClanLib Developer
    Join Date
    May 2007
    Posts
    1,766

    Default

    I vote to stick with CL_xxxx for now. Maybe in a couple of years time we can change, but at the moment, there is no requirement. OpenCL and ClanLib, at the current svn works without any problem.

    Quote Originally Posted by Magnus Norddahl View Post
    I am not sure how you concluded that using the standard headers for OpenGL would work for projects wanting to use direct OpenGL calls. Isn't the standard headers in Windows still OpenGL 1.6 or something? Similar types of problems for the other platforms if I recall correctly.
    By using some safe tricks...

    Sources/API/GL/opengl_defines.h

    Added:
    #include <GL/gl.h>
    (on WIN32 this includes up to OpenGL 1.1)
    (on Linux this includes up to OpenGL 3.something)

    Added for each GL definition block, up to and including OpenGL 4.2

    Code:
    enum CL_DisplayDefines
    {
    #ifndef GL_DEPTH_BUFFER_BIT
    	GL_DEPTH_BUFFER_BIT               = 0x00000100,
    	GL_STENCIL_BUFFER_BIT             = 0x00000400,
    	GL_COLOR_BUFFER_BIT               = 0x00004000,
    #endif
    #ifndef GL_FALSE
    	GL_FALSE                          = 0,
    	GL_TRUE                           = 1,
    #endif
    	...
    }
    Sources/API/GL/opengl_wrap.h

    Renamed clCullFace to glCullFace etc. Since #define's override function definitions, this works.

    Code:
    #define glCullFace CL_OpenGL::functions->cullFace
    #define glFrontFace CL_OpenGL::functions->frontFace
    #define glHint CL_OpenGL::functions->hint

    Sources/GL/opengl_cpp

    Since WIN32 static links certain early OpenGL calls, we have to undef the gl function to obtain the function address.

    (Linux does not static link any function)

    Code:
    #undef glBindTexture
    if (!functions->bindTexture) functions->bindTexture = (CL_GLFunctions::ptr_glBindTexture) &glBindTexture;
    Sources/API/Core/IOData/datatypes.h

    File removed, replaced with...

    Sources/API/Core/System/cl_platform.h

    Since OpenCL meaning of cl_int8 is different to ours, I changed ours to match theirs.

    Note: cl_int8 now represents 8 cl_int's with 32 byte alignment.
    Renamed cl_int8-->cl_char, cl_int16-->cl_short, cl_int32->cl_int, cl_int64->cl_long

    I do have to say that I am not sure why khronos named them that way, to me it's counter intuitive.

    Examples

    It was very surprising how little I had to change.

    Only a couple of lines of Dicewar
    and the GL_ prefixes on Examples/Display_GL/CustomGL (which uses clanGL1)

    Comment

    We could have simply copied GL.h from http://www.opengl.org/registry/ into Sources/API/GL/opengl_defines.h ,but that may have caused problems for:
    #include <OpenGLES/ES2/gl.h>

    At the moment we enum the GL defines. Maybe it's better to #define them for consistancy with the GL headers. I do not know, but it should not matter. (Unless code performs a #ifdef on them)

  12. #12
    ClanLib Developer
    Join Date
    May 2007
    Posts
    1,766

    Default

    Quote Originally Posted by Magnus Norddahl View Post
    ...since our project is closely related to what they do ....
    I disagree with that.

    OpenCL is "Open Computing Language".

    It's OpenGL's equivalent to Microsoft's DirectCompute

    You use it to run 'C' on the GPU.

    The OpenCL interface controls memory objects, program object, kernal objects and event objects.

    The ClanLib's Example/OpenCL/Basic example code is:

    Code:
    	static const char source_code[] = 
    		""
    		"__kernel void simple_test(__global float *vals)"
    		"{"
    		"	const uint i = get_global_id(0);"
    		""
    		"vals[i] = 1.23;"
    		"}"
    		"";
    When called it uses the GPU to fill 32 floats with 1.23 - useful stuff

  13. #13
    ClanLib Developer
    Join Date
    Sep 2006
    Location
    Denmark
    Posts
    547

    Default

    Yes, but since OpenCL and OpenGL are "best buddies" and can share data between them I would not find it unlkely we would want to have some classes that represents some of the concepts in OpenCL to make it integrate better with ClanLib. Anyhow as you suggested lets just keep the CL prefix for now and only change if it becomes a major problem down the line.

Bookmarks

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •