FlightGear wiki

FlightGear and OpenGL Core Profile: Difference between revisions

Page Discussion

FlightGear and OpenGL Core Profile (view source)

Revision as of 22:51, 10 December 2020

4,983 bytes added ,  10 December 2020
m
→‎Affected features and sources: https://sourceforge.net/p/flightgear/mailman/search/?q=Skia+AND+Canvas&mail_list=all
No edit summary
m (→‎Affected features and sources: https://sourceforge.net/p/flightgear/mailman/search/?q=Skia+AND+Canvas&mail_list=all)
(44 intermediate revisions by 2 users not shown)
Line 11: Line 11:


{{Portability Navbar}}
{{Portability Navbar}}
== Objective ==
{{See also|Howto:Build and run FlightGear on Raspberry Pi 4}}
{{Wikipedia|OpenGL ES}}
 
Some FG users are very interested in seeing how FlightGear runs on lower end/embedded hardware (think RPi-style) using {{Wikipedia|OpenGL ES}}.
 
The bigger issue here is we need to ditch [[PUI]] (which is in progress) and some OpenGL 1.0 code (HUD, 2D panels especially - can be #ifdef for now) so we can enable Core profile on Mac - since Mac 4.x support (we only hit about 4.3 alas, but with some extensions to get in sight of 4.5) is Core profile only, no Compatability mode.
 
I *believe* the new open-source Intel-Mesa drivers on Linux (which are supposed to decent quality, and even fast) might be in the same situation.<ref>https://sourceforge.net/p/flightgear/mailman/message/36341578/</ref>
 
Probably to do it initially, GLES1 would have to be used - I think GLES2 has no fixed function - and simgear/flightgear would have to be patched to use only OSG calls (if possible), e.g. by excluding features/subsystems that still use legacy OpenGL code incompatible with GLES.


Some FG users are very interested in seeing how FlightGear runs on low end hardware - because they may have a collection of it :)
OSG can have GLES{1,2} support without windowing compiled in.


Probably to do it initially, gles1 would have to be used - I think gles2 has no fixed function - and simgear/flightgear would have to be patched to use only OSG calls (if possible)
OpenGL 1 and 2 can be mixed but OpenGL ES 1 and OpenGL ES 2 can't. There is a performance price to pay for this backward compatibility. For this reason, we should get rid of PLib because this (old) code is all OpenGL 1 that may slowdown the all rendering pipeline.


I know OSG can have gles{1,2} support without windowing compiled in
For historical reasons, Flightgear and Simgear are mixing OpenGL 1
(old code) and OpenGL 2 (more recent code).<ref>https://sourceforge.net/p/flightgear/mailman/message/36980923/</ref>


== Background ==
== Background ==
{{Main article|Howto:Optimizing FlightGear for mobile devices}}
{{Main article|Howto:Optimizing FlightGear for mobile devices}}


being able to run fgfs on such, comparatively low-powered, system is actually a good thing for fgfs as a whole - it can help us understand bottlenecks that are hardly visible on typical gaming rigs, but that may still show up over time (think leaking listeners/memory) - this sort of thing can also be considered the prerequisite for people wanting to target/build/run fgfs on other embedded hardware, such as thin clients with integrated GPUs or even mobile phones (think Android)
The OpenSceneGraph port initiated in 2006 has never been fully completed, so that there is a certain amount of code making use of legacy OpenGL calls, which complicates modernizing the renderer.
 
In particular, this means that [[Supporting multiple renderers]] is unnecessarily complicated, [[Unifying the 2D rendering backend via canvas|unifying the 2D rendering back-end]] is a long standing challenge. It's only since just very recently, that supporting different renderers is being worked on thanks to the [[Compositor]] effort.


In other words, if the right people were to team up to specifically such hardware, this could also mean significant performance improvements for people on powerful gaming rigs.
But even then, phasing out legacy code or porting it, still needs to be addressed sooner or later.
 
Being able to run fgfs on such, comparatively low-powered, systems using OpenGL ES can actually be a good thing for fgfs as a whole - it can help us understand bottlenecks that are hardly visible on typical gaming/developer rigs, but that may still show up over time (think leaking listeners/memory) - this sort of thing can also be considered the prerequisite for people wanting to target/build/run fgfs on other embedded hardware, such as thin clients with integrated GPUs or even mobile phones/tablets (think Android)
 
we need to remove PUI and change the Canvas not to use Shiva, to be ES2 compatible or Core-profile compatible.<ref>https://sourceforge.net/p/flightgear/mailman/message/36194973/</ref>
 
In other words, if the right people were to team up to specifically target such hardware, this could also mean significant performance improvements for people on powerful gaming rigs.


== Approach ==
== Approach ==
{{See also|Unifying the 2D rendering backend via canvas}}


For starters, we can try the [[FlightGear Headless]] option to build a fgfs version without any graphics at all.
For starters, we can try the [[FlightGear Headless]] option to build a fgfs version without showing any graphics at all.


The next step will be identifying and excluding problematic sources (those containing legacy/raw OpenGL code, e.g. using <code>glBegin()</code> or <code>glEnable()</code> respectively):
The next step will be identifying and excluding problematic sources (those containing legacy/raw OpenGL code, e.g. using <code>glBegin()</code> or <code>glEnable()</code> respectively):
Line 48: Line 65:
Whenever FlightGear sources contain such or similar code, it is pretty safe to assume that we will need to port/exclude such modules from compilation to ensure that no legacy OpenGL code is executed at runtime.
Whenever FlightGear sources contain such or similar code, it is pretty safe to assume that we will need to port/exclude such modules from compilation to ensure that no legacy OpenGL code is executed at runtime.


== Example: disabling PUI ==
<syntaxhighlight>
Instrumentation/HUD/HUD_runway.cxx
Instrumentation/HUD/HUD_tbi.cxx
Instrumentation/HUD/HUD.hxx
Instrumentation/HUD/HUD_instrument.cxx
Instrumentation/HUD/HUD_ladder.cxx
Instrumentation/HUD/HUD_dial.cxx
Instrumentation/HUD/HUD_tape.cxx
Cockpit/render_area_2d.cxx
Cockpit/panel.cxx
GUI/WaypointList.cxx
GUI/CanvasWidget.cxx
GUI/MapWidget.cxx
</syntaxhighlight>
 
This means, we'll need to review/disable the compilation of the following folders in $FG_SRC and patch up all hard-coded references to these systems:
* Instrumentation/HUD
* Cockpit
* GUI
 
In addition, there's Viewer/PUICamera.cxx which references glEnable()
 
== Example: Disabling PUI ==
{{Main article|Developing using CMake}}
{{Main article|Developing using CMake}}


We should add separate build options to explicitly disable certain features individually, e.g.:
We should add separate build options to explicitly disable certain features individually.
* <code>-DDISABLE_PUI</code>
 
* <code>-DDISABLE_2DPANELS</code>
The bigger issue here is we need to ditch PUI (which is in progress) and some OpenGL 1.0 code (HUD, 2D panels especially - can be #ifdef for now) so we can enable Core profile on Mac - since Mac 4.x support (we only hit about 4.3 alas, but with some extensions to get in sight of 4.5) is Core profile only, no Compatability mode.<ref>https://sourceforge.net/p/flightgear/mailman/message/36341578/</ref>


Knowing that [[PUI]] contains legacy OpenGL code and knowing it's scheduled to be removed anyway because it isn't compatible with modern OpenGL, we will disable it completely without  
Knowing that [[PUI]] contains legacy OpenGL code and knowing it's scheduled to be removed anyway because it isn't compatible with modern OpenGL, we will disable it completely without  
Line 69: Line 108:
option(SYSTEM_CPPUNIT    "Set to ON to build Flightgear with the system's CppUnit library")
option(SYSTEM_CPPUNIT    "Set to ON to build Flightgear with the system's CppUnit library")
option(DISABLE_PUI    "Set to ON to build Flightgear without PUI support")
option(DISABLE_PUI    "Set to ON to build Flightgear without PUI support")
if(DISABLE_PUI)
      add_definitions(-DDISABLE_PUI)
endif(DISABLE_PUI)
</syntaxhighlight>
</syntaxhighlight>


Line 83: Line 127:
     // Create and register the XML GUI.
     // Create and register the XML GUI.
     ////////////////////////////////////////////////////////////////////
     ////////////////////////////////////////////////////////////////////
#if 0
#ifndef DISABLE_PUI
     globals->add_subsystem("gui", new NewGUI, SGSubsystemMgr::INIT);
     globals->add_subsystem("gui", new NewGUI, SGSubsystemMgr::INIT);
#endif
#endif
Line 124: Line 168:
     { "hires-screen-capture", do_hires_screen_capture },
     { "hires-screen-capture", do_hires_screen_capture },
     { "tile-cache-reload", do_tile_cache_reload },
     { "tile-cache-reload", do_tile_cache_reload },
#if 0
#ifndef DISABLE_PUI
     { "dialog-new", do_dialog_new },
     { "dialog-new", do_dialog_new },
     { "dialog-show", do_dialog_show },
     { "dialog-show", do_dialog_show },
Line 184: Line 228:
The renderer is basically just referencing the PUI camera so that the GUI can be drawn, whereas canvas_mgr merely acccesses the PUI subsystem to be able to render canvas based textures. In other words, both references can be easily removed for testing purposes.
The renderer is basically just referencing the PUI camera so that the GUI can be drawn, whereas canvas_mgr merely acccesses the PUI subsystem to be able to render canvas based textures. In other words, both references can be easily removed for testing purposes.


== Affected Features / Sources ==
== Affected features and sources ==


{| class="wikitable"
{| class="wikitable"
Line 190: Line 234:
! Feature !! Directory !! Notes !! Status  
! Feature !! Directory !! Notes !! Status  
|-
|-
| [[PUI]] || $FG_SRC/GUI || trivial to disable, can be replaced via [[Phi]] || {{Pending}}
| [[PUI]] || $FG_SRC/GUI || trivial to disable, can be replaced via [[Phi]]. Is in the process of being replaced by an optional [[QtQuick use in FlightGear|QtQuick runtime]]  || {{Progressbar|70}}
|-
| [[Post_FlightGear_2020.2_LTS_changes#2D_Panels|2D Panels]] || $FG_SRC/Cockpit || see {{Merge-request|project=flightgear|id=217|text=Populate /canvas property tree for the 2D panel}}
 
There's also a [https://sourceforge.net/p/flightgear/flightgear/ci/topics/panel-hacking/~/tree/ branch] (which is a few of years old) contains WIP on implementing 2D panels as canvas. It uses the same loading / updating logic in C++ (for 100% compatibility), but rather than building custom rendering, it builds up a Canvas element hierarchy in C++.<ref>https://sourceforge.net/p/flightgear/mailman/message/36980724/</ref><ref>https://sourceforge.net/p/flightgear/mailman/message/37042351/</ref>
|| {{Progressbar|80}}
|-
|-
| [[FGPanel|2D Panels]] || $FG_SRC/Cockpit || legacy 2D panels (could use [[Canvas]]), actually as of 04/2020, there is now a dedicated OpenGL ES based version of the standalone fgpanel port available which could be backported (mainly hard-coded shader updates) <ref>https://sourceforge.net/p/flightgear/flightgear/ci/dc6fb535962eff8214bc5b1708886178cceb482e/log/?path=/utils/fgpanel</ref> || {{Pending}}
| [[Canvas Path]] (Shiva) || $SG_SRC/canvas || needs some thinking, probably native OpenVG on RPi <ref>https://github.com/ajstarks/openvg</ref> <ref>http://mindchunk.blogspot.com/2012/09/openvg-on-raspberry-pi.html</ref> or an OpenGL based implementation like nanovg <ref>https://www.raspberrypi.org/forums/viewtopic.php?t=247586#p1516785</ref> [https://sourceforge.net/p/flightgear/mailman/search/?q=Skia+AND+Canvas&mail_list=all James mentioned Skia repeatedly], but that's only an option for Qt-enabled builds obviously.|| {{Pending}}
|-
|-
| [[Canvas Path]] (Shiva) || $SG_SRC/canvas || needs some thinking, probably native OpenVG on RPi <ref>https://github.com/ajstarks/openvg</ref> <ref>http://mindchunk.blogspot.com/2012/09/openvg-on-raspberry-pi.html</ref> or an OpenGL based implementation like nanovg <ref>https://www.raspberrypi.org/forums/viewtopic.php?t=247586#p1516785</ref> || {{Pending}}
| [[Effects]] || $FG_ROOT/Effects || not important for the time being, will include [[Shader]]s and probably involve a custom [[Compositor]] pipeline || {{Pending}}
|-
|-
| [[Effects]] || $FG_ROOT/Effects || not important for the time being, will include [[Shader]] and probably involve a custom [[Compositor]] pipeline || {{Pending}}
| [[OSGText Issues]] || ... || If you have a chance to replace OSGText by canvas - do so. OSGText (even with the custom OSG repository) does not play nice with our Effects and Shaders framework and will continue to have issues for all eternity.<ref>https://forum.flightgear.org/viewtopic.php?f=37&t=36287&p=353351&#p353351</ref><ref>https://sourceforge.net/p/flightgear/codetickets/2199/#f702</ref> <ref>https://sourceforge.net/p/flightgear/mailman/message/37042476/</ref>|| {{Progressbar|10}}
|}


In addition, [[SimGear]] needs special treatment, too <ref>https://sourceforge.net/p/flightgear/mailman/message/36978098/</ref>.
Using the same heuristics as before (based on grepping [[$SG_SRC]] for <code>glBegin</code> and <code>glEnable</code>, we end up with the following sources (ignoring [[Canvas Path ]]/shivavg, which is dealt with already above):
<syntaxhighlight>
simgear/scene/tgdb/SGVasiDrawable.cxx:42:    glBegin(GL_POINTS);
simgear/scene/model/shadanim.cxx
</syntaxhighlight>
{| class="wikitable"
|-
! Feature !! Directory !! Notes !! Status
|-
|}
|}


Line 203: Line 266:
{{Wikipedia|OpenGL ES}}
{{Wikipedia|OpenGL ES}}


=== Vertex Buffer Objects ===
=== Vertex buffer objects ===
{{See also|Uniform Buffer Objects}}
 
=== Canvas.Path (OpenVG) ===
=== Canvas.Path (OpenVG) ===
Will likely need to replace shiva vg with an OpenGL 2.0 based implementation like nanovg.
Will likely need to replace shiva vg with an OpenGL 2.0 based implementation like nanovg <ref>https://github.com/memononen/nanovg</ref>.


== Forum topics ==
== Community talks ==
* [https://forum.flightgear.org/viewtopic.php?f=45&t=36922&p=364937#p364937 Download_and_compile.sh & Raspberry Pi4]
* [https://forum.flightgear.org/viewtopic.php?f=45&t=36922&p=364937#p364937 Download_and_compile.sh & Raspberry Pi4]
== See also ==
* [https://sourceforge.net/p/flightgear/mailman/search/?q=%22opengl+es%22 OpenGL ES (devel list)]
 
== References ==
{{Appendix}}
 
== Related content ==
* [[FlightGear Headless]]
* [[FlightGear Headless]]
* [[Howto:Optimizing FlightGear for mobile devices]]
* [[Howto:Optimizing FlightGear for mobile devices]]
Line 216: Line 286:
* [[FlightGear and old Hardware]]
* [[FlightGear and old Hardware]]
* [[Compositor]]
* [[Compositor]]
== References ==
{{Appendix}}
Retrieved from "https://wiki.flightgear.org/Special:MobileDiff/122984...129478"