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".
Update: random googling suggests that some Android GLSL ES2 drivers don't
support macros-with-arguments. (Maybe they are supposed to, but they
don't...)


On Tue, Jul 22, 2014 at 8:48 AM, Steven Johnson <srj@google.com> wrote:

> 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>.
>>
>
>