Understanding OpenGL programs internals

For a start, you will need to understand lots of terms: GLX, OpenGL, DRI, DRM etc. Lookup here:

http://people.freedesktop.org/~ajax/dri-explanation.txt

for the definition.

Looking up resources in internet (eg, http://pyopengl.sourceforge.net/, or just search "wiretorus.py" for python implementation of torus drawing using OpenGL),

The heart of the program can summarized as follows:

glLoadIdentity()

gluLookAt(
0.0, 0.0, 10.0,
0.0, 0.0, 0.0,
0.0, 1.0, 0.0)

glRotatef(xrot, 1.0, 0.0, 0.0)
glRotatef(yrot, 0.0, 1.0, 0.0)
glRotatef(zrot, 0.0, 0.0, 1.0)

glutWireCube(1)
glColor3f(0.5, 0.0, 1.0)
glutWireTorus(0.5,1.5,36,36)

And the drawing as follow:

Using gdb to attach to the python program:

#0 0x00007fa60b4acb90 in __poll_nocancel ()
at ../sysdeps/unix/syscall-template.S:81
#1 0x00007fa607d12b72 in ?? () from /usr/lib/x86_64-linux-gnu/libxcb.so.1
#2 0x00007fa607d143ff in ?? () from /usr/lib/x86_64-linux-gnu/libxcb.so.1
#3 0x00007fa607d14512 in xcb_wait_for_reply ()
from /usr/lib/x86_64-linux-gnu/libxcb.so.1
#4 0x00007fa60898c48f in _XReply () from /usr/lib/x86_64-linux-gnu/libX11.so.6==========================>
#5 0x00007fa60970c673 in ?? () from /usr/lib/x86_64-linux-gnu/mesa/libGL.so.1
#6 0x00007fa60970a02b in ?? () from /usr/lib/x86_64-linux-gnu/mesa/libGL.so.1
#7 0x00007fa60263a9a9 in ?? () from /usr/lib/x86_64-linux-gnu/dri/i965_dri.so
#8 0x00007fa60263adc3 in ?? () from /usr/lib/x86_64-linux-gnu/dri/i965_dri.so
#9 0x00007fa60262f8f5 in ?? () from /usr/lib/x86_64-linux-gnu/dri/i965_dri.so
xxx
xxx
#30 0x000000000055c594 in PyEval_EvalCodeEx ()
#31 0x00000000005b7392 in PyEval_EvalCode ()
#32 0x0000000000469663 in ?? ()
#33 0x00000000004699e3 in PyRun_FileExFlags ()
#34 0x0000000000469f1c in PyRun_SimpleFileExFlags ()
#35 0x000000000046ab81 in Py_Main ()
#36 0x00007fa60b3e0ec5 in __libc_start_main (main=0x46ac3f <main>, argc=2,
argv=0x7fff7d08c1e8, init=<optimized out>, fini=<optimized out>,
rtld_fini=<optimized out>, stack_end=0x7fff7d08c1d8) at libc-start.c:287
#37 0x000000000057497e in _start ()

The legacy of X protocol as shown below (http://www.artima.com/articles/desktop_grid2.html):

And underlying the packet exchange:

Here "_XReply" is an X extension API as documented here:

http://www.ualberta.ca/dept/chemeng/AIX-43/share/man/info/C/a_doc_lib/libs/x11tr/_XReply.htm

http://xwindow.angelfire.com/page27.html

and here:

http://ps-2.kev009.com/tl/techlib/manuals/adoclib/libs/x11tr/xreply.htm

As defined above: _XReply does: "Flushes the output buffer, waits for a reply packet, and copies the contents into the specified Reply parameter."

And the modern implementation is this (inside src/xcb_io.c of libX11-1.6.2 from Ubuntu’s source code repository):

/*
* _XReply - Wait for a reply packet and copy its contents into the
* specified rep.
* extra: number of 32-bit words expected after the reply
* discard: should I discard data following "extra" words?
*/
Status _XReply(Display *dpy, xReply *rep, int extra, Bool discard)
{
xcb_generic_error_t *error;
xcb_connection_t *c = dpy->xcb->connection;
char *reply;
PendingRequest *current;

which is implemented using XCB API (vs Xlib in the past, which uses lots of locks, and thus is slow). And further understanding XCB protocol (notice the mention of lockless protocol):

http://xcb.freedesktop.org/tutorial/

And the public API is documented here:

http://xcb.freedesktop.org/PublicApi/

Doing a search for the packages:

apt-file search libGL.so

libgl1-mesa-dev: /usr/lib/x86_64-linux-gnu/libGL.so
libgl1-mesa-dev: /usr/lib/x86_64-linux-gnu/mesa/libGL.so
libgl1-mesa-glx: /usr/lib/x86_64-linux-gnu/mesa/libGL.so.1

So, based on above, if you do a "apt-get source libgl1-mesa-dev" you will see that you end up with the Mesa source code.

From the stack trace above, we see that the Mesa component is implemented on top of _XReply API (X extension):

For example, is the glx init screen:

_X_HIDDEN Bool
glx_screen_init(struct glx_screen *psc,
int screen, struct glx_display * priv)
{
/* Initialize per screen dynamic client GLX extensions */
psc->ext_list_first_time = GL_TRUE;
psc->scr = screen;
psc->dpy = priv->dpy;
psc->display = priv;

getVisualConfigs(psc, priv, screen);
getFBConfigs(psc, priv, screen);

return GL_TRUE;
}

where getVisualConfigs():

static GLboolean
getVisualConfigs(struct glx_screen *psc,
struct glx_display *priv, int screen)
{
xGLXGetVisualConfigsReq *req;
xGLXGetVisualConfigsReply reply;
Display *dpy = priv->dpy;

LockDisplay(dpy);

psc->visuals = NULL;
GetReq(GLXGetVisualConfigs, req);
req->reqType = priv->majorOpcode;
req->glxCode = X_GLXGetVisualConfigs;
req->screen = screen;

if (!_XReply(dpy, (xReply *) & reply, 0, False))
goto out;

psc->visuals = createConfigsFromProperties(dpy,
reply.numVisuals,
reply.numProps,
screen, GL_FALSE);

out:
UnlockDisplay(dpy);
return psc->visuals != NULL;
}

And here are the relation between GLX and OpenGL (OpenGL extension):

And trying to understanding the Mesa source tree downloaded:

http://www.mesa3d.org/sourcetree.html

From above both the OpenGL and DRI drivers will talk to Nouveau modules directly:

And the kernel modules loaded:

lsmod |grep nouv

nouveau 1097199 0
mxm_wmi 13021 1 nouveau
ttm 85150 1 nouveau
drm_kms_helper 55071 2 i915,nouveau
drm 303102 7 ttm,i915,drm_kms_helper,nouveau
i2c_algo_bit 13413 2 i915,nouveau
wmi 19177 3 mxm_wmi,nouveau,asus_wmi
video 19476 3 i915,nouveau,asus_wmi

Another way of looking at some ofl the libraries called by the python program:

(gdb) info sharedlibrary

/usr/lib/x86_64-linux-gnu/mesa/libGL.so.1
/usr/lib/x86_64-linux-gnu/libX11-xcb.so.1
/usr/lib/x86_64-linux-gnu/libxcb-dri3.so.0
/usr/lib/x86_64-linux-gnu/libGLU.so.1

More OpenCL introductions

http://www.x.org/wiki/Events/XDC2013/XDC2013TomStellardCloverStatus/XDC2013TomStellardCloverStatus.pdf

and the video is here:

http://www.phoronix.com/scan.php?page=news_item&px=MTQ2OTQ

OpenCL history:

http://image.slidesharecdn.com/kite-opencl-course-141010090714-conversion-gate01/95/hands-on-opencl-19-638.jpg?cb=1413191038

Both the internals of OpenCL and “Clover” (OpenCL over Gallium) history are explained.

Here below are further development from Apple:

http://support.apple.com/en-us/HT202823

Classic sequence of calls:

clGetPlatformIDs ( [ . . . ] ) ;
clGetDeviceIDs ( [ . . . ] ) ;
clCreateContext ( [ . . . ] ) ;
clCreateCommandQueue ( [ . . . ] ) ;
clCreateProgramWithSource ( [ . . . ] ) ;
clBuildProgram ( [ . . . ] ) ;
clCreateKernel ( [ . . . ] ) ;
clCreateBuffer ( [ . . . ] ) ;
clSetKernelArg ( [ . . . ] ) ;
clEnqueueNDRangeKernel ( [ . . . ] ) ;
c l F i n i s h ( [ . . . ] ) ;
clEnqueueReadBuffer ( [ . . . ] );

http://people.freedesktop.org/~nh/piglit/

OpenCL vs OpenGL Compute Shaders:

https://www.opengl.org/discussion_boards/showthread.php/180692-OpenGL-Compute-Shaders-vs-OpenCL

http://gamedev.stackexchange.com/questions/64061/implementing-algorithms-via-compute-shaders-vs-pipeline-shaders

http://www.pouet.net/topic.php?which=9095

https://www.linkedin.com/groups/Using-GLSL-Shader-from-OpenGL-1729897.S.203326291

Libclc implementation:

http://libclc.llvm.org/

http://blog.jholewinski.org/llvm-3-0-ptx-backend/

http://www.wenda.io/questions/484488/how-to-use-clang-to-compile-opencl-to-ptx-code.html

Current status of OpenCL in Nouveau (http://en.wikipedia.org/wiki/Nouveau_%28software%29):

http://dri.freedesktop.org/wiki/GalliumCompute/

From http://www.phoronix.com/scan.php?page=news_item&px=MTgwODA:

(AMD development on OpenCL “AMDGPU”)

Accelerating a climate physics model with OpenCL

http://saahpc.ncsa.illinois.edu/11/presentations/zafar.pdf

https://devtalk.nvidia.com/default/topic/521004/opencl-opengl-interop-4-5x-slower-than-cg-shaders-performance-issues-with-opencl/

http://ebiquity.umbc.edu/_file_directory_/papers/630.pdf

Good overview:

http://www.slideshare.net/vladimirstarostenkov/hands-on-opencl

A study on Shaders /GLSL

http://stackoverflow.com/questions/4200224/random-noise-functions-for-glsl

http://stackoverflow.com/questions/6478342/glsl-interlacing

http://stackoverflow.com/questions/10652862/glsl-semaphores

https://www.opengl.org/documentation/glsl/

http://blog.lwjgl.org/ray-tracing-with-opengl-compute-shaders-part-i/

http://www.cse.chalmers.se/edu/year/2011/course/TDA361/Advanced%20Computer%20Graphics/deferredshading2012.pdf

http://web.engr.oregonstate.edu/~mjb/cs475/Handouts/compute.shader.1pp.pdf

Shader vs OpenCL:

https://devtalk.nvidia.com/default/topic/468883/ray-tracing-glsl-vs-cuda-opencl/

https://devtalk.nvidia.com/default/topic/521004/opencl-opengl-interop-4-5x-slower-than-cg-shaders-performance-issues-with-opencl/

http://www.pouet.net/topic.php?which=9095

http://gamedev.stackexchange.com/questions/64061/implementing-algorithms-via-compute-shaders-vs-pipeline-shaders

https://www.linkedin.com/groups/Using-GLSL-Shader-from-OpenGL-1729897.S.203326291

http://stackoverflow.com/questions/11838246/rendering-particles-should-i-learn-shader-or-opencl

https://www.opengl.org/discussion_boards/showthread.php/180692-OpenGL-Compute-Shaders-vs-OpenCL

http://www.java-gaming.org/index.php?topic=25613.0

Unboxing my HackRF One

Reading “Getting Started with the HackRF One on Ubuntu 14.04”:

https://mborgerson.com/getting-started-with-the-hackrf-one-on-ubuntu-14-04/

Starting from freshly installed Ubuntu 14.04 LTS 64-bit, something missing in the above blog (explained below) is this:

sudo apt-get install librtlsdr-dev

Next is to download all the three git tree.

While doing the cmake of “gr-osmosdr”:

cmake ../
…
CMake Error at CMakeLists.txt:151 (find_package):
Could not find a configuration file for package “Gnuradio” that is
compatible with requested version “3.7.3”.

The following configuration files were considered but not accepted:

/usr/lib/x86_64-linux-gnu/

cmake/gnuradio/GnuradioConfig.cmake, version: 3.7.2.1

— Configuring incomplete, errors occurred!

So no choice but to use the original webpage’s changeset version (notice there is a one digit difference between mine and his ….. guess it is an error in his webpage).

For gr-osmosdr, to get the older version:

git checkout  58d95b51

And then continue with cmake/make/make install etc.

Got the following errors:

—   package ‘gnuradio-fcdproplus’ not found
— gnuradio-fcdproplus not found.
— Could NOT find GNURADIO_FCDPP (missing:  GNURADIO_FCDPP_LIBRARIES GNURADIO_FCDPP_INCLUDE_DIRS)
— checking for module ‘libosmosdr’
—   package ‘libosmosdr’ not found
— libosmosdr not found.
— checking for module ‘librtlsdr’
—   package ‘librtlsdr’ not found
— librtlsdr not found.
— checking for module ‘libmirisdr’
—   package ‘libmirisdr’ not found
— libmirisdr not found.
— checking for module ‘libhackrf’
—   found libhackrf, version 0.3
— Found LIBHACKRF: /usr/local/lib/libhackrf.so
— checking for module ‘libairspy’
—   package ‘libairspy’ not found
— Could NOT find LIBAIRSPY (missing:  LIBAIRSPY_LIBRARIES LIBAIRSPY_INCLUDE_DIRS)
— checking for module ‘libbladeRF’
—   package ‘libbladeRF’ not found
— libbladeRF not found.
— Could NOT find Doxygen (missing:  DOXYGEN_EXECUTABLE)
— Found PythonLibs: /usr/lib/x86_64-linux-gnu/libpython2.7.so (found suitable version “2.7.6”, minimum required is “2”)

I ignored all the errors, except for one: librtlsdr, which I have to apt-get thus:

sudo apt-get install librtlsdr-dev

After the gqrx download and qmake, everything got running, on the latest changeset (today is 21 Dec 2014).

There is another way for Ubuntu/Fedora as well:

Go to:

http://gnuradio.org/redmine/projects/gnuradio/wiki/InstallingGRFromSource#Using-the-build-gnuradio-script

And run the script.   It will build all the necessary binaries – completed successfully for both Fedora 20 and Ubuntu 14.04.

Essentially it will install every “hackrf_xxxxx” command, but not gqrx itself.   So using “hackrf_transfer” to capture the radio wave, and then followed by installing a third party tool “Baudline” it is possible to render the radio waves as well.   For details please refer to:

http://blog.kismetwireless.net/2013/08/playing-with-hackrf-keyfobs.html

blog.kismetwireless.net/2013/08/hackrf-pt-2-gnuradio-companion-and.html

I did also tried direct “apt-get” for the following:

gqrx-sdr – Software defined radio receiver
gr-osmosdr – Gnuradio blocks from the OsmoSDR project
hackrf – Software defined radio peripheral
libhackrf-dev – Software defined radio peripheral
libhackrf0 – Software defined radio peripheral

For gqrx, after apt-get, I got the following errors:

gqrx: symbol lookup error:

Many places recorded the same errors:

https://lists.debian.org/debian-hams/2014/10/msg00013.html

Upgrading using RPi:

http://314256.blogspot.sg/2014_09_01_archive.html

Similarly for Fedora 20, “sudo yum install gqrx”  will install all the dependencies for gqrx, (essentially gr-osmosdr, and rtl-sdr, and gnuradio), but executing “gqrx” does not bring up and QT screen at all.

Docker vs VM vs Vagrant vs LXC

http://www.programering.com/a/MDMzAjMwATk.html (see diagram below)

http://stackoverflow.com/questions/20578039/difference-between-kvm-and-lxc

http://www.slideshare.net/miurahr/introduction-to-vagrantdockernttdata

http://en.community.dell.com/techcenter/os-applications/w/wiki/6950.lxc-containers-in-ubuntu-server-14-04-lts

http://www.slideshare.net/sverma/juju-lxc-openstack-fun-with-private-clouds

Different forms of hypervisor:

http://netmgt.blogspot.sg/2012/01/virtualizations-lpars-ldoms-and-xen.html

Glue for all:

http://www.linux-kvm.org/wiki/images/3/3b/2012-forum-libvirt-sandbox-kvm.pdf