User:ScotXW/Rendering APIs
- We have 3D geometry and lightning data and some texture data, and would to like to create, i.e. calculate, 2D pictures based on that data plus user input ("movement" inside the game). And would like to offload some or all of this calculations to something other then the CPU. And we would like some cross-hardware, cross-platform API for that. Cf. QuakeCon 2012 – John Carmack on the principles of Lighting and Rendering – what is rendering? a straight forward explanation by John Carmack
OpenGL is an API to enable game engines to outsource computations regarding the rendering of 3D-data via Rasterisation (or via Ray-tracing?) to the GPU
OpenGL vs Direct3D
[edit]| Graphics: rendering acceleration | |||||||
|---|---|---|---|---|---|---|---|
| Release | OpenGL | Date | Direct3D | ||||
| 1996-06-06 | 2.0 | ||||||
| 1996-09-15 | 3.0 | ||||||
| 1997-03-04 | 1.1 | 1997-08-07 | 5.0 | ||||
| 1998-03-16 | 1.2 | 1998-08-07 | 6.0 | ||||
| T&L: Quake III Arena (December 27, 1999) GeForce 256 (October 11, 1999), Radeon 7000 (April 2000) | |||||||
| 2000-02-17 | 7.0 (T&L) | ||||||
| 2000-11-12 | 8.0 | ||||||
| 2001-08-14 | 1.3 | OpenGL ES 1.0 | |||||
| 2002-07-24 | 1.4 | 2002-12-19 | 9.0 | High-level shader language (HLSL) 2.0 | |||
| 2003-07-29 | 1.5 | 2003-08-13 | 9.0b | ||||
| 2004-09-07 | 2.0 | 2004-08-06 | 9.0c | OpenGL Shading Language (GLSL) v1.10.59 by 3Dlabs | |||
| Xbox 360 (November 22, 2005), (Direct3D 9.4) | |||||||
| 2006-07-02 | 2.1 | 2006-07-31 ARB ⇒ Khronos Group[1] PlayStation 3 (November 11, 2006) Wii (November 19, 2006) | |||||
| Unified shader model (2006-11-08) | |||||||
| GeForce 8800 GTS (G80) (2006-11-08) | |||||||
| 2007-01-30 | 10 | ||||||
| Radeon HD 2600 (R600) (2007-07-28) | |||||||
| 2008-08-11 | 3.0 | 2008-02-04 | 10.1 | Longs Peak and OpenGL 3.0 controversy | |||
| 2009-03-24 | 3.1 | ||||||
| 2009-08-24 | 3.2 | 2009-07-22 | 11 | ||||
| 2010-03-11 | 3.3 | ||||||
| 2010-03-11 | 4.0 | ||||||
| 2010-07-26 | 4.1 | ||||||
| 2011-08-08 | 4.2 | Rage (October 4, 2011) | |||||
| Unified virtual memory (2012-02-15) | |||||||
| 2012-02-15 Radeon HD 7000 "Southern Islands" (GCN) | |||||||
| 2012-08-06 | 4.3 | 2012-10-26 | 11.1 | ||||
| 2013-07-22 | 4.4 | 2013-10-17 | 11.2 | PlayStation 4 (15 November 2013) (GNM, GNMX & PlayStation Shader Language (PSSL)) | |||
| 2014-08-11 | 4.5 | Direct State Access (DSA) | |||||
| 2015-07-30 | 12 | ||||||
- 1996-12-23 John D. Carmack: http://www.bluesnews.com/archives/carmack122396.html
- 1997-04 Chris Hecker: http://chrishecker.com/images/3/33/Gdmogl.pdf
- 2008-07-15: Rage is still OpenGL (Rage, October 4, 2011)
- 2010-01-08 David Rosen: Why you should use OpenGL and not DirectX
- 2010-01-27 David Rosen: DirectX vs. OpenGL revisited
- 2013-03-14 Nicol Bolas: Technical history of OpenGL and Direct3D
- Note Nicol confuses the ARB with Khronos Group! Khronos took over in July 2006, so it was them, who delayed OpenGL 3 that long!
- 2014-06-08 Alex St. John: “OpenGL has been held hostage by CAD companies for over a decade. That is why ES was created”
- Alex St. John was/is technology evangelist for DirectX! Yet his assertion regarding "OpenGL and CAD" could be right; but even if the claim was right, that would not make Direct3D better then OpenGL! As a matter of fact, OpenGL 4.5 with EXT has the edge over Direct3D 11.2! See "zero driver-overhead".
- Now, that we stopped allowing Microsoft to bamboozle us even further with their crap, let's look at the actual competitors of OpenGL in the gaming market and compare:
- Compare OpenGL 4.5 + EXT with Mantle and Sony's GNM & GNMX
- Compare GLSL with PSSL
- Adoption of Direct3D 10 after its release
Preferring OpenGL
[edit]SDD 2014 January
[edit]- 2014-01-15 at SDD – Beyond Porting: How Modern OpenGL Can Radically Reduce Driver Overhead on YouTube / Slides by Cass Everitt & John McDonald (Nvidia)
- Efficient Buffer Management, McDonald 2012, for correct management of buffers with fencing; Efficient Texture Management, or "how to manage all texture memory myself"
- Moving Your Games to OpenGL
GDC 2014 March
[edit]- 2014-03-20 at GDC2014 – Approaching zero driver overhead Cass Everitt & John McDonald (Nvidia), Graham Sellers (AMD) and Tim Foley (Intel)
Mantle & OpenGL 5.0?
[edit]- 2014-06-03: Apple introduces Metal[2]
- Some guy: the problem is not that the drivers are sending millions of additional opcodes trashing the command dispatchers or not using certain optimized paths as suggested in the "Approaching zero driver overhead" talk at GDC2014!
- Problem is, that PCIe induces too high a latency and does still not have enough bandwidth??? As a result uploads to graphics memory take longer time (bandwidth) and blocks the CPU (latency). Me: does it block all CPUs? Cannot this uploads be marshalled?
- Current OpenGL game: upload TextureA, wait for upload to finish, then tell GPU to process TextureA, then upload TextureB, wait for upload to finish, then tell GPU to process TextureB, and finally render.
- Next Gen OpenGL game: upload Textures A,B,..,N to buffers A,B,..,N only once per scene (me: is this a game level?), wait for upload to finish, reference buffer A, process, reference buffer B, process, finally render. ⇒ The time difference induced by the uploading of TexturesB is gone. A big deal to the achieved rendering performance? A big deal to developer-hours-to-results?
- Of course many more factors need to work that way, the example is just a very bastardised way to show part of the problem.
Current OpenGL drivers do a lot of input validation and take care of resource management (allocation, buffering...). With Mantle, this validation and resource management have become responsibility of the game engine. – Free memory access for everyone everywhere, hooray! The input validation is there for a good reason. In best case, you just hang the hardware and have to reset. More worse, the application gets access to regions it's not allowed. Some causes of driver overhead are "cost of CPU fulfilling the API contract", Vallidation & hazard avoidance!
| “ | Much of the work that drivers used to do on an application’s behalf is now the responsibility of the game engine. ... It also means that this work, which must still be done, is done by someone with considerably more information. Because the engine knows exactly what it will do and how it will do it, it is able to make design decisions that drivers could not. | ” |
| — Firaxis on 2014-04-28, Why We Went With Mantle | ||
- http://www.firaxis.com/?/blog/single/why-we-went-with-mantle
- http://www.oxidegames.com/2014/05/21/next-generation-graphics-apis/
- http://www.joshbarczak.com/blog/?p=99
- http://www.engadget.com/2014/01/14/oxide-star-swarm-real-time-strategy-mantle-demo/
- http://www.pcgamesn.com/amds-mantle-api-how-it-works-and-why-pc-developers-will-adopt-it
- http://www.amd.com/Documents/Mantle_White_Paper.pdf
- http://community.amd.com/community/amd-blogs/amd-gaming/blog/2013/10/17/the-four-core-principles-of-amd-s-mantle
Metal API
[edit]- 2014-06-02: Apple presents Metal API
- 2014-07-18: Unreal Engine 4.3 supports Apple's Metal API
That video game developers want a new low-level rendering API (be it named OpenGL 5, Direct3D 12 or Mantle or Metal) for non-consoles has been known for years....!!!!
- AMD's Mantle was announced at the AMD Developer Summit (APU) in November 2013. As of July 2013 this API is hardware specific.
- Apple's Metal was announced in June 2014. As of July 2014 this API is specific to OS X and iOS.
- OpenGL 4.5/5.0 will be introduced at SIGGRAPH in August 2014, and hopefully its implementation will be made available for multiple hardware and multiple operating systems.
While AMD may have an interest in bringing Mantle to Linux (and possible other OSes), even releasing the specifications, it is unlikely that Apple will do that with Metal. So Metal could be viewed as yet another unique selling proposition for the Apple walled garden. Except that it is not unique. It was announced in June 2014, while Metal was announced in November 2013 and OpenGL 5 in August 2014.
It rather the other way around: Apple's actual dray-horse is their digital distribution platform for the iOS. This makes it fairly easy to monetize programming efforts, even books. All the software developers who do lack of better software distribution, might swallow Metal along the way using the Apple digital distribution platform, hence furthering walled garden-features with vendor lock-in. Looking at the crappy OpenGL implementation on OS X, even serious video game developers might swallow Metal, convince yourselves: Ubuntu With Linux 3.16 Smashes OS X 10.9.4 On The MacBook Air. Back in the day, Microsoft spread FUD about the support for OpenGL in Windows Vista with the intention to weaken OpenGL, see Why you should use OpenGL and not Direct3D!!!
Any additional rendering API to be supported, only increases development expenditures while bringing not advantages at all to ISVs!!!
Back in the day, Microsoft could push their proprietary & available for Microsoft-platforms-only stuff, because of their huge installed base. Microsoft Windows came pre-installed, one was forced to search very hardly to find hardware, that would come without a pre-installed Microsoft Windows. Today, in the mobile market, Apple could do the same with their digital distribution platform. Google Play is the only serious competitor, and a very successful one: File:World Wide Smartphone Sales.png, File:World Wide Smartphone Sales Share.png.
Do we need more successful digital distribution platforms? More competition will definitely not hurt the end-user! And this is another point: what is there for plain Linux? AFAIK, there is Steam and the Ubuntu Software Center, which can distribute software for money. Google Play is Android-only, it is e.g. not available for Debian or Fedora.
Instead of trying to compete with Red Hat (the systemd vs. Upstart-crap in Debian, Mir (software) vs. Wayland, etc. Canonical SHOULD HAVE concentrated on developing and establishing such another digital distribution platform! Sadly they rather play stupid useless crap.