-
Notifications
You must be signed in to change notification settings - Fork 1
/
Copy pathslides.pandoc
308 lines (202 loc) · 8.71 KB
/
slides.pandoc
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
% LambdaCube 3D DSL
## Overview
- Background
- hardware (GPUs)
- software (OpenGL)
- LambdaCube 3D
- motivations, usage, components, plans
- Demo
# Hardware background
## General trends
- Performance per watt grows exponentially for computer architectures
[5 gigaflops/watt was surpassed in 2014](http://www.green500.org/news/green500-list-november-2014)
- Consequently, computer architectures target more and more work intensive algorithms
](600px-Green500_evolution.png)
## Trends driving GPU development
Main trend: Migrate computationally intensive work from CPU to GPU
- by adding special hardware elements
- by unifying GPU hardware elements to be more general purpose
](cpu-vs-gpu-thumbnail.png)
## Work migrated from CPU to GPU
- 80's
- sprites
- line drawing
- filling
- blending (transparency)
- mid 90's
- 96: texturing, clipping
- 99: 3D vertex transformations
- 00's
- real time decompression / compression of data streams
- 2001: programmable shading
- shadow mapping
- bump mapping
- 2007: GPGPU
- computational finance
- biochemistry
- climate modelling, ...
- 10's
- tesselation
- global illumination
## Other trends in GPU development
- memory closer to computation
- more hierarchical design (see figure)
- [desktop and mobile GPUs are getting closer](http://hothardware.com/reviews/mobile-maxwell-nvidia-launches-geforce-gtx-980m-970m)
- more tight CPU - GPU integration
- planned: unified memory
- bigger displays (resolution, color depth, HZ, number of displays drivable from one card)
](GeForce_GTX_980_Block_Diagram_FINAL_575px.png)
# Software background
## GPU API
Main motivation
~ have a common interface for lots of different GPUs
How it works
~ missing features on a specific GPU are emulated on CPU
## OpenGL
Currently OpenGL is the only cross-language, multi-platform API for GPU graphics.
Scope:
- 2D and 3D vector graphics
- some general purpose GPU programming (compute shaders)
## OpenGL (2)
- History
- Development started in 1991, by Silicon Graphics Inc.
- Currently is managed by the non-profit technology consortium Khronos Group.
- Languages
- Primarily for C language, but has many language bindings
- Platforms
- desktop: iOS, Linux, Windows, ...
- OpenGL ES: for embedded systems (mobile devices)
- WebGL: JavaScript binding for browsers (Chrome, Firefox, Safari, Opera, IE, BlackBerry, Maemo, Tizen, ...)
- Versions
1.0, 1.1, 1.2, 1.2.1, 1.3, 1.4, 1.5, 2.0, 2.1, 3.0, 3.1, 3.2, **3.3**, 4.0, 4.1, 4.2, 4.3, 4.4, **4.5**
- Implementations (a.k.a. drivers)
- by graphics card manufacturers
- open source drivers
## OpenGL architecture and usage
OpenGL is a state-machine whose state is called **pipeline**.
The pipeline is an abstract model of the configured GPU
(the data is loaded into the GPU memory but the computation did not begin)
Two different group of OpenGL operations:
- pipeline setup (operations which modify the pipeline)
- pipeline execution (draw call)
Typical sequence of operations of an application:
1. initial pipeline setup
2. pipeline execution
3. put the result onto the screen (not part of OpenGL)
4. wait for user input (not part of OpenGL)
5. pipeline modification
6. go back to 2.
## OpenGL pipeline
- some parts of the pipeline are *configurable*
- some parts of the pipeline are *programmable* (configurable by a program; blue in figure)
The configuration programs are called **shaders**,
i.e. shaders are programs running on the GPU
## OpenGL pipeline (2)
## Shaders
**GLSL**: the language specified for shaders in OpenGL
- a C like language
- the same language for all OpenGL language bindings
- no real procedure calls because there is no stack on GPU
- limited procedure calls are emulated by inlining / using registers;
limitation: call graph should be known statically
- branches (`if-then-else`) and loops (`while` and `for`) are possible
Steps for processing GLSL source code:
1. the application provides GLSL code as a string (usually hand written)
2. the driver compiles it to GPU machine code (usually at runtime)
3. the code is uploaded to the GPU with specific OpenGL commands (at runtime)
# LambdaCube 3D
## Motivations
Main goal: cross-platform GPU graphics in a statically typed functional language
## LambdaCube 3D layers
Layers and design decisions:
- OpenGL backend for various architectures
- Intermediate Representation (IR)
- data type for OpenGL command sequences
- interpreted with OpenGL command calls
- functional OpenGL API
- written in a Haskell-like language
- OpenGL constraints are expressed in the type system
- OpenGL state machine is replaced by ADT expressions
- shaders are expressions with function type (`input -> output`)
- compiled to IR
- high-level layer on top of the functional OpenGL API
- library in the same language as the functional OpenGL API
- intended for use by application developers
- developed by need
## State machine vs. ADT expressions
A *state machine* is fed by a sequence of state modification operations
- each operation modifies one part of the state
- easy to express mutations of state
An *ADT expression* is built up by constructors
- ADT stands for Algebraic Data Type (a kind of composite type)
- each ADT constructor builds a substate from smaller substates
- easy to reuse substates
- immutability prevents unexpected mutations
- needs optimization to reach the same performance as with the state-machine approach
## Use strong static typing
- Language construct used:
- ADTs: the type of argument substates are constrained
- GADTs: the type of the result substate can depend on the constructor and the type of arguments used
- type classes
- type families
- example
Result: *all* OpenGL specification constraints are expressed in the type system
i.e. if the type checking succeeds at compile time, we have a valid pipeline at runtime
## Development history of LambdaCube 3D
--------------- ----------------------------------------------------
2009 begin to work on an Ogre3D compatible engine in Haskell
2011 public API of the engine as a Haskell EDSL
2012 redesigned, more functional EDSL which was ispired by [GPipe](https://wiki.haskell.org/GPipe)
2013 LambdaCube Intermediate Representation (IR) was introduced for platform independence
2015 March begin to work on a separate DSL with a compiler
2015 May begin to work on a web-based editor
2015 end of May begin LambdaCube 3D Europe Tour
--------------- ----------------------------------------------------
## Integration into applications
## LambdaCube 3D language
Scope:
- functional OpenGL API
- shader description
- high-level library on top of the functional OpenGL API
Main abstractions used: GADTs, functions, type classes
## Language specification
Haskell98 (with some diversions) + various extensions
Main diversion: different Prelude
[more](lang-specification)
## LambdaCube 3D Prelude
- no `IO` monad
- builtins for the functional OpenGL API
- GADTs
- primitive operations used in shaders
- utility functions (`id`, `foldl`, ...)
~~~~~ {.haskell}
data FrontFace
= CW
| CCW
data CullMode
= CullFront FrontFace
| CullBack FrontFace
| CullNone
data RasterContext (a :: PrimitiveType) where
TriangleCtx :: CullMode -> PolygonMode -> PolygonOffset -> ProvokingVertex -> RasterContext Triangle
PointCtx :: PointSize -> Float -> PointSpriteCoordOrigin -> RasterContext Point
LineCtx :: Float -> ProvokingVertex -> RasterContext Line
builtins
PrimAnd, PrimOr, PrimXor :: Bool -> Bool -> Bool
PrimAdd, PrimSub, PrimMul :: (t ~ MatVecElem a, Num t) => a -> a -> a
~~~~~
## Compiler
- written in Haskell
- built from scratch
## Web-based editor
## Plans
Plans for the second half of 2015
- port Quake example
- add tutorial & documentation
- organize a game jam
- develop a small, real game
- get feedback & plan next phase