Board index FlightGear Development

ALS vs. Rembrandt (forward vs. deferred rendering)

FlightGear is opensource, so you can be the developer. In the need for help on anything? We are here to help you.
Forum rules
Core development is discussed on the official FlightGear-Devel development mailing list.

Bugs can be reported in the bug tracker.

Re: ALS vs. Rembrandt (forward vs. deferred rendering)

Postby Hooray » Sat Oct 10, 2015 10:04 am

So with your way of thinking we end up with a simulator good for the computers that are old or low-end. But without the benefits of computer evolution. Why is this a good approach?


Once you look at the facts, the opposite is currently the case - indeed, FlightGear, with its current default settings, will often segfault for people with old hardware, simply because those defaults don't scale too well, i.e. will use unsupported features. And that has nothing to do with entirely optional features like ALS and/or Rembrandt.

This has much more to do with the monolithic nature of the FlightGear process, and its extremely monolithic initialization process, with the majority of subsystems being added unconditionally, with the defaults often not working too well for much older hardware.

So on the one hand we have people like you complaining that the FG default settings look "archaic" and are simply too basic for modern hardware, while we have other users, who frankly are no longer able to run FG without tons of customizing first.
Ironically, however, scaling up is much easier for people (and typically even exposed via the UI) than doing the opposite, for which you need to be really familiar with FG internals (just look at the minimal startup profile on the wiki).

What people have been contemplating to explore/do for a while is implementing a framework for doing dynamic "feature-scaling", i.e. where a safe subset of FlightGear would be booted (as per the minimal startup profile) and the rest (effects, shaders, ALS or Rembrandt, weather systems, visibility etc) would be dynamically determined after this subset of FG is up and running - e.g. using a PID controller that is hooked up to the corresponding PagedLOD (OSG machinery).

Once you take a look at the wiki, you will find that a number of core developers have been discussing the possibilities of dynamical feature scaling, including people like Stuart, James and Rebecca

But for that to happen, it would first of all make sense to implement the required hooks to expose process internals to the property tree, so that these can be queries, but also adjusted, at run-time.

Thus, testing, benchmarking and profiling really is the first step here:
http://wiki.flightgear.org/FlightGear_Benchmark
http://wiki.flightgear.org/Testing

The next step would be feature-scaling: http://wiki.flightgear.org/Feature_Scaling

In the long term, this would also improve support for older hardware, but also for mobile platforms:
http://wiki.flightgear.org/FlightGear_and_old_Hardware
http://wiki.flightgear.org/Howto:Optimi ... le_devices

In reality, proper profiling/regression testing may not even entail having a graphics window, to see where the non-GPU related issues are coming from, which is why James has been pursuing a headless mode: http://wiki.flightgear.org/FlightGear_Headless

In other words, people are aware of the real problem here and have several solutions/approaches in mind.
But if you really want to help with that, you should also be prepared to get involved with testing - which doesn't necessarily involve patching/building FG from source, but just donating your own time to run several tests and report back with the results here.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: ALS vs. Rembrandt (forward vs. deferred rendering)

Postby Thorsten » Sat Oct 10, 2015 10:33 am

I would not say that a benchmark comparing Rembrandt with non-Rembrandt is necessarily meaningless


Which is why I didn't say 'a' benchmark but 'the' benchmark (referring to the mentioned one). But since this thread seems to go the usual path and I have better things to do with my time, I'll leave it here. What do I know anyway?
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: ALS vs. Rembrandt (forward vs. deferred rendering)

Postby hamzaalloush » Sat Oct 10, 2015 10:47 am

The usual path of what? i even mentioned to customize Advanced Weather to make a prettier scene, which is your code but looks like I'm on my own. Anyway this thread will continue .
hamzaalloush
 
Posts: 631
Joined: Sat Oct 26, 2013 10:31 am
OS: Windows 10

Re: ALS vs. Rembrandt (forward vs. deferred rendering)

Postby Thorsten » Sat Oct 10, 2015 12:04 pm

The usual path of what?


The usual path of there being no shortage of people who know how rendering 'really' works and eager to tell me.

See, I've spent years with ALS. There are weeks in which I have done nothing else but benchmarking what the precise effect of adding a subroutine really is. I have plenty of first-hand experience seeing how performance was affected by the individual changes, where the performance impact was most drastic, etc.

I don't claim to be a technical expert in GLSL - if I have learned one thing, that it's complicated, It has its idiosyncrasies, if-statements don't work as we're used to for instance, there's things you can only do with difficulties conditionally, for instance referencing a texture. It has its interaction with hardware - what's blazingly fast on my one GPU sucks on my older one. I've learned how the limitations can shift as more detailed planes entered the fray, or the hires scenery arrived.

But there's now years of hands-on experience behind what I see how it all works in the FG context.

I've spent days deriving light scattering equations, checking how good fast approximations to them are, taking picture series of sunrises and sunsets with noted exposure times to that I can later convert them into good color and intensity values, reading through some literature on how perception in the eye works to get a handle on how to translate true intensities into screen values. That kind of thing.

I have learned enough of the C++ side of OpenGL/OSG to come up with my own features - like the tree shadows.

Yet I keep meeting people who tell me how it should be done. Often based on things like

* this 3d game [insert name here] also manages

Well, half of the time, the context and challenge is completely different. In a surface-walking 3d setup, you can easily do agressive scene culling, which you never can perform when you see the scene from the air. For a view from the ground, you never need to render a 3d structure of clouds because you don't reach them. Etc. The other half of the time, it is conveniently ignored that in FG, we start with a given context. If I could design a scheme to render terrain from scratch, it would be different from what we have now. It would not run on old hardware and be much better on new hardware. However, the terrain is what we have, and there's good reasons except rendering to keep it that way - so we can't do everything that's theoretically possible.

* but in that blog it says

So, if I would write a blog about rendering, what I say would be gospel? I've found valuable information in blogs on rendering just as much as things for which I have derived a better solution on my own. If we're talking about light for instance, I have my set of measurements and my set of equations - that's science, to be countered by data and other equations, not by 'a blog says so' and not even by 'rendering guru xy says so'.

* but X has said the problem really is

How does X know? I know what I know by having tested. A lot. Under very different circumstances. In situ, not running a shader in isolation in a development environment. I'm not interested at all in what X said, I'm interested in X's test data. Numbers. Things like 'if I remove this block of code, I get a 5% increase in framerate'. Because that's the accuracy to which I know the ALS routines.

There's no shortage of people who can talk for pages of how they would do everything better, or how everything would be better if everyone would listen to them. Here's the thing that should give you pause: Where's the code? Where's the blazingly fast spectacular effect which achieves everything ALS does, just much faster and better? If you think it is no problem cramming 1500 lines of fragment shader instructions into an already fragment-limited framework, do it! Don't second-guess me when I say I think it can't be done based on nothing but your gut feeling that it should be somehow possible.

See, I respect results, not names and claims. If someone tells me 'modify this algorithm like that, and it'll be 30% faster' and he turns out to be right, I'll pull my hat to this person.Because he or she obviously understood something I didn't. If someone tells me 'you have no idea what you're doing, and it should all be done differently' or 'X should absolutely be possible' that's not something that impresses me much.

Now you know the usual path of the rendering discussions.
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: ALS vs. Rembrandt (forward vs. deferred rendering)

Postby hamzaalloush » Sat Oct 10, 2015 2:39 pm

Thorsten wrote in Sat Oct 10, 2015 12:04 pm:
The usual path of there being no shortage of people who know how rendering 'really' works and eager to tell me.


people want to participate in discussions, that's it, it's another thing to have somebody come out of the wood work and tell me X-Plane or FSX is better talking with the developer and judging work without understanding can be wasting time that developer can use for something else.

Thorsten wrote in Sat Oct 10, 2015 12:04 pm:See, I've spent years with ALS. There are weeks in which I have done nothing else but benchmarking what the precise effect of adding a subroutine really is. I have plenty of first-hand experience seeing how performance was affected by the individual changes, where the performance impact was most drastic, etc.


Which is why we are saying it's important to come up with standard and small scale test-case for evaluating purposes, or at least pass these findings to other people.

Thorsten wrote in Sat Oct 10, 2015 12:04 pm:I don't claim to be a technical expert in GLSL - if I have learned one thing, that it's complicated, It has its idiosyncrasies, if-statements don't work as we're used to for instance, there's things you can only do with difficulties conditionally, for instance referencing a texture. It has its interaction with hardware - what's blazingly fast on my one GPU sucks on my older one. I've learned how the limitations can shift as more detailed planes entered the fray, or the hires scenery arrived.


Let's put some discussion out then, so we can actually learn something instead of this becoming an argument(i dont want it to), so as i understand, texels are attached to two-element vectors for a 3d object rendered in world space, whenever you want to reference a texture you would have to hold the three-element vectors for that object in the scene and do UV_Mapping upon it, which is done after a camera pass, so yeah i guess that claim is valid. (this is my talking, just searching google, not some X :) ).

there is also this osg::Drawable in between, right?

Thorsten wrote in Sat Oct 10, 2015 12:04 pm:But there's now years of hands-on experience behind what I see how it all works in the FG context.

I've spent days deriving light scattering equations, checking how good fast approximations to them are, taking picture series of sunrises and sunsets with noted exposure times to that I can later convert them into good color and intensity values, reading through some literature on how perception in the eye works to get a handle on how to translate true intensities into screen values. That kind of thing.

I have learned enough of the C++ side of OpenGL/OSG to come up with my own features - like the tree shadows.


so you know your physics, that's great, and OSG already has a forest example with double-quad tree classes, so you happen to expose the properties for the physics involved to create co-planar shadows using C++, that's good, no one said anything against it.

osg::Geometry* ForestTechniqueManager::createOrthogonalQuads



Thorsten wrote in Sat Oct 10, 2015 12:04 pm:Well, half of the time, the context and challenge is completely different. In a surface-walking 3d setup, you can easily do agressive scene culling, which you never can perform when you see the scene from the air. For a view from the ground, you never need to render a 3d structure of clouds because you don't reach them. Etc. The other half of the time, it is conveniently ignored that in FG, we start with a given context. If I could design a scheme to render terrain from scratch, it would be different from what we have now. It would not run on old hardware and be much better on new hardware. However, the terrain is what we have, and there's good reasons except rendering to keep it that way - so we can't do everything that's theoretically possible.


i agree, we all play by the rules, since it's why not fair comparing with other sims directly, but it also won't hurt to do a visual test of our final product, even if it's "useless" in this context. :)

Thorsten wrote in Sat Oct 10, 2015 12:04 pm:
See, I respect results, not names and claims. If someone tells me 'modify this algorithm like that, and it'll be 30% faster' and he turns out to be right, I'll pull my hat to this person.Because he or she obviously understood something I didn't. If someone tells me 'you have no idea what you're doing, and it should all be done differently' or 'X should absolutely be possible' that's not something that impresses me much.

Now you know the usual path of the rendering discussions.


i get what you are saying, I just find quite sad that people who have actually written code for FG can't participate in such discussion. and even if 'X' haven't actually written any concerning graphics, and doesn't hold 'phd'(as refrenced in the wiki), doesn't make me not helpful.
hamzaalloush
 
Posts: 631
Joined: Sat Oct 26, 2013 10:31 am
OS: Windows 10

Re: ALS vs. Rembrandt (forward vs. deferred rendering)

Postby Johan G » Sat Oct 10, 2015 9:48 pm

@Hamza and others:

I think Thorsten's arguments above boils down the simple fact that it is one thing to discuss a subject with someone who respects the man hours put into development, who is willing to give things a try, and I think most importantly, is someone who would be willing to challenge his own knowledge on a subject. It is something completely else to discuss a subject with someone who often simply does not understand that he does not understand a subject, who often have cherry-picked the answers and sticks to them, and who usually refuse explanations of why they most probably is not applicable in the context of a subject.

Unfortunately it would often at least seem like the last group is in majority, or possibly that the first group is in minority,* which kind of complicates the prospects for a meaningful and constructive discussion.

This is not at all specific only to Thorsten and his work, but is a general problem with the forum (and most other forms of social interaction).** This is also the reason why some really good aircraft and other developers stopped showing up on the forum in the past and why probably most of the core developers never would set foot here.

* Though I should mention that it consider there to be a (sometimes wide) gray scale between the extremes.
** See also this slightly related post of mine, and most of that thread for that matter.
Low-level flying — It's all fun and games till someone looses an engine. (Paraphrased from a YouTube video)
Improving the Dassault Mirage F1 (Wiki, Forum, GitLab. Work in slow progress)
Some YouTube videos
Johan G
Moderator
 
Posts: 6629
Joined: Fri Aug 06, 2010 6:33 pm
Location: Sweden
Callsign: SE-JG
IRC name: Johan_G
Version: 2020.3.4
OS: Windows 10, 64 bit

Re: ALS vs. Rembrandt (forward vs. deferred rendering)

Postby hamzaalloush » Sun Oct 11, 2015 12:44 am

hmm i wonder how we came to this point, please delete my posts and Thorsten's since he doesn't want to participate(right before/after his "usual path" post, take your choice), let's keep this on topic because i don't want to create another one, frankly i dont care about all this talk.
hamzaalloush
 
Posts: 631
Joined: Sat Oct 26, 2013 10:31 am
OS: Windows 10

Re: ALS vs. Rembrandt (forward vs. deferred rendering)

Postby Johan G » Sun Oct 11, 2015 12:50 am

Edit: You beat me to it. :)

@Hamsa:
I should probably clarify that I am not saying there is a problem with your posts. I am just saying that I think I see where Thorsten's experiences and expectations stem from (admittedly risking putting words in his mouth).

Many people arguing about what should be done or not do not care for making as much comparative tests as you seem to have done so far (in fact I feel that most that have criticized things on the graphics side do pretty much no comparative tests between FlightGear settings at all... :| )

I think you are on the right track, but that it seems you probably could refine your tests with some feedback from Hooray and Thorsten. While your testing may not impress them all to much currently, you are doing something similar to what Hooray have argued for for years.

Also, when Thorsten started working on what later became advanced weather (back then local weather), he and Hooray at least initially had very different ideas of what was possible to achieve and how to test things for getting a reasonably optimal feature vs. performance balance. Not agreeing and questioning each other can be a great way to learn collectively, albeit it is frustrating at times.
Low-level flying — It's all fun and games till someone looses an engine. (Paraphrased from a YouTube video)
Improving the Dassault Mirage F1 (Wiki, Forum, GitLab. Work in slow progress)
Some YouTube videos
Johan G
Moderator
 
Posts: 6629
Joined: Fri Aug 06, 2010 6:33 pm
Location: Sweden
Callsign: SE-JG
IRC name: Johan_G
Version: 2020.3.4
OS: Windows 10, 64 bit

Re: ALS vs. Rembrandt (forward vs. deferred rendering)

Postby hamzaalloush » Sun Oct 11, 2015 1:09 am

i might misunderstood you, but i became frustrated (probably because i saw him "rage quit" from this thread, from what appear to be no reason, and i frankly thought of this as disrespectful).
hamzaalloush
 
Posts: 631
Joined: Sat Oct 26, 2013 10:31 am
OS: Windows 10

Re: ALS vs. Rembrandt (forward vs. deferred rendering)

Postby Thorsten » Sun Oct 11, 2015 7:46 am

Just to stress this very clearly: I have no issue at all with making benchmark tests in general. I do however think that you should understand what it is you're testing. For rendering in particular, an (incomplete) list of issues is:

* relative loads of vertex / fragment / (geometry) shaders - screen resolution vs. scene visibility
* role of z-buffering and depth culling
* role of single vs. multiple camera passes
* role of single vs. multiple draws
* role of multi-sampling (anti-aliasing)

Just to give an example - an actual question we had to decide is whether to render trees once or twice. We had the option of using a simple pass rendering just the white outline of the tree into the scene to fill the z-buffer, thus saving to make a detailed computation of all invisible pixels covered by the tree, then in a second pass render all visible pixels with complete lighting, fogging and texturing. Or to just not do the first pass and also render invisible pixels.

Which of the two is faster depends on

a) view angle - if you're looking flat into a forest, you have plenty of trees in a row, i.e. not rendering obscured pixels is very efficient
b) tree coverage - if you have a dense forest, it covers almost all of the terrain
c) effort for the terrain - if you use a simple texture, not computing a terrain pixel doesn't gain you much, if you use detailed procedural terrain, it gains you a lot
d) vertex vs. fragment load - z-culling gains you only if the fragment shader limits speed, the additional pass unconditionally harms you if the bottleneck is the vertex shader
e) screen resolution - fragment shader load is proportional to the number of screen pixels, vertex shader load to the vertices inside the view frustrum
f) hardware - how much vertex vs. fragment processing capability does the card provide?
g) (...) (yet more unknown factors)

With such a question in mind and an idea of what the underlying factors are, you can proceed to test this scenario for various tree densities and terrain texturing schemes. It turned out that while on my computer I got on average a modest framerate increase (~5%) by doing a z-buffer filling path, several Mac systems seemed to lose out quite a bit, so all things considered the second pass was dropped and we now render all pixels which aren't culled in the single pass z-buffering (even invisible ones).

I describe that example because I think it illustrates what kind of benchmark I consider meaningful, what kind of knowledge you need to set it up and why I don't believe in testing shaders in isolation, aka a debug/devel framework (because of all the cross interactions with the rest of the scene in the FG context).
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: ALS vs. Rembrandt (forward vs. deferred rendering)

Postby hamzaalloush » Mon Oct 12, 2015 4:05 pm

Thank you for the detailed reply, i'll reflect on it, and i appreciate your help. When i feel informed enough i'll discuss further.
hamzaalloush
 
Posts: 631
Joined: Sat Oct 26, 2013 10:31 am
OS: Windows 10

Re: ALS vs. Rembrandt (forward vs. deferred rendering)

Postby Hooray » Wed Nov 11, 2015 9:27 am

Subject: ALS vs. Rembrandt (forward vs. deferred rendering)
Hooray wrote:Richard came up with the hypothesis that Rembrandt's performance issues may be in some way due to OSG-level issues involving camera/vsync-limits: http://wiki.flightgear.org/FlightGear_N ... _and_Vsync

Now, I don't know if you, or anybody else familiar with the effects/GLSL and OSG side of things, ever got around to looking at those findings, but it would definitely make sense to revisit this at some point, simply because Rembrandt may currently be the main component in FG using slaved cameras to this degree, but as you know, we do have other cameras/components making fairly extensive use of OSG cameras that should not necessarily be vsync limited, e.g. Canvas coming to mind - and the other thing being CompositeViewer support: http://wiki.flightgear.org/CompositeViewer_Support

Admittedly, I belong to the camp of those people (like Thorsten) with fairly powerful hardware, who are still not able to get very impressive frame rates - a few months ago, F-JJTH was politely suggesting that we simply would not understand how to configure our systems properly. From my standpoint, I never got sufficiently motivated to look at these issues beyond exchanging osg-stats with Thorsten.
But like Richard's tests have shown, it is indeed possible to come up with tests/benchmarks and come up with useful data, or even a working hypothesis.


FWIW, I played around with Canvas and supporting slaved cameras there, and was going to look at disabling vsync for certain offscreen textures (separate context) , and it turns out that some platforms supported by OSG did not support the corresponding OSG traits (startup flag to disable vsync), so that vsync may behave differently for people on Windows, depending on the version of OSG.

I don't have access to a Windows system - but if I remember correct, F-JJTH belonged to those using Linux, while others (Thorsten?) were using Rembrandt on Windows, which would match the observation that vsync may play a key role here.

The windows implementation got fixed in 2011 with this patch: https://github.com/openscenegraph/osg/c ... e3ab3973f4

According to the patch, you should see a corresponding log message once you set OSG_NOTIFY_LEVEL: http://trac.openscenegraph.org/projects ... sAndTricks
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Previous

Return to Development

Who is online

Users browsing this forum: No registered users and 12 guests