Add metal view, shaders and renderer.

webrtc/sdk/objc/Framework/Classes/metal/Shaders.metal

Index: webrtc/sdk/objc/Framework/Classes/metal/Shaders.metal
diff --git a/webrtc/sdk/objc/Framework/Classes/metal/Shaders.metal b/webrtc/sdk/objc/Framework/Classes/metal/Shaders.metal
new file mode 100644
index 0000000000000000000000000000000000000000..63577d9cbd73fe415ee9b6ab643eccb555a85e85
--- /dev/null
+++ b/webrtc/sdk/objc/Framework/Classes/metal/Shaders.metal
@@ -0,0 +1,56 @@
+/*
+ *  Copyright 2017 The WebRTC project authors. All Rights Reserved.
+ *
+ *  Use of this source code is governed by a BSD-style license
+ *  that can be found in the LICENSE file in the root of the source
+ *  tree. An additional intellectual property rights grant can be found
+ *  in the file PATENTS.  All contributing project authors may
+ *  be found in the AUTHORS file in the root of the source tree.
+ */
+
+#include <metal_stdlib>
+#include <simd/simd.h>
+
+using namespace metal;

[tkchin_webrtc, 2017/02/10 23:32:10]

It is kinda burdensome to force users to include this in their bundle.
Can this be done as a C define instead?
I'll send you an email with a link for an example.

[daniela-webrtc, 2017/02/13 12:32:06]

Yes it can be done like that as well. I managed to make it work, thanks to your
pointers :)
We discussed this in the team a bit as well.
Basically that would simplify the build process but we might lose the biggest
performance win Metal offers which is precompiling shaders in a bundled library.
So we'll postpone this until we do some profiling.
Also previous experience shows that big static strings might increase binary
size even more than the bundled metal lib. 

[tkchin_webrtc, 2017/02/14 00:23:55]

I'm slightly worried about how to compile dynamic frameworks with prebuilt
shaders. It may impact CocoaPod work if this is checked in right now. Bundle
loading can be finicky, and i can only hope that shader loading works as
expected when a binary is linked against a dynamic framework and needs access to
things in its bundle.
I do agree that profiling is required to determine which approach to take here -
since we don't have a lot of shaders I don't know what the real perf impact is.

+
+typedef struct {
+  packed_float2 position;
+  packed_float2 texcoord;
+} Vertex;
+
+
+typedef struct {
+  float4 position [[position]];
+  float2 texcoord;
+} Varyings;
+
+vertex Varyings vertexPassthrough(
+                                  device Vertex* verticies [[ buffer(0) ]],
+                                  unsigned int vid [[ vertex_id ]]
+                                  ) {
+  Varyings out;
+  device Vertex& v = verticies[vid];
+  out.position = float4(float2(v.position), 0.0, 1.0);
+  out.texcoord = v.texcoord;
+
+  return out;
+}
+
+fragment half4 fragmentColorConversion(
+                                       Varyings in [[ stage_in ]],
+                                       texture2d<float, access::sample> textureY [[ texture(0) ]],
+                                       texture2d<float, access::sample> textureCbCr [[ texture(1) ]]
+                                       ) {
+  constexpr sampler s(address::clamp_to_edge, filter::linear);
+  float y;
+  float2 uv;
+  y = textureY.sample(s, in.texcoord).r;
+  uv = textureCbCr.sample(s, in.texcoord).rg - float2(0.5, 0.5);
+
+  float4 out = float4(y + 1.403 * uv.y,
+                  y - 0.344 * uv.x - 0.714 * uv.y,
+                  y + 1.770 * uv.x,
+                  1.0);
+
+  return half4(out);
+}