Download as PDF, PPTX
![Rendering Upside Down
Solutions?
Could sample with (U, 1 - V)
Could render and flip in NDC (X,-Y,Z)
We choose to render upside down.
Fewer choke points: lots of texture samples in shader code!
You have to transform your post-projection vertex positions anyway. D3D
expects Z in [0,1], OpenGL expects Z in [-1,1].
Can wrap all of this in to a single patched projection matrix for no runtime
cost.
You also have to reverse your polygon winding when setting rasterizer state!
BUT: Remember not to flip when rendering to the backbuffer!](https://image.slidesharecdn.com/gdc14bringingunrealengine4toopengl1-140714030002-phpapp02/75/Gdc-14-bringing-unreal-engine-4-to-open_gl-20-2048.jpg)
Uploaded bychangehee lee
Gdc 14 bringing unreal engine 4 to open_gl
This document discusses bringing Unreal Engine 4 to OpenGL by porting its render hardware interface (RHI) to support OpenGL. It describes mapping the D3D11-based RHI to OpenGL, developing a cross-compiler to compile HLSL shaders to GLSL, addressing differences between D3D and OpenGL like texture coordinate systems, and optimizations to achieve performance parity with D3D11. It also covers bringing UE4 to Android by leveraging an NVIDIA Tegra K1 mobile chip's full OpenGL 4.4 support.
More Related Content
![[IGC 2016] 넷게임즈 김영희 - Unreal4를 사용해 모바일 프로젝트 제작하기](https://cdn.slidesharecdn.com/ss_thumbnails/igcppt-161008143730-thumbnail.jpg?width=640&height=640&fit=bounds)
Similar to Gdc 14 bringing unreal engine 4 to open_gl
![[Kgc2012] deferred forward 이창희](https://cdn.slidesharecdn.com/ss_thumbnails/kgc2012deferredforward-121010214035-phpapp02-thumbnail.jpg?width=640&height=640&fit=bounds)
![[Kgc2013] 모바일 엔진 개발기](https://cdn.slidesharecdn.com/ss_thumbnails/kgc2013-130929065039-phpapp02-thumbnail.jpg?width=640&height=640&fit=bounds)
Gdc 14 bringing unreal engine 4 to open_gl
- 1. BRINGING UNREAL ENGINE4 TO OPENGL Nick Penwarden – Epic Games Mathias Schott, Evan Hart – NVIDIA | March 20, 2014
- 2. About Us Nick Penwarden LeadGraphics Programmer – Epic Games @nickpwd on Twitter Mathias Schott Developer Technology Engineer – NVIDIA Evan Hart Principal Engineer - NVIDIA
- 3. Unreal Engine 4 Latestversion of the highly successful UnrealEngine Long, storied history Dozens of Licensees Hundreds of titles Built to scale Mobile phones and tablets Laptop computers Next-gen Console High-end PC
- 4. Why OpenGL? The onlychoice on some platforms: Mac OS X iOS Android Linux HTML5/WebGL Access to new hardware features not tied to OS version. Microsoft has been tying new versions of Direct3D to new versions of Windows. OpenGL frees us of these restrictions: D3D 11.x features on Windows XP!
- 5. Porting UE4 toOpenGL UE4 is a cross platform game engine. We run on many platforms today (8 by my count!) with more to come. Extremely important that we can develop features once and have them work across all platforms!
- 6. (Very) High LevelLook at UE4 Game Engine World PrimitiveComponents … LightComponents … Etc. Renderer Scene PrimitiveSceneInfo … LightSceneInfo … Etc. RHI Shaders Textures Vertex Buffers Etc. CROSS PLATFORM PLATFORM DEPENDENT
- 7. Render Hardware Interface Largelybased on the D3D11 API Resource management Shaders, textures, vertex buffers, etc. Commands DrawIndexedPrimitive, Clear, SetTexture, etc.
- 8. OpenGL RHI Much ofthe API maps in a very straight-forward manner. RHICreateVertexBuffer -> glGenBuffers + glBufferData RHIDrawIndexedPrimitive -> glDrawRangeElements What about versions? 4.x vs 3.x vs ES2 vs ES3 What about extensions? A lot of code can be shared between versions, even ES2 and GL4.
- 9. OpenGL RHI Use aclass hierarchy with static functions. Each platform ultimately defines its own, typedefs it as FOpenGL. Optional functions defined here, e.g. FOpenGL::TexStorage2D() Depending on platform could be unimplemented, glTexStorage2DEXT, glTexStorage2D, … Optional features have a corresponding SupportsXXX() function. E.g. FOpenGL::SupportsTexStorage(). If support depends on an extension, we parse the GL_EXTENSIONS string at boot time and return that. If support is always (or never) available for the platform we return a static true or false. This allows the compiler to remove unneeded branches and dead code. Allows us to share basically all of our OpenGL code across ES2, GL3, and GL4!
- 10. What about shaders? Thatother stuff was easy. Well, not exactly, Evan and Mathias will explain why later. We do not want to write our shaders twice! We have a large, existing HLSL shader code base. Most of our platforms support an HLSL-like shader language. We want to be able to compile and validate our shader code offline. Need reflection to create metadata used by the renderer at runtime. Which textures are bound to which indices? Which uniforms are used and thus need to be computed by the CPU?
- 11. What are ouroptions? Can we just compile our HLSL shaders as GLSL with some magical macros? No. Maybe for really simple shaders but the languages really are different in subtle ways that will cause your shaders to break in OpenGL. So use FXC to compile the HLSL and translate the bytecode! Can work really well! But not for UE4: we support Mac OS X as a full development platform. Any good cross compilers out there? None that support shader model 5 syntax, compute, etc. At least none that we could find two years ago :)
- 12. HLSLCC Developed our owninternal HLSL cross compiler. Inspired by glsl-optimizer: https://github.com/aras-p/glsl-optimizer Started with the Mesa GLSL parser and IR: http://www.mesa3d.org/ Modified the parser to parse shader model 5 HLSL instead of GLSL. Wrote a Mesa IR to GLSL converter, similar to that used in glsl- optimizer. Mesa includes IR optimization: this is an optimizing compiler!
- 13. Benefits of CrossCompilation Write shaders once, they work everywhere. Contain platform specific workarounds to the compiler itself. Offline validation and reflection of shaders for OpenGL. Treat generated GLSL that doesn’t work with a GL driver as a bug in the cross compiler. Simplifies the runtime, especially resource binding and uniforms. Makes mobile preview on PC easy!
- 14. GLSL Shader Pipeline ShaderCompiler Input HLSL Source HLSL Source HLSL Source HLSL Source #defines Compiler Flags MCPP* Shader Compiler Output GLSL Source Parameter Map Parse HLSL -> Abstract Syntax Tree Convert AST -> Mesa IR Convert IR for HLSL entry point to GLSL compatible main() Optimize IR Pack uniforms Optimize IR Convert IR -> GLSL + parameter map HLSLCC * http://mcpp.sourceforge.net/
- 15. Resource Binding When theOpenGL RHI creates the GLSL programs, setting up bind points is easy: Renderer binds textures to indices. RHISetShaderTexture(PixelShader,LightmapParameter,LightmapTexture); Same as every other platform. for (int32 i=0; i < NumSamplers; ++i) { Location = glGetUniformLocation(Program, “_psi”); glUniform1i(Location,i); } (from parameter map)
- 16. Uniform Packing All globaluniforms are packed in to arrays. Simplifies binding uniforms when creating programs: We don’t need the strings of the uniform’s names, they are fixed! glGetUniformLocation(“_pu0”) Simplifies shadowing of uniforms when rendering: RHISetShaderParameter(Shader,Parameter,Value) Copy value to shadow buffer, just like the D3D11 global constant buffer. Simplifies setting of uniforms in the RHI: Track dirty ranges. For each dirty range: glUniform4fv(…) Easy to trade off between the quantity of glUniform calls and the amount of bytes uploaded per draw call.
- 17. Uniform Buffer Emulation(ES2) Straight-forward extension of uniform packing. Rendering code gets to treat ES2 like D3D11: it packages uniforms in to buffers based on the frequency at which uniforms change. The cross compiler packs used uniforms in to the uniform arrays. Also provides a copy list: where to get uniforms from and where they go in the uniform array.
- 18. UV Space Differences -1,-1 +1,+1 0,0 1,1 0,0 1,1 NormalizedDevice Coordinates Direct3D UV Space OpenGL UV Space
- 19. From the Shader’sPoint of View -1,-1 +1,+1 0,0 1,1 0,0 1,1 Normalized Device Coordinates Direct3D UV Space OpenGL UV Space
- 20. Rendering Upside Down Solutions? Couldsample with (U, 1 - V) Could render and flip in NDC (X,-Y,Z) We choose to render upside down. Fewer choke points: lots of texture samples in shader code! You have to transform your post-projection vertex positions anyway. D3D expects Z in [0,1], OpenGL expects Z in [-1,1]. Can wrap all of this in to a single patched projection matrix for no runtime cost. You also have to reverse your polygon winding when setting rasterizer state! BUT: Remember not to flip when rendering to the backbuffer!
- 21. After Patching theProjection Matrix -1,-1 +1,+1 0,0 1,1 0,0 1,1 Normalized Device Coordinates Direct3D UV Space OpenGL UV Space
- 22. Next… Evan and Mathiaswill talk about extending the GL RHI to a full D3D11 feature set. Also, how to take all of this stuff and make it fast!
- 23. Achieving DX11 Parity Enableadvanced effects Not a generic DX11 layer Only handle engine needs 60% shader / 40% engine Evolves over time with engine OpenGL API
- 24. From OpenGL 3.xto 4.x Compute shaders General Shader upgrades Unordered Access Views Tessellation Lots of extensions And API enchancements but Maintain Core API Compatibility ES2, GL3, GL4 etc
- 25. General Shader Upgrades Toomany to discuss Most straight forward Some ripple in HLSLCC Type system IR Optimization Different UBO packing rules for Arrays Shared Memory RWTexture* RWBuffer* Memory Barriers Shared Memory Atomics UAV Atomic Conversion and packing functions Texture arrays Integer Functions Texture Queries New Texture Functions Early Depth Test
- 26. Compute Shader API Simpleanalogs for Dispatch Need to manage resources No separate binding points i.e. no CSetXXX Memory behavior is different DirectX 11 hazard free OpenGL exposes hazards Enforce full coherence Guarantees correctness Optimize later //State Setup glUseProgram( ComputeShader); SetupTexturesCompute(); SetupImagesCompute(); SetupUniforms(); //Ensure reads are coherent glMemoryBarrier(GL_ALL_BARRIER_BITS); glDispatchCompute( X, Y, Z); //Ensure writes are coherent glMemoryBarrier(GL_ALL_BARRIER_BITS);
- 27. Unordered Access Views Direct3D11 world view Multiple shader object types RWBuffer, RWTexture2D, RWStructuredBuffer, etc Unified API for setup CSSetUnorderedAccessViews OpenGL world view GL_image_load_store (Closer to Direct3D 11) GL_shader_buffer_storage_object Solution Use GL_image_load_store as much as possible Indirection table for other types
- 28. Tessellation (WIP) Both havetwo shader stages Direct3D11: Hull Shader & Domain Shader OpenGL: Tessellation Control Shader &Tessellation Evaluation Shader Notable divergence: HLSL Hull vs. GLSL Tessellation Control Shader HLSL has two Hull Shader functions Hull shader (per control point) PatchConstantFunction (per patch) GLSL has a single TESSELLATION_CONTROL_SHADER Explicitly handle patch constant computations
- 29. Tessellation Solution Execute TCSin phases First hull shader Next patch constants GLSL provides barrier Ensures values are ready Patch constant function is scalar Just execute on one thread Possibly vectorize later layout( vertices = 3) out; void main() { //Execute Hull shader barrier(); if (gl_InvocationID == 0) { //Execute Patch constant } }
- 30. Optimization Feature complete isonly half the battle No one wants pretty OpenGL 4.3 at half the performance Initial test scene < ¼ of Direct3D 90 FPS versus ~13 FPS (IIRC)
- 31. HLSLCC Optimizatons Initially heavilyGPU bound Internal engine tools were fantastic Just needed to implement proper OpenGL query support Shadows were the biggest offender Filtering massively slower Projection somewhat slower Filter offsets and projection matrices turned into temp arrays GPU compilers couldn’t fold through the temp array Needed to aggressively fold / propagate Reduced performance deficit to < 2x
- 32. Software Bottlenecks Remaining bottleneckswere mostly CPU Both application and driver issues Driver is very solid, but Unreal Engine 4 is a big test Heaviest use of new features This effort made the driver better Applications issues were often unintuitive Most problems were synchronizations Overall, lots of onion peeling
- 33. Application & DriverSyncs Driver likes to perform most of its work on a separate thread Often improves software performance by 50% Control panel setting to turn it off for testing Can be a hindrance with excessive synchronization Most optimization effort went into resolving these issues General process Run code with sampling profiler Look at inclusive timing results Find large hotspot on function calling into the driver Time reflects wait for other thread
- 34. Top Offenders glMapBuffer (andsimilar) Needs to resolve and queued glBufferData calls Replace with malloc + glBufferSubData glGetTexImage Used with reallocating mipmap chains Replace with glCopyImageSubData glGenXXX Every time a new object is created Replace with a cache of names quaried in a large block glGetError Just say no, except in debug
- 35. Where are we? Infiltratorperformance is at parity (<5% difference) Primitive throughput test is faster Roughly 1 ms Rendering test is slower Roughly 1.5-2.0 ms
- 36. Where do wego? More GPU optimization Driver differences Loop unrolling improvements More software optimizations Reduce object references Already implemented for UBOs Bindless Textures More textures & Less overhead BufferStorage Allows persistent mappings Reduces memory copying
- 37. Supporting Android Tegra K1opened an interesting door Mobile chip with full OpenGL 4.4 capability Common driver code means all the same features Can we run “full” Unreal Engine 4 content? Yes Need to make some optimizations / compromises No different than a low-end PC Work done in NVIDIA’s branch On-going work with Epic to feedback changes
- 38. What were thechallenges? High resolution, modest GPU Rely on scaling Turn some features back (motion blur, bloom, etc) Aggressively optimize where feasible Do reflections always need to be at full resolution? Modest CPU Often disable cpu-hungry rendering Shadows Optimize API at every turn Modest Memory Remove any duplication