GLSL: Handle more intrinsics, fix bugs in code generation and texture transfer

Map intrinsics to correct GLSL functions:
- trigonometric functions (sin, cos, tan, asin, acos, atan, atan2)
- exponential functions (pow, exp, log)
- general functions (floor, ceil, lerp)

Since GLSL doesn't support bit arithmetic, don't use C backend to generate
code for "Mod" and "Div".
Perhaps I'm misreading the syntax error that I'm getting from KitKat, but
it appeared to be complaining about the macro usage. However, it's moot
now; I'll try the latest patch when I get in.


On Tue, Jul 22, 2014 at 8:13 AM, Daniel Heck <notifications@github.com>
wrote:

> In src/CodeGen_OpenGL_Dev.cpp:
>
> > @@ -312,9 +382,22 @@ void CodeGen_GLSL::compile(Stmt stmt,
> >      if (opengl_es) {
> >          stream << "precision highp float;\n";
> >      }
> > -    stream << "#define sin_f32 sin\n";
> > -    stream << "#define cos_f32 cos\n";
> > -    stream << "#define sqrt_f32 sqrt\n";
> > +    stream << "#define sdiv(a, b) ((a - (int)mod((float)a, (float)b))/b)\n"
>
> It *should* permit macros with arguments, but there is actually little
> reason for us to depend on the preprocessor since it's just as easy to
> directly generate proper GLSL code.
>
> (In this case, it turns out that GLSL ES does support integer divisions,
> so there's no need for something like sdiv().)
>
> —
> Reply to this email directly or view it on GitHub
> <https://github.com/halide/Halide/pull/381/files#r15233477>.
>