Remove out-of-date document.

Signed-off-by: Zhigang Gong <zhigang.gong@intel.com>

3 files changed, 47 insertions, 99 deletions

diff --git a/Software/Beignet/Backend.mdwn b/Software/Beignet/Backend.mdwn
index be6081b2..319ce817 100644
--- a/Software/Beignet/Backend.mdwn
+++ b/Software/Beignet/Backend.mdwn
@@ -88,7 +88,7 @@ Implementation details
 Several key decisions may use the hardware in an usual way. See the following
 documents for the technical details about the compiler implementation:
 
-- [[Flat address space|flat_address_space]]
+- [[Mixed buffer pointer)|mixed_buffer_pointer]] 
 - [[Unstructured branches|unstructured_branches]]
 - [[Scalar intermediate representation|gen_ir]]
 - [[Clean backend implementation|compiler_backend]]
diff --git a/Software/Beignet/Backend/flat_address_space.mdwn b/Software/Beignet/Backend/flat_address_space.mdwn
deleted file mode 100644
index 3018a295..00000000
--- a/Software/Beignet/Backend/flat_address_space.mdwn
+++ /dev/null
@@ -1,98 +0,0 @@
-Flat Address Space
-==================
-
-Segmented address space...
---------------------------
-
-The first challenge with OpenCL is its very liberal use of pointers. The memory
-is segment into several address spaces:
-
-- private. This is the memory for each work item
-
-- global. These are buffers in memory shared by all work items and work groups
-
-- constant. These are constant buffers in memory shared by all work items and
-work groups as well
-
-- local. These is a memory shared by all work items in the *same* work group
-
-... But with no restriction inside each address space
------------------------------------------------------
-
-The challenge is that there is no restriction in OpenCL inside each address
-space i.e. the full C semantic applies in particular regarding pointer
-arithmetic.
-
-Therefore the following code is valid:
-
-<code>
-\_\_kernel void example(\_\_global int *dst, \_\_global int *src0, \_\_global int *src1)<br/>
-{<br/>
-&nbsp;&nbsp;\_\_global int *from;<br/>
-&nbsp;&nbsp;if (get\_global\_id(0) % 2)<br/>
-&nbsp;&nbsp;&nbsp;&nbsp;from = src0;<br/>
-&nbsp;&nbsp;else<br/>
-&nbsp;&nbsp;&nbsp;&nbsp;from = src1;<br/>
-&nbsp;&nbsp;dst[get\_global\_id(0)] = from[get\_global\_id(0)];<br/>
-}
-</code>
-
-As one may see, the load done in the last line actually mixes pointers from both
-source src0 and src1. This typically makes the use of binding table indices
-pretty hard. In we use binding table 0 for dst, 1 for src0 and 2 for src1 (for
-example), we are not able to express the load in the last line with one send
-only.
-
-No support for stateless in required messages
----------------------------------------------
-
-Furthermore, in IVB, we are going four types of messages to implement the loads
-and the stores
-
-- Byte scattered reads. They are used to read bytes/shorts/integers that are not
-aligned on 4 bytes. This is a gather message i.e. the user provides up to 16
-addresses
-
-- Byte scattered writes. They are used to write bytes/shorts/integers that are not
-aligned on 4 bytes. This is a scatter message i.e. the user provides up to 16
-addresses
-
-- Untyped reads. They allow to read from 1 to 4 double words (i.e 4 bytes) per
-lane. This is also a gather message i.e. up to 16 address are provided per
-message.
-
-- Untyped writes. They are the counter part of the untyped reads
-
-Problem is that IVB does not support stateless accesses for these messages. So
-surfaces are required. Secondly, stateless messages are not that interesting
-since all of them require a header which is still slow to assemble.
-
-Implemented solution
---------------------
-
-The solution is actually quite simple. Even with no stateless support, it is
-actually possible to simulate it with a surface. As one may see in the run-time
-code in `intel/intel_gpgpu.c`, we simply create a surface:
-
-- 2GB big
-
-- Which starts at offset 0
-
-Surprisingly, this surface can actually map the complete GTT address space which
-is 2GB big. One may look at `flat_address_space` unit test in the run-time code
-that creates and copies buffers in such a way that the complete GTT address
-space is traversed.
-
-This solution brings a pretty simple implementation in the compiler side.
-Basically, there is nothing to do when translating from LLVM to Gen ISA. A
-pointer to `__global` or `__constant` memory is simply a 32 bits offset in that
-surface.
-
-Related problems
-----------------
-
-There is one drawback for this approach. Since we use a 2GB surface that maps
-the complete GTT space, there is no protection at all. Each write can therefore
-potentially modify any buffer including the command buffer, the frame buffer or
-the kernel code. There is *no* protection at all in the hardware to prevent
-that.
diff --git a/Software/Beignet/Backend/mixed_buffer_pointer.mdwn b/Software/Beignet/Backend/mixed_buffer_pointer.mdwn
new file mode 100644
index 00000000..f43ab7ed
--- /dev/null
+++ b/Software/Beignet/Backend/mixed_buffer_pointer.mdwn
@@ -0,0 +1,46 @@
+Mixed Buffer Pointer
+--------------------
+
+Segmented address space...
+--------------------------
+
+The first challenge with OpenCL is its very liberal use of pointers. The memory
+is segment into several address spaces:
+
+- private. This is the memory for each work item
+
+- global. These are buffers in memory shared by all work items and work groups
+
+- constant. These are constant buffers in memory shared by all work items and
+work groups as well
+
+- local. These is a memory shared by all work items in the *same* work group
+
+... But with no restriction inside each address space
+-----------------------------------------------------
+
+The challenge is that there is no restriction in OpenCL inside each address
+space i.e. the full C semantic applies in particular regarding pointer
+arithmetic.
+
+Therefore the following code is valid:
+
+<code>
+\_\_kernel void example(\_\_global int *dst, \_\_global int *src0, \_\_global int *src1)<br/>
+{<br/>
+&nbsp;&nbsp;\_\_global int *from;<br/>
+&nbsp;&nbsp;if (get\_global\_id(0) % 2)<br/>
+&nbsp;&nbsp;&nbsp;&nbsp;from = src0;<br/>
+&nbsp;&nbsp;else<br/>
+&nbsp;&nbsp;&nbsp;&nbsp;from = src1;<br/>
+&nbsp;&nbsp;dst[get\_global\_id(0)] = from[get\_global\_id(0)];<br/>
+}
+</code>
+
+As one may see, the load done in the last line actually mixes pointers from both
+source src0 and src1. This typically makes the use of binding table indices
+pretty hard. In we use binding table 0 for dst, 1 for src0 and 2 for src1 (for
+example), we are not able to express the load in the last line with one send
+only. The pointer "from" in the last line is so called a mixed buffer pointer.
+
+(To be updated)