Implementing a Hardware Accelerated Libretro Core Hans-Kristian Arntzen May 10, 2013

Abstract Libretro API 1 recently received support for cores to use OpenGL (GL2+ or GLES2) directly instead of software rendering to a buffer which is subsequently used by the frontend. This article explains how a core can take advantage of this, and which considerations must be taken into account. This article assumes familiarity with the libretro API. Cores which use hardware rendering can still use known frontend features, such as multi-pass shaders. This is accomplished by letting cores render to frame buffer objects (FBOs) instead of the back buffer 2 . This addition to the libretro API is designed to be used with hardware-accelerated emulator cores, as well as serving as a framework for graphical demos and experiments.

Application model Using OpenGL in a libretro context is somewhat different than when you use libraries like SDL, GLFW or SFML. In libretro, the frontend owns the OpenGL context. For an application using conventional libraries like SDL, the application will do this: • Initialize, create a window of specific size • Initialize OpenGL resources • Per frame, handle window events (resize), handle input, render as desired, swap buffers 1 2

http://libretro.org GL drivers must support render-to-texture extensions for this to work.

1

• Tear down context and window Using libretro API, platform specifics like managing windows, rendering surfaces and input are all handled by the frontend. The core will only deal with rendering to a surface. The core renders to an FBO of fixed size, determined by the core. The frontend takes this rendered data and stretches to screen as desired by the user. It can apply shaders, change aspect ratio, etc. This model is equivalent to software rendering where retro video refresh t callback is called.

Using OpenGL in libretro • Use RETRO ENVIRONMENT SET PIXEL FORMAT and request a 32-bit format. This is the format that the resulting framebuffer will have 3 . • Use RETRO ENVIRONMENT SET HW RENDER environment callback in retro load game(), notifying frontend that core is using hardware rendering. An OpenGL 2+ or GLES2 context can be specified here. If this is not supported the callback will return false, and you can fallback to software rendering or refuse to start. • In retro get system av info(), as normal, max width and max height fields specify the maximum resolution the core will render to. • When the frontend has created a context or reset the context, retro hw context reset t is called. Here, OpenGL resources can be initialized. The frontend can reset the context at will (e.g. when changing from fullscreen to windowed mode and vice versa). The core should take this into account. It will be notified when reinitialization needs to happen. • A callback to grab OpenGL symbols is exposed via retro hw get proc address t. Use this to retrieve symbols and extensions. • In retro run(), use retro hw get current framebuffer t callback to get which FBO to render to 4 . This is your ”backbuffer”. Do not 3 In reality, RetroArch converts all 16-bit data (RETRO PIXEL FORMAT RGB565) to 32-bit (XRGB8888) when running desktop GL for performance reasons. In GLES mode, this is not done, however. Do not rely on this behavior, and be explicit about it. 4 e.g. glBindFramebuffer(GL FRAMEBUFFER, get current framebuffer())

2

attempt to render to the real back buffer. You must call this every frame as it can change every frame. The dimensions of this FBO are at least as big as declared in max width and max height. If desired, the FBO also has a depth buffer attached 5 . • When done rendering, call retro video refresh t with the macro RETRO HW FRAME BUFFER VALID as argument for buffer. Width and height should be specified as well, but pitch argument is irrelevant and will be ignored. If the frame is duped 6 , the buffer argument takes NULL as normal.

Important considerations in the OpenGL code The frontend and libretro core share OpenGL context state. Some considerations have to be taken into account for this cooperation to work nicely. • Don’t leave buffers and global objects bound when calling retro video refresh t. Make sure to unbind everything, i.e. VAOs, VBOs, shader programs, textures, etc. Failing to do this could potentially hit strange bugs. The frontend will also follow this rule to avoid clashes. Being tidy here is considered good practice anyway. • The GL viewport will be modified by frontend as well as libretro core. Set this every frame. • glEnable() state like depth testing, etc, is likely to be disabled in frontend as it’s just rendering a quad to screen. Enable this per-frame if you use depth testing. There is no need to disable this before calling retro video refresh t. • Avoid VAOs. They tend to break on less-than-stellar drivers 7 . • Try to write code which is GLES2 as well as GL2+ (w/ extensions) compliant. This ensures maximum target surface for the libretro core. • Libretro treats top-left as origin. OpenGL treats bottom-left as origin. To be compatible with the libretro model, top-left semantics are preserved. Rendering normally will cause the image to be flipped 5

see RETRO ENVIRONMENT SET HW RENDER RETRO ENVIRONMENT CAN DUPE 7 At least AMD drivers on Windows are known to break here. 6

3

vertically. To avoid this, simply scale the final projection matrix by [1, −1, 1, 1].

Test implementations A very basic test implementation of libretro GL interface is available in RetroArch repository on GitHub 8 . It displays two spinning quads. It runs both as a GLES2 and GL2 core depending on GLES environment variable. A slightly more involved test core is found on Bitbucket 9 . It uses instanced rendering of a textured cube, with FPS-style fly-by camera. It uses libretro’s mouse API as well. It is valid GLES and GL2 at the same time.

Building a libretro core Libretro is an interface, and not a utility library. Libretro cores are built as standalone dynamic or static libraries, and as they use GL symbols here, they must link against GL symbols themselves. An example of how this can be done is shown in the test implementation 10 .

8

https://github.com/Themaister/RetroArch/tree/master/libretro-test-gl https://bitbucket.org/Themaister/libretro-gl 10 https://github.com/Themaister/RetroArch/blob/master/libretro-test-gl/Makefile 9

4

Implementing a Hardware Accelerated Libretro Core - GitHub

May 10, 2013 - The frontend takes this rendered data and stretches to screen as ... at least as big as declared in max width and max height. If desired, the FBO ...

157KB Sizes 15 Downloads 172 Views

Recommend Documents

Accelerated Edition - GitHub
All graphics used here are public domain. ..... Succeed: Create or discover the aspect, get a free ... Succeed: Generate one free invocation on the aspect.

Hardware and Representation - GitHub
E.g. CPU can access rows in one module, hard disk / another CPU access row in ... (b) Data Bus: bidirectional, sends a word from CPU to main memory or.

A Hybrid Hardware-Accelerated Algorithm for High ...
octree data structures [27]. Hardware-accelerated .... nal rendering quality comparison (shown in Figure 4) to ..... Reality modeling and visualization from multiple.

Prometheus: Designing and Implementing a Modern ... - GitHub
New("counter cannot decrease in value")). } c.value += v .... (pprof) web ... Highly optimized C libraries can be great. ... Loss of certain advantages of the Go build.

Hardware-Accelerated Rendering of Photo Hulls -
Compared to a pure software implementation, the performance of our hardware-accelerated method .... OMR: Online Model Reconstruction for Interactive Virtual. Environments [Lok01]. ..... a P4 1.7GHz processor machine equipped with a GeForce. FX 5800 U

Hardware-Accelerated Visual Hull Reconstruction and ...
Jun 11, 2003 - System Performance & Demo Video. Conclusions & Future Work. Introduction ... 3D interactive TV, computer games, tele-communication, etc.

MS RAMAIAH INSTITUTE OF TECHNOLOGY Hardware ... - GitHub
6.2 Tests and results of frequency domain technique . . . . . . . . . . 33. 6.3 Tests and results of spatial domain .... represented as a linear combinations of the DCT basis functions which are shown in Fig.1.4. The DCT basis functions are obtained

MIAOW Whitepaper Hardware Description and Four ... - GitHub
design so likely to remain relevant for a few years, and has a ... Table 1: MIAOW RTL vs. state-of-art products (Radeon HD) .... details are deferred to an accompanying technical report. ...... our workloads and believe programs rarely do this.

CORE-pdf-A4-P.cdr - GitHub
Page 1. EL - TEC. - *

CORE-pdf-A4-P.cdr - GitHub
Page 1. - A. - wat e. |-I. }-->

Embedded Hardware Design For An Autonomous Electric ... - GitHub
Mar 9, 2011 - Department of Electrical and Computer Engineering. University of .... At peak load, the steering motor can draw up to 10Amps continuously.

Copyright Scarab Hardware 2014 With some parts from ... - GitHub
P9. P$9. P10. P$10. P11. P$11. P12. P$12. P13. P$13. P14. P$14. P15. P$15. P16. P$16. P17. P$17. P18. P$18. P19. P$19. P20. P$20. P21. P$21. P22. P$22.

An Open-Source Hardware and Software Platform for ... - GitHub
Aug 6, 2013 - Release 1.03. Zihan Chen. 1. , Anton Deguet. 1. , Russell Taylor. 1. , Simon DiMaio .... the high-speed serial network (IEEE-1394a) and the I/O hardware. In this design .... of services: isochronous and asynchronous transfers.

Implementing the Local Sky Model in the MeqTree System - GitHub
Date of issue: 2005-Jul-08. Scope: Project Documentation. Kind of issue: Public ... System Engineering Manager. Program Manager. J.E. Noordam. C.M. de Vos.

Accelerated Publication
tides, and cell culture reagents such as Geneticin (G418) and hygromy- cin B were ..... We also thank. Dr. S. E. H. Moore for critical reading of the manuscript.

Core Bluetooth MySQL Database Server Static content ... - GitHub
get map information. Robot. Position. Container. Jobs. Route. Calculator using A* algorithm get graph information give live list of containers and their position.