The future ofhigh-performance graphics© Copyright Khronos Group 2014 - Page 1

Welcome
Tom OlsonARM© Copyright Khronos Group 2014 - Page 2

The story so far…
• Prehistory- Growing recognition that OpenGL needs a reboot• June to August 2014
- Next Generation OpenGL project launch- Unprecedented commitment from all sectors of the industry- Project disclosure and call for participation at SIGGRAPH• Since then…
- Intense focus and a lot of hard work
- Vulkan unveil at GDC 2015

© Copyright Khronos Group 2014 - Page 3

Outline• Welcome - Tom Olson, ARM• Introducing Vulkan - Johan Andersson, EA• High Level Concepts in Vulkan - Pierre-Loup Griffais, Valve• Going Wide: Vulkan and Many Threads - Dan Baker, Oxide Games• Vulkan Binding Model - Niklas Smedberg, EPIC Games• Shaders and Programs and Binary Oh My! - Aras Pranckevičius, Unity• It's Dangerous to Vulkan Alone—Take These - John McDonald, Valve© Copyright Khronos Group 2014 - Page 4

But first…
Apple• Huge thanks to the whole Vulkan team!
- New members are always welcome© Copyright Khronos Group 2014 - Page 5

THANKS "AMD!"INTRODUCING
VULKANJOHAN ANDERSSONELECTRONIC ARTSSTATE OF THE INDUSTRY} Consensus around explicit low-level graphics APIs!
} Mantle pioneered & led the way} Proven with multiple engines & full games} DX12 & Metal further contributed

NEED A STANDARD} Work on all (modern) GPUs} Supported on all platforms – desktop & mobile} Developed together – not owned by a single platform / vendor} Extensible - avoid explosion of platform- or vendor-specific APIs} Binary intermediate representation for shadersVULKAN} Based on Mantle – standardizes & replaces it} Explicit control & extremely low overhead} Designed to be efficient on a wide set of GPUs} Advanced concepts:} Multi queue & multi device} Tile-based passes & load/store operations} + Much more!

} Frostbite will transition our Mantle renderer to Vulkan

VULKAN FOUNDATION} Unprecedented collaborative rapid development in Khronos} Game engine developers} Software developers} GPU vendors} Platform vendors} Building a powerful foundation for the industry going forward!

High Level Concepts in Vulkan
Pierre-Loup Griffais

The soul of Vulkan§ Brand new API§ Built with multi-threading in mind§ Works everywhere§ Greater control over memory management§ Less hidden work and overhead in the driver§ à Smaller drivers, better driver quality

With great power…
§ More developer responsibility§ No runtime error validation§ CPU synchronization around common objects§ CPU/GPU synchronization§ GPU memory hazards

With great power…
§ More developer responsibility§ No runtime error validation§ CPU synchronization around common objects§ CPU/GPU synchronization§ GPU memory hazards§ Tools and validation suites to help developers§ John will talk more about this later

Scheduling work in Vulkan§ Queues and command buffers§ Command buffers are built on many threads§ Every command buffer is self-sufficient§ Scheduled into GPU queues

Shaders in Vulkan§ SPIR-V, brand new binary shading language§ Easy and fast to consume by the driver§ Makes offline shader compilation possible§ Spec and GLSL compiler available TODAYVulkan is here§ Valve driver for Intel GPUs developed along the spec to help ISVs
bootstrap their code
§ Source 2 supports Vulkan alpha today§ Spec and drivers coming later this year§ Intel/Linux driver will be open-sourced§ Vulkan supported across the board on Steam MachinesDemoGoing Wide: Vulkan and Many Threads
Dan	  Baker	  Graphics	  Architect,	  Oxide	  Games	  Inspirational Video• Certain	  types	  of	  games,	  peak	  loads	  can	  get	  pre<y	  big	  ThreadingObservations• GPUs	  are	  ge@ng	  faster	  more	  quickly	  than	  CPUs	  • Most	  CPU	  performance	  now	  comes	  from	  higher	  core	  count	  • SoFware	  takes	  years	  to	  develop,	  even	  if	  your	  app	  is	  not	  CPU/API	  bound	  yet,	  will	  be	  soon	  • Conclusion:	  SoFware	  must	  scale	  CSS Threading• Caller	  Side	  SynchronizaLon	  Threading	  • Previous	  generaLon	  APIS	  built	  on	  either	  single	  threaded	  or	  client/server	  thread	  designs	  • Advantageous	  if	  applicaLon	  does	  not	  make	  good	  use	  of	  mulLple	  cores	  • Hugely	  problemaLc	  if	  applicaLon	  is	  truly	  threaded	  CSS: Functions are “Silo”ed
vkTypicalCall([output],[input],[input1])

Only	  modiﬁes	  output*	  Only	  reads	  input	  No	  global	  state	  side-­‐eﬀects!	  A contract between App and API
ApplicaLon	  will	  not	  make	  conﬂicLng	  calls	  on	  the	  same	  objects	  (e.g.	  wriLng	  one	  object	  while	  another	  is	  reading	  it)	  • Driver	  will	  generally	  not	  lock	  or	  serialize	  any	  API	  call	  – Context	  informaLon	  is	  embedded	  on	  the	  object	  being	  operated	  on	  – 	  With	  excepLon	  to	  occasional	  CPU	  side	  memory	  allocaLon	  (but	  should	  be	  rare	  occurrence	  on	  create	  calls)	  •Application runs parallel to GPU
Even	  Command	  Buﬀers	  ApplicaLon	  GPU	  Odd	  Command	  Buﬀers	  Delete	  Queue	  Flush	  Queue	  Delete	  Queue	  Application runs parallel to GPU
Even	  Command	  Buﬀers	  ApplicaLon	  GPU	  Odd	  Command	  Buﬀers	  Delete	  Queue	  Flush	  Queue	  Delete	  Queue	  Review•

When	  we	  say	  Vulkan	  is	  free	  threaded,	  we	  mean	  – most	  API	  funcLon	  calls	  are	  operators.	  	  They	  operate	  only	  on	  data	  which	  is	  passed	  into	  them	  as	  output,	  and	  read-­‐only	  the	  data	  passed	  on	  that	  as	  input	  – API	  funcLon	  calls	  are	  transparent	  for	  thread	  safety:	  valid	  to	  call	  so	  long	  as	  the	  there	  is	  no	  read/write	  or	  write/write	  hazards	  – No	  hidden	  driver	  work!	  
– GPU/CPU	  hazard	  is	  explicitly	  exposed.	  GPUs	  are	  read	  operators	  on	  data,	  therefore	  read/write	  hazards	  between	  CPU/GPU	  must	  also	  be	  managed	  by	  applicaLon	  – In	  General,	  API	  funcLon	  calls	  will	  not	  have	  locks	  in	  them	  • With	  excepLon	  to	  calls	  which	  must	  allocate	  	  some	  types	  of	  memory	  	  Old way

Dead	  Lme	  Current	  Frame	  Core	  1	  Game	  Job	  Physics	  Job	  Core	  2	  AI	  Job	  Physics	  Job	  Core	  3	  AI	  Job	  Physics	  Job	  Core	  4	  Game	  Job	  AI	  Job	  AI	  Job	  Sim	  Job	  Sim	  Job	  Core	  5	  Game	  Job	  Game	  Game	  Job	  Job	  Game	  Game	  Job	  Job	  Sim	  Job	  Sim	  Job	  Core	  6	  Graphics	  	   	  Prev	  Frame	  Graphics	  Sim	  Job	  Sim	  Job	  Sim	  Job	  Sim	  Job	  ob	  Sim	  Sim	  Job	  Sim	  Job	  Graphics	  	  (Opaque,	  in	  driver)	  ???GPU	  Fence,	  or	  CPU	  wait???	  Old Way

Driver	  related	  cores.	  Missing	  Lme	  due	  to	  thread	  accounLng	  and	  system	  level	  synchronizaLon	  primiLves	  Lots	  of	  unused	  CPU	  space!	  Engine	  is	  just	  waiLng	  for	  driver	  to	  be	  done	  Powerful New model

Next	  Frame	  Current	  Frame	  Core	  1	  Sim	  Job	  Sim	  Job	  Sim	  Job	  Sim	  Job	  Core	  2	  Core	  3	  Sim	  Job	  Sim	  Job	  Core	  4	  Sim	  Job	  Core	  5	  Sim	  Job	  Core	  6	  Sim	  Job	  GPU	  Fence	  Vulkan	  CMD	  Job	  Vulkan	  	  CMD	  Job	  Game	  Job	  Vulkan	  CMD	  Job	  Vulkan	  	  CMD	  Job	  AI	  Job	  Sim	  Job	  Sim	  Job	  Vulkan	  CMD	  Job	  Vulkan	  	  CMD	  Job	  AI	  Job	  Sim	  Job	  Sim	  Job	  Vulkan	  CMD	  Job	  Vulkan	  	  CMD	  Job	  Game	  Job	  Sim	  Job	  Vulkan	  CMD	  Job	  Vulkan	  	  CMD	  Job	  Game	  Job	  Vulkan	  CMD	  Job	  Vulkan	  	  CMD	  Job	  Vk	  present	  Job	  Sim	  Job	  Sim	  Job	  Sim	  Job	  End	  of	  Frame	  New way

Vulkan	  simulaLon	  using	  a	  modiﬁed	  Mantle	  build	  to	  simulate	  inﬁnitely	  fast	  GPU	  Big performance Gains• 8-­‐Core/16	  thread	  CPUs	  exist	  today	  for	  consumers	  –	  even	  in	  mobile	  • Where	  will	  be	  in	  2	  years?	  5?	  10?	  
• On	  the	  high	  end,	  game	  genres	  are	  limited	  by	  API	  threading	  model.	  What	  types	  of	  games	  will	  Vulkan	  bring	  to	  us?	  	  Vulkan	  Binding	  Model	  Niklas	  “Smedis”	  Smedberg	  Senior	  Engine	  Programmer,	  Epic	  Games	  Goal	  • Eﬃciently	  bridge	  the	  gap	  – TradiLonal	  ﬁxed	  hardware	  bindings	  – Bindless-­‐like	  operaLon	  Overview	  • Shader	  uses	  a	  Descriptor	  to	  access	  a	  resource	  – Resources:	  Sampler,	  Image,	  Buﬀer	  • Descriptors	  are	  grouped	  into	  DescriptorSets	  – DescriptorSet	  is	  bound	  as	  a	  single	  unit	  – Shader	  bindings	  described	  by	  DescriptorSetLayout	  • Shader	  has	  mulLple	  DescriptorSet	  binding	  slots	  – Described	  by	  DescriptorSetLayoutChain	  in	  PSO	  DescriptorPool	  • DescriptorSets	  are	  allocated	  from	  a	  DescriptorPool	  	  • One-­‐shot:	  – Allocate	  unLl	  DescriptorPool	  is	  full,	  then	  clear	  enLre	  pool	  – Ultra-­‐fast	  allocator:	  great	  for	  ring	  buﬀering	  DescriptorSets	  	  • Dynamic:	  – Out-­‐of-­‐order	  allocaLon/delete	  of	  DescriptorSets	  MulLthreading	  • Update	  Descriptors	  on	  any	  thread	  	  • Pre-­‐alloc	  DescriptorSets	  of	  a	  common	  DescriptorSetLayout	  – Update	  exisLng	  DescriptorSets,	  avoiding	  alloc/free	  	  • Update	  descriptors:	  – By	  copy	  (driver	  schedules	  the	  update)	  – Immediately	  (promise	  no	  synchronizaLon	  is	  needed)	  DescriptorSetLayoutChain	  • Ordered	  by	  binding	  frequency	  (lowest	  ﬁrst)	  – Fast	  switching	  between	  similar	  DescriptorSetLayoutChains	  – Low-­‐frequency	  bindings	  are	  persistent	  	  • For	  example,	  two	  PipelineStateObjects:	  – PSO	  A	  using	  Chain	  S:	  {LayoutX,	  LayoutY,	  LayoutZ}	  – PSO	  B	  using	  Chain	  T:	  {LayoutX,	  LayoutY,	  LayoutW}	  	  • When	  binding	  PSO	  B	  aFer	  using	  PSO	  A:	  – Only	  bind	  Set	  for	  LayoutW	  – Sets	  in	  {LayoutX,	  LayoutY}	  persists	  Extra	  Features	  • Bind	  DescriptorSets	  to	  all	  or	  any	  subset	  of	  pipeline	  stage	  	  • High-­‐frequency	  buﬀer	  oﬀsets	  for	  UBOs	  and	  SSBOs	  – Can	  be	  provided	  at	  DescriptorSet	  binding	  	  • Flexibility	  with	  samplers.	  API	  supports:	  – Separate	  {sampler},{texture}	  descriptors	  – Combined	  {sampler,texture}	  descriptors	  – Immutable	  samplers	  speciﬁed	  in	  DescriptorSetLayout	  Shaders and Programs andBinary Oh My!
Aras Pranckevičius
Graphics Plumber, Unity© Copyright Khronos Group 2014 - Page 42

TL;DR• SPIR-V• It’s bytecode!
• Well, that’s it :)© Copyright Khronos Group 2014 - Page 43

Improvements• Half of the world is not even using GLSL!
- Allow more source languages• No need for full compiler stack in every driver- Solves different frontend bugs/performance• Solves IP issues for some usages© Copyright Khronos Group 2014 - Page 44

SPIR-V• Standard Portable Intermediate Representation• Core for Vulkan- Supports GLSL• Core for OpenCL 2.1- Supports CL 1.2, 2.0, 2.1 C/C++• Allows conversion from/to LLVM IR© Copyright Khronos Group 2014 - Page 45

SPIR-V• Highly regular binary representation• Higher level than other shader IRs(D3D)- No register alloc- No packing into float4- Hierarchical type info preserved- Structured flow control preserved• SSA for all intermediate results- Load/Store for IO© Copyright Khronos Group 2014 - Page 46

Splitting the work
• Offline- All frontend work
- Some optimizations• Load Time
- Conversion to GPU code, regalloc, sched• Vulkan- No hidden recompiles (full state specified)- Can save/load final pipeline objects© Copyright Khronos Group 2014 - Page 47

Source Languages & IRs• Multiple possible (GLSL & CL out of the box)
• Built-in function sets separate from core spec
• Convertible to other ILs without data loss
- SPIR-V -> LLVM -> Optimize -> SPIR-V© Copyright Khronos Group 2014 - Page 48

Misc• Extensible: can import new instruction sets & semantics• Debugging: can annotate anything with text/file/line• All instructions encode their size
- Tools can skip over unknown extensions easily© Copyright Khronos Group 2014 - Page 49

Call to shader action!
• Go write your own parser/compiler• Specification and reference GLSL->SPIR-V- Available right this second!
• Other shading languages?
- Should be possible™

© Copyright Khronos Group 2014 - Page 50

It’s Dangerous to Vulkan Alone—Take TheseJohn McDonald

Efficient Development§ Layered API§ Official SDK§ Other Tools

Layered API?
§ Vulkan consists of multiple layers§ The bottom-most layer is driver—the top-most is the application§ Application developer chooses which layers are active§ Proportional Taxation: Inactive Layers are completely freeApplication
LoaderValidation
RefCounterDriver

Layered API?
§ Vulkan consists of multiple layers§ The bottom-most layer is driver—the top-most is the application§ Application developer chooses which layers are active§ Proportional Taxation: Inactive Layers are completely free
RequiredApplication

Optional*Loader

Optional

Validation

Optional

RefCounter

Required

DriverTypes of Layers§ Active (application requested)§ Debug§ Validation§ Performance§ Passive (injected via third party)§ Steam Overlay§ FRAPS

Types of Layers§ Active (application requested)§ Debug§ Validation§ Performance§ Passive (injected via third party)§ Steam Overlay§ FRAPS§ Layers can be OSS (all Official Layers are OSS)§ Or Proprietary§ RAD Game Tools’ Telemetry Layer

Vulkan SDK§ Official SDK with BSD/MIT Open Source License directly from Khronos§ SDK Includes§ Loader§ Header / Build Scripts per platform§ Official Layers

Loader?
§ Expected that platforms will ship a default loader§ You can use this if you choose§ But applications can ship a private version as well§ Allows you to work around bugs
§ And avoids the opengl32.dll problem§ The Loader is actually just another Layer!
§ You could opt-out of using the loader, but it’s usage is highly
recommended

Official Layers§ The complete list of layers is TBD, but the current expectation is roughly:§ Loader§ Validation§ Reference Counting§ Performance Linting§ Debug§ Thread Safety§ Trace Capture & Replay§ Above may change, of course

Additional SDK Includes§ Scripts to trivially generate your own layers§ Useful for tracking down app-specific bugs
§ And helping build a richer ecosystem§ Open Source Intel Driver§ For Linux/SteamOS§ Used in today’s demos§ GLSL->BIL Compiler

Conformance Testing§ Open Source Conformance Testing!
§ Allow developers to easily verify an implementation they are running on§ And see examples of feature usage in real code§ Ensure your application is covered by submitting usage cases back toKhronos§ Patches Welcome

3rd Party Tools§ Introducing GLAVE, an Open Source Debugger for Vulkan§ Effectively VOGL, but for Vulkan§ Developed in parallel with the API§ Expected to ship with the API

Performance DemoQuestions?
§ Come ask questions at Khronos sessions today§ SF Green Space§ 657 Mission Street Suite 200 (5 minute walk)§ 12-1:30 (First Session)§ 2-3:00 (Second Session)§ All Technical Questions are fair game!

• Tom Olson: @thekhronosgroup• Johan Andersson: @repi• Pierre-Loup Griffais: @plagman• Niklas Smedberg: @EpicGames• Dan Baker: @danbaker, @oxidegames• Aras Pranckevicius: @aras_p• John McDonald: @basisspace