BeagleBoard/GSoC/BeagleBoard-GPUBx

=BeagleBoard-GPUBx =

BeagleBoard GPUBx is an extensive toolkit for benchmarking the BeagleBoard GPU. This toolkit consists of verious programs/shaders, built using OpenGL ES 2.0 and GLSL, which involve complex mathematical computations for rendering, and we make the GPU perform these computations and based on how it performs, we benchmark it. Hence, this project provides an estimate of the efficiency of the onboard GPU. I have also created a YouTube video for a quick demonstration of my project.

Student: Shreyas Iyer Mentors: Jason Kridner, Hunyue Yau, Robert Manzke Code: https://github.com/l0ftyWhizZ/BeagleBoard-GPUBx Wiki: http://elinux.org/BeagleBoard/GSoC/BeagleBoard-GPUBx GSoC: GSoC entry

=Status= This project is currently just a proposal.

=Proposal= Goal: Sample programs to utilize the GPU for computations. The GPU on most of the BeagleBone/Board are limited to OpenGL ES 2; Goal is to provide sample programs to show using GLES2 for computations. Software Skills: OpenGLES, GLSL Reference: thebookofshaders Possible Mentors: Hunyue Yau, Robert Manzke

About you
IRC: Shreyas Github: My Github Profile School: International Institute of Information Technology, Bangalore Country: India Primary language (We have mentors who speak multiple languages): English, Hindi Typical work hours (We have mentors in various time zones): 12AM-8AM US Eastern (9:30 AM - 5:30 PM Indian Standard Time (IST)) Previous GSoC participation: This is my second attempt at GSoC. I had applied for a project under Copyleft Games last year, but unfortunately it didn't get accepted. I want to work on this project with BeagleBoard because me being a game developer and graphics programmer, I should learn to develop high quality shaders for my applications or games, and also in a way such that the algorithm is efficient for the GPU to render. This project serves the exact same purpose, and it will really help me in my career. Also, considering the the scale factor of the BeagleBoard, this analysis will help in improving the efficiency of the onboard GPU.

About your project
Project name: BeagleBoard GPUBx - A benchmarking tool for the BeagleBoard GPU

Overview
BeagleBoard® contains an onboard GPU, capable of 2D/3D rendering, which can be manipulated through OpenGL ES 2.0. Offloading complex instructions onto the GPU from the CPU is evidently advantageous, since presence of multiple cores in the GPU, all working in parallel, would result in a much faster computation, as compared to the CPU. So, through this project, using GLSL along with OpenGL ES, we develop a benchmarking suite of programs which make use of custom shaders which provide intensive computations to the GPU, at the end of which we compute how efficient the GPU was, and in turn benchmark the GPU. The GPU will be tested for various parameters, with programs like: 1 * Procedurally-generated terrain using noise functions (Perlin noise in particular), changing the amplitude of the noise dynamically, and checking for performance drops. 2 * Ray marching in complex 3D environments. 3 * Ocean shader, using Perlin noise and Fresnel shading. 4 * Shaders where vertex data is altered according to noise function, resulting in a dynamically changing mesh. (3D)
 * Fractal shaders, whose computation reflects the memory bandwidth of the GPU.
 * Graphically-intensive shaders (2D and 3D) for testing the rendering capability of the GPU, which includes:
 * Post-processing effects, such as Bloom, HDR, Depth of Field (DoF), and other advanced lighting effects.

Languages used: C++ along with OpenGL ES 2.0, and OpenGL Shading Language (GLSL).

Aim
The aim of the project is to develop a tool, which tests the GPU in various parameters, be it in terms of metrics like Frames Per Second (FPS while rendering complex environments, or post-processing effects), or computation time (for computing solutions to complex problems involving FFT, or Linear Algebra). So, we develop different programs which will help us benchmark the GPU.

Approach
Before delving into the main content, we talk about the necessity of offloading the CPU into PU:

Background Theory: The main reason of offloading the CPU instructions to the GPU is to exploit the presence of multiple cores present in the GPU. CPUs have a small number of cores (limited to 4 in most of the cases), whereas the modern GPUs have several hundred cores, all running in parallel. Hence complex instruction sets can be offloaded to the GPU, resulting in a faster computation. Figure below shows the basic mechanism: So, our aim is to exploit the parallel computing of the GPU, by developing shaders involving complex/intensive computations, and benchmarking the GPU based on how it performs.

Fractal shaders:
-- Fractal shaders are generally derived from a considerably simple linear algebraic equation, which on computing per-pixel, results in a highly-detailed and complex structure. Generally, the algorithm goes through some iterations while drawing, and the computations during these iterations are sometimes resource-heavy even for a powerful system. So, we perform some pre calculations in order to achieve a decent frame rate. We make use of the parallel computing on the GPU, since rendering of a unique pixel doesn’t depend on nearby pixel’s information. Following is a GLSL code snippet: By modifying the values of the constant terms in the given snippet, CONSTANT_1 and CONSTANT_2 in particular, we get different fractals, out of which some can be categorized as Mandelbrot Fractals and Julia Fractals. Also, in order to push the GPU to the limit, we can keep on dynamically increasing the number of iterations the algorithm has to go through. I can even tweak the code to implement animated fractals, like pulsating and progressive fractals, by introducing the time varying attribute in the shader. For reference, I am using this repository: https://github.com/jonathan-potter/shadertoy-fractal. Below is a simple Mandelbrot fractal:

Graphically-Intensive shaders
-- In this section, we develop multiple shaders, all serving the same purpose - computing the ‘Frames Per Second’ while the GPU renders the environment. The shaders to be built are categorized as: 1) Ray Marching shaders: In this category, as the name suggests, the ray is “marched” every time frame by some step size, and at every step we check whether the ray has intersected with some primitive or not. It gives us an estimate of how far are we from a primitive, and base our rendering calculations around that. This method is useful while rendering volumetric primitives that are to be integrated along the ray. Using this, we can build our shaders that result in a different ray marching environment with different levels of detail. I have already made a few ray marching shaders, which are up on my shadertoy profile as well as on my Github profile. Following is a basic ray marching function in GLSL: So, in the above snippet, modifying the values of the constants would yield a different output, be it different volumetric primitives, or different marching step size. Using a similar technique, I have also developed a Voxel terrain marching shader, which is hosted on https://www.shadertoy.com/profile/djeof1. For ideas and references, I am using https://www.shadertoy.com.

2) Procedurally-generated terrain using Noise: As the name suggests, we initially create a flat ground, where the y-coordinate (or height) associated with each of the points are the same. Then using a modified version of the inbuilt noise function, such that the resulting terrain is acceptable in terms of variations in height and continuity, we modify the y-coordinate of each of the pixels according to the function, which results in an terrain, and then we perform ray marching over the terrain. There are several inbuilt noise functions defined in GLSL like,       vec2 noise (vec2 pixel), vec2 noise (vec3 pixel), vec3 noise (vec3 x), vec3 noise (vec2 x) ... In order to create higher-quality noise functions, we add the noise functions upto a certain octave, for example we take a noise function and add it to itself once, we get a second octave, add it again, we get third octave, and so on. At higher octaves, the noise function reaches closer to being ideal. Now, in order to make an ideal noise function, we must take care of the following major properties:
 * 1) It should be a continuous function giving the appearance of randomness.
 * 2) The function must have a well-defined range of outputs. (Between [-1,1] or [0,1])
 * 3) The values which are the result of this function must not show regular patterns.
 * 4) It must be isometric, that means it should be rotationally invariant.

Perlin's method of noise creation is considered to be one of the best noise functions for the purpose of terrain creation, and is widely used in almost every graphics related application, or games. Below is a snippet of generating the heightmap for each of the points of the terrain:

Timeline
Provide a development timeline with a milestone each of the 11 weeks. (A realistic timeline is critical to our selection process.)

2017-06-06: Milestone #1 2017-06-13: Milestone #2 2017-06-20: Milestone #3 2017-06-27: Milestone #4 2017-07-04: Milestone #5 2017-07-11: Milestone #6 2017-07-18: Milestone #7 2017-07-25: Milestone #8 2017-08-01: Milestone #9 2017-08-08: Milestone #10 2017-08-15: Milestone #11

Experience and approach
In 5-15 sentences, convince us you will be able to successfully complete your project in the timeline you have described.

Contingency
In case I am stuck at a particular phase while development, and also my mentor isnt available, then following are the steps that I would take (in no particular order) :
 * I would talk to the members of the BeagleBoard community by posting my queries on the mailing lists, and also the IRC.
 * I would look up for the solution or similar on the internet. With websites like stackoverflow.com, and even shadertoy.com, the community is extremely friendly and helpful.
 * I would also ask my Computer vision and graphics professor at my institute for guidance.

Benefit
If successfully completed, what will its impact be on the BeagleBoard.org community? Include quotes from BeagleBoard.org community members who can be found on http://beagleboard.org/discuss and http://bbb.io/gsocchat.

Suggestions

 * More details could have been given regarding what is exactly expected of the project, what kind of programs are to be developed and how many of them are to made.
 * Nothing else to suggest