Check for rendering suppport in CMAKE testing generation

gazebosim / gazebo-classic

Gazebo classic. For the latest version, see https://github.com/gazebosim/gz-sim

http://classic.gazebosim.org/

Other

1.19k stars 481 forks source link

Check for rendering suppport in CMAKE testing generation #318

Closed osrf-migration closed 11 years ago

osrf-migration commented 11 years ago

Original report (archived issue) by Jose Luis Rivero (Bitbucket: Jose Luis Rivero, GitHub: j-rivero).

The goal is to be able to compile rendering needed tests only in those machines which already support them. Basically ones with direct rendering support.

Currently, there is a runtime check in gtest in this way:

#!c++

  if (rendering::RenderEngine::Instance()->GetRenderPathType() ==
      rendering::RenderEngine::NONE)

Since during cmake there is no chance of compiling and running an application we should find another way of asking the system about capabilities. Ideas:

Check glxinfo output and parse the relevant parts
Explore the Ogre code to see what is the previous C++ function currently doing. Relevant code is in: RenderSystems/GL/src/OgreGLRenderSystem.cpp

osrf-migration commented 11 years ago

Original comment by Jose Luis Rivero (Bitbucket: Jose Luis Rivero, GitHub: j-rivero).

Looking at the Ogre code, our current rendering check is really looking for the following OpenGL symbols:

#!

GLEW_EXT_Framebuffer_object 

and one of the following: 
GLEW_version2 or
GLEW_ARB_drawbuffer or 
GLEW _ATI_drawbuffer

After looking at Ogre and OpenGL code and several cmake related modules I couldn't find any solution to check for rendering which do not depend on running an executable.

Options to consider:

Run glxinfo (from mesa-utils) and grep for OpenGL needed extensions during cmake. Make gazebo depend on this package.
Create a helper small application (a bunch of OpenGL or Ogre lines), create a package for it (gazebo-gl-checker) and make gazebo depends on it. Run this helper during cmake.

osrf-migration commented 11 years ago

Original comment by Brian Gerkey (Bitbucket: Brian Gerkey, GitHub: gerkey).

I would run glxinfo and grep for the symbols that we need.

I would not make Gazebo depend on mesa-utils. Instead, if running glxinfo fails for any reason (e.g., because it's not installed), just keep going with the configuration (but, obviously, disable any display-dependent tests). That way, you can still build (and even potentially run) Gazebo on a machine without a display, which is how it should be.

osrf-migration commented 11 years ago

Original comment by Nate Koenig (Bitbucket: Nathan Koenig).

Should we look into writing our own (python?) script that we can use instead of glxinfo? It would be nice to allow users to compile Gazebo, and get all the test without a hidden dependency on glxinfo.

osrf-migration commented 11 years ago

Original comment by Brian Gerkey (Bitbucket: Brian Gerkey, GitHub: gerkey).

Not sure how that would work; presumably we'd then have a hidden dependency on the Python GL library. Unless it's possible to query the GL system without running a GL application (e.g., just parsing strings from somewhere in /dev or /proc).

I don't think that it's so bad to use glxinfo. Everybody can still compile and run all of Gazebo. The only people who lose something are those running on a GL-equipped system that doesn't happen to have mesa-utils installed. And all that they lose is the GL-dependent tests (the GL-dependent parts of Gazebo will still work properly).

osrf-migration commented 11 years ago

Original comment by Jose Luis Rivero (Bitbucket: Jose Luis Rivero, GitHub: j-rivero).

I was unable to find a method for parsing /dev and /proc which can provide the desired info.

I agree with Brian, we will end up with a hidden dependency on mesa-utils or pyopengl in both cases. Not nice. Not critical. A message on configuration can help (For automatic detection and run of GL tests, please install the mesa-utils).

We could also include a compilation define (GZ_FORCE_GL_TESTS) for people which do not want to install extra software but run the GL tests.

osrf-migration commented 11 years ago

Original comment by Brian Gerkey (Bitbucket: Brian Gerkey, GitHub: gerkey).

Based on discussion today: go with either glxinfo or a pyopengl script and we'll deal with the remaining corner cases later.

osrf-migration commented 11 years ago

Original comment by John Hsu (Bitbucket: hsu, GitHub: hsu).

glxIsDirect seems to be what we need?

osrf-migration commented 11 years ago

Original comment by Jose Luis Rivero (Bitbucket: Jose Luis Rivero, GitHub: j-rivero).

@hsu we are trying to avoid the needed of compiling a binary in the CMake step thus the use of: existing aplication (glxinfo) or non-compiled executable (pyopengl based).

osrf-migration commented 11 years ago

Original comment by Jose Luis Rivero (Bitbucket: Jose Luis Rivero, GitHub: j-rivero).

changed state from "new" to "resolved"

Implemented in pull request #251

osrf-migration commented 8 years ago

Original comment by Nate Koenig (Bitbucket: Nathan Koenig).

set version to "all"

osrf-migration commented 8 years ago

Original comment by Nate Koenig (Bitbucket: Nathan Koenig).

changed state from "resolved" to "closed"