A Clo loud Gaming Framework for Dynamic Graphical Rendering Towards - PowerPoint PPT Presentation

A Clo loud Gaming Framework for Dynamic Graphical Rendering Towards Achie ieving Dis istri ributed Game Engines James Bulman, Peter Garraghan Evolving Distributed Systems Lab Lancaster University, UK

Video Games World’s largest entertainment sector Game Instance • $143.5 billion in 2020 Render Update Game engines use tightly-coupled subsystems Handle Swap game game • Graphics, physics, AI, lighting, audio, etc… Input Buffers state state • Synchronize within the game loop Game Code Ambitious creativity -> Quality of Experience Graphical API • Higher computation & hardware demands Operating System • Game consoles, GPUs, VR, etc. Hardware

Cloud Gaming Cloud gaming exploits cloud resources providing Games as a Service • Google Stadia, Microsoft Project xCloud • Game executed in cloud VM with minor* modifications Cloud VM Benefits • Instant access to games without downloads • Powerful hardware -> higher quality experiences • Cross-device access Video by Jordan Mechner, licensed under the Creative Commons Attribution-Share Alike 4.0 International

Research Problem Reliance on Cloud performance & dependability Cloud VM • VM interference or failure • Network volatility Update Render game state game state • Inconsistent framerate, total service loss Monolithic game engine architectures Input Video • Tightly-coupled subsystems processor encoding • Limited portability (OS, graphics API) • Game per VM: “Equiv. game experience + latency” Video Input Input Video Allow cloud-client Distributed game processor player execution subsystems Client device

Objectives A Cloud Gaming Framework for Distributed Game Engines Features • Loose-coupling graphical renderer and game engine • Dynamic cloud-client frame interlacing • Graphical API hot-swapping Advantages • Platform and graphics API independence • Tolerate against Cloud failure and network loss • First distributed game engine designed for the cloud

Overview CloudRend • Leverages generic graphical commands • Converts these commands to API specific calls • Cloud-client rendering • Supports Vulkan, OpenGL CloudRend Cloud VM CloudRend Game Instance Manager Mitigation CloudRend Command Graphic API Buffer Converter Hotswap Renderer Frame QoS Selector Interlacing Monitor OpenGL Vulkan

Mitigation Hotswap Frame Interlacing Run-time switching of Graphical APIs Collaborative cloud-client rendering (Vulkan, OpenGL) (based on network) Cloud VM Cloud VM Cloud VM Vulkan OpenGL 30 frames/s 30 frames/s OpenGL

Architecture Game Loop CloudRend CloudRend Instance Instance Screen #1 #2 0% 100% Vulkan OpenGL Encoder Encoder Local CloudRend Renderer Interface Instance OpenGL Decoder Client Cloud

CloudRend CloudRend CloudRend Game Loop Interface Instance RenderModel() Command RenderModel Vulkan Processor RenderLightSet() vkCmdPushConstants() RenderModel() Transmit EndFrame() vkCmdBindVertexBuffers() Command Buffer RenderLightSet() vkCmdBindIndexBuffers() vkCmdDrawIndexed() Read Framebuffer RenderLightSet Screen Vulkan Decode Frame Encode Frame vkCmdPushConstants() Client Cloud

Setup System • Cloud : i7-7700HQ, GTX 1050 GPU, Vulkan/OpenGL • Client : Raspberry Pi 4, Quad Core Cortex-A72, OpenGL ES 3.0 Variable latency wireless network (16 – 100 ms) Experiments Low: 500 vertices • Cloud-client frame interlacing (100- 0% … 0% -100%) • Graphical API hotswapping per frame • 10,000 frame per run, frames per second (FPS), network High: 200k vertices

Initial Results In Low Vertices Scene 60 Trade-off render complexity High Vertices Scene Framerate (FPS) vs network latency 40 Higher consistent framerates when interlacing 20 Low network utilization ~4 Mbps 0 Local 25% 50% 75% Cloud Cloud Cloud Cloud

Conclusions Cloud gaming framework via distributed game engines • Successful game distribution across cloud and client devices • 33% performance gains, cloud latency vs. client computation Vision • Create fully-fledged cloud gaming framework and distributed game engines • Cloud gaming in the home Future Work • Network-aware + power-aware frame interlacing • System at scale – shared subsystems • More decoupled subsystems – AI, collision detection, physics

Thanks Contact • James Bulman - j.bulman@lancaster.ac.uk • Peter Garraghan - p.garraghan@lancaster.ac.uk Evolving Distributed Systems Lab School of Computing & Communications Lancaster University, UK