Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Replace GLEW with glbinding #89

Merged
merged 23 commits into from
Aug 17, 2016
Merged

Conversation

9prady9
Copy link
Member

@9prady9 9prady9 commented May 9, 2016

Fixes #85
Fixes #101

Also fixes, virtual trackball rotation based interaction for 3d chart objects.

All examples also use glbinding from now, but OpenCL examples
are not functional yet due incompatibility between gl.h header
included by opencl headers and glbinding header
@shehzan10
Copy link
Member

@9prady9 Can you detail the OpenCL issue? And perhaps file a bug request with glbinding?

@shehzan10
Copy link
Member

@arrayfire/core-devel I support merging this PR. However, I understand that there are concerns, among other things, about

  • CMake minimum version incremented to 3.0 (this will need an increment on ArrayFire too)
  • glBinding not being as widely available as GLEW.

The later of those is not such a big issue as we can make glBinding is an external build. So it will be built from source. We could add an option to use system one as well.

Upgrading CMake may be an issue. This is the one that we should take with caution.

-DCMAKE_C_FLAGS:STRING=${CFLAGS}
-DCMAKE_BUILD_TYPE:STRING=${CMAKE_BUILD_TYPE}
-DCMAKE_INSTALL_PREFIX:STRING=${prefix}
-DBUILD_SHARED_LIBS:BOOL=ON
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We want this to be static. Is there any reason why it's shared?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nothing of concern i guess, start started off like that.

@pavanky
Copy link
Member

pavanky commented May 9, 2016

I don't think we should use a library that's not widely used if there isn't a strong enough reason to do it.

@shehzan10
Copy link
Member

Among others, are the following advantages:

  • It is type safe (GLEW uses enums everywhere and it can be messed around with)
  • C++11, templates, lambdas etc
  • Availability:
  • In my opinion, it has better multi-context and multi threading support

I don't know the amount of work that would be required, but I would be fine supporting both GLEW and glBinding similar to how we support GLFW and SDL. GLEW and glbinding are easily interchangeable as GLEW uses glFunction and glbinding uses gl::Function.

ExternalProject_Add(
glb-ext
GIT_REPOSITORY https://github.com/cginternals/glbinding.git
GIT_TAG v2.0.0
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

They have v2.0.1 out as of April 6.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have seen v2.0.1 and tried it out, i faced some issues while compiling against that version. This commit from v2.0.1 is conflicting with standard gl.h header. I haven't figured how to resolve that elegantly yet.

@9prady9
Copy link
Member Author

9prady9 commented May 9, 2016

@arrayfire/core-devel I think it is good if we just pick one loader. To support both would be lot of pain that is not the worth spending time on.

We have two options:

  • Stick with GLEW in hope that they will release 2.0 soon (there is no known timeline on this as per their github page) that fixes the problems with GLEW (cannot use in conjunction with Qt - thats one problem apart from being void of other things @shehzan10 mentioned above).
  • Use glbinding

@9prady9
Copy link
Member Author

9prady9 commented May 9, 2016

@shehzan10 Regarding OpenCL, i didn't get the time to resolve that one before i pushed the branch. Will do soon. It is probably something simple. Will let you know once i figure out whats the issue.

UPDATED:

In file included from /home/pradeep/gitroot/forge/examples/opencl/fractal.cpp:15:0:
/home/pradeep/gitroot/forge/examples/opencl/cl.hpp: In constructorcl::ImageGL::ImageGL(const cl::Context&, cl_mem_flags, gl::GLenum, gl::GLint, gl::GLuint, cl_int*)’:
/home/pradeep/gitroot/forge/examples/opencl/cl.hpp:4241:19: error: cannot convertgl::GLenumtocl_GLenum {aka unsigned int}’ for argument3to_cl_mem* clCreateFromGLTexture(cl_context, cl_mem_flags, cl_GLenum, cl_GLint, cl_GLuint, cl_int*)’
             &error);

The above type conversion is the issue, i am trying to figure out if we can by pass this problem on our end. It may not be possible i think. Any thoughts ?

@pavanky
Copy link
Member

pavanky commented May 9, 2016

Hmm might be a good way to get glbinding into the official repos as well if forge depends on it.

@9prady9
Copy link
Member Author

9prady9 commented May 18, 2016

@arrayfire/core-devel
I don't think we can use cl.hpp header with glbinding, i have raised an issue on their github page asking for work around. One way for us would be to rewrite our OpenCL examples to use OpenCL-C API and convert the glbinding's enum gl::GL* class values to cl_GL* types ourselves.

Any thoughts ?

@9prady9 9prady9 added this to the 1.0.0 milestone Jun 6, 2016
Added the following utility functions to help with
copying data from host side to rendering buffers

* fg_update_vertex_buffer(cpp version is updateVertexBuffer)
* fg_update_pixel_buffer(cpp version is updatePixelBuffer)
@9prady9 9prady9 changed the title [WIP]: Replace GLEW with glbinding Replace GLEW with glbinding Jul 5, 2016
@9prady9
Copy link
Member Author

9prady9 commented Jul 5, 2016

@pavanky @shehzan10 Review please.

@9prady9 9prady9 force-pushed the glew_to_glbinding branch from cb716de to 6aaf3e7 Compare August 15, 2016 11:35
* [GLFW](http://www.glfw.org/)
* [freetype](http://www.freetype.org/)
* [FreeImage](http://freeimage.sourceforge.net/)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is FreeImage necessary for the library or is it necessary for the demos ?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is needed to save frame buffers to disks.

@shehzan10
Copy link
Member

I have these 2 commits locally for the same task.

shehzan10@04ded4e
shehzan10@3dd77e9

can you combine them into one and add it to this PR.

PS. Don't miss the file renames.

@@ -80,6 +80,10 @@ ELSE(TARGET forge)
ENDIF(UNIX)
ENDIF(TARGET forge)

IF(UNIX)
SET(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Wno-deprecated-declarations -Wno-unused-function")
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You missed adding -pthread.

@@ -154,7 +156,7 @@ void font_impl::loadAtlasWithGlyphs(const size_t pFontSize)
// FT_Stroker_Done(stroker);
// FT_Done_Face(face);
// FT_Done_FreeType(library);
// FT_THROW_ERROR("FT_Glyph_Stroke", fg::FG_ERR_FREETYPE_ERROR);
// FT_THROW_ERROR("FT_Glyph_Stroke", forge::FG_ERR_FREETYPE_ERROR);
//}
//FT_Stroker_Done(stroker);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why are these commented out ? Can you remove this if you can.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is related to outline strokes for characters, I added a FIXME label before the commented out code block. Removed it now.

const auto display = wglGetCurrentDC();
#elif defined(OS_LNX)
const auto display = glXGetCurrentDisplay();
#endif
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There needs to be a OSX block here. Otherwise, display will not be defined.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually, there is no need for OSX block in this case. Default value of 0 is sufficient enough. OSX OpenCL-OpenGL interop doesn't use these functions at all.

9prady9 and others added 4 commits August 17, 2016 16:13
The auto -> DisplayHandle change is required in gl_native_handles as
const auto diplay = 0; initializes auto as int which errors out reinterpret
cast.
To avoid this, initialize it as DisplayHandle.
@shehzan10
Copy link
Member

All platforms are compiling. Merging this PR.
Will open new issues for failing/buggy examples.

@shehzan10 shehzan10 merged commit e2f75ff into arrayfire:devel Aug 17, 2016
@9prady9 9prady9 deleted the glew_to_glbinding branch September 10, 2016 05:32
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants