View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0004425||The Dark Mod||Graphics||public||24.11.2016 10:09||10.07.2018 21:34|
|Priority||normal||Severity||normal||Reproducibility||have not tried|
|Target Version||TDM 2.06||Fixed in Version||TDM 2.06|
|Summary||0004425: Framebuffer objects for color, depth, stencil|
|Description||Making use of framebuffer objects could bring numerous benefits, such as applying graphics settings without recreating window, virtual screen resolutions, access of depth buffer w/o copy to texture, etc.|
|Tags||No tags attached.|
|parent of||0004708||resolved||duzenko||Water: big square blocks on screen when FBO is on|
|parent of||0004669||resolved||duzenko||Bloom \ Post-Process does not render unless you toggle r_useFBO|
|parent of||0004860||resolved||duzenko||Soft particles not visible with AA on|
|parent of||0004697||resolved||duzenko||Some console commands don't work with GLSL 1 and useFBO 0/1|
|parent of||0004834||resolved||duzenko||Dynamic Internal Images do not scale to match r_fboResolution Results in HOM artifact|
|parent of||0004850||resolved||cabalistic||Implement antialiasing compatible with FBO|
|related to||0004671||resolved||duzenko||HeatHaze behaving wrongly|
|related to||0004714||resolved||duzenko||Water surfaces broken in Volta2|
|related to||0004693||resolved||stgatilov||Soft shadows: some squares of shadow flicker randomly|
|related to||0004684||resolved||stgatilov||Graphical Artifacts in Warp Materials|
|child of||0003684||new||Investigate GPL Renderer Improvements|
|Probably should also mention 16-bit color and depth buffers too.|
Virtual resolution works (no shadows so far - need to add stencil buffer next).
r_useFbo 1 - use fbo, 0 - old style
r_virtualResoltion 1 = default, 2 - twice width & height, 0.5 - half, etc
|Added stencil, forced 16 bit color and depth for testing.|
|If vendor is nvidia, use a single d24s8 buffer for depth and stencil|
This works now but I presume the posterization effect is due to the forced 16-bit color?
I didn't see any drastic slowdown when going to FBO with Lightgem processing enabled.
Yes, due to the 16-bit color, which is for testing purpose.
Puzzling: no posterization on Intel.
NVidia does not support separate stencil which is the bigger (?) part of fps gain on Intel.
32 bit color & 24+8 bit depth/stencil FBO must be the same speed or slower than the "normal" mode.
Curious: glRenderbufferStorage specification only allows one of these
But NVidia wants GL_DEPTH24_STENCIL8_EXT instead of GL_STENCIL_INDEX8.
What about this particular view? Low fps with lightgem here for me: https://s17.postimg.org/ltzc54qf3/Untitled.png
Apparently nvidia driver does a software fallback if glReadPixels format is different from framebuffer. This is faster with 16 bit fbo:
qglReadPixels(rc->x, rc->y, rc->width, rc->height, GL_RGB, GL_UNSIGNED_SHORT_5_5_5_1, 0);
Cvars: r_fboResolution, r_fboColorBits
Apparently Intel ignores the color bits option and always renders to 32bit texture.
Fbo fullscreen: always use desktop resolution for fast Alt-Enter.
The 32-bit buffer looks great.
In the spot you mentioned:
r_useFB0 = 0 ... 48FPS
r_useFBO = 1 ... 63FPS
I consistently get a 2 to 3 FPS boost when avg is below 40 and it goes to higher percentages when above. Looks ready for production to me. :)
I have this issue with FPS: if TDM starts with r_useFB0 1 and then switch to r_useFB0 0, FPS is lower than if TDM starts with r_useFB0 0.
I.e. an existing FBO somehow makes rendering slower in default framebuffer.
It's just that it would be unreasonable to expect 32+24+8-bit fbo to perform any better than the default framebuffer. Plus there is the additional step to copy the fbo content to the screen.
Puzzling: blitting framebuffers with different sizes fails in TDM even though demo runs fine (http://www.songho.ca/opengl/gl_fbo.html)
|Hmm. Fogged surfaces are acting strange with r_useFBO 1 now. Fills in with white pixels and looks like motion blur.|
|Example of a fogged surface is ... water?|
Hmm. On further testing, it seems to be isolated to No Honor Among Thieves mission 3.
1) Set r_useFBO = 1
2) Install NHAT
3) Open the console and invoke "map forest"
4) Look at the sky and distant woods
5) Set r_useFBO = 0
6) The visuals are cured
You mean the skybox is blurry?
Does g_enablePortalSky 1 fix it for you?
What I think happens here is
1 - color buffer not cleared properly by me when fbo is used
2 - this particular skybox has no opaque material and blends with framebuffer pixels (which is a valid fillrate optimization)
|Skybox blurring addressed in svn rev 6712|
All fixed for me.
I haven't done a big dive into your changes.
Are you using FBO for "dynamic internal images" like _currentRender and _scratch?
If not, there may be some additional wins for the Postprocess shaders with this change.
Svn rev 6713: use currentDepthImage as fbo depth attachment
Where can I see use of _currentRender and _scratch (for what they are used, where in which mission)?
_currentRender is used for all transparent shaders. Glass, Water, etc.
It's also used for our Postprocess (Bloom) setting. Looking in PlayerView.cpp (idPlayerView::dnPostProcessManager) it looks like there's a few more candidates: _bloomImage, _cookedMath.
_scratch is used for mirrors and some water shaders as I recall. There may be other internal uses for it. I am not as familiar with that one.
A good mission to test? NHAT 2: A Night Out On the Town. (anoott.map). The transparent water should have a pretty large impact on the shore scene.
6716 - attached the currentRender texture to FBO
You can see some feedback loop jittering as a result.
Where can I test scratch/reflection?
The mirror in Crystal Grave is a good place to look at _scratch.
Hmm. Since the currentRender is really just a snapshot of the framebuffer, I wonder if just connecting it to the main framebuffer FBO would work better?
|Not sure what you mean by connecting?|
|Rather than make _currentRender it's own FBO, just read from the main framebuffer. Unless you're already doing that?|
Actually right now there is only one fbo that does all the rendering.
Main framebuffer only used to display the fbo content.
Hmm. Maybe lightgem timing shenanigans akin to issue 4420 are at play here?
Not sure what else would cause the jitter.
|I'm almost sure that this is a manifestation of so called feedback loop, i.e. the same image is being used as source and destination of the water shader.|
|Ah yes. _currentRender needs to be a still capture of a moment prior to the current render pass so it would need it's own FBO, PBO, or memory object to preserve it's past-tense nature.|
I think the same thing applies to Depth Buffer. I reverted the currentRender changes and noticed that the water shaders have line artifacts. The "current" images must capture a static state in the middle of the render passes for a scene and cannot dynamically update to reflect changes made after the snapshot. Thus currentRender and currentDepth would need their own FBO or PBO(etc).
It would appear that after all it might not be feedback loop.
Tried many approaches today, ended up with simple texture copy and it's still there.
Note how r_fbodebug 1 shows the currentRender.
Added options for sharing color/depth textures as input/output of postprocessing. It should fix the recent rendering artifacts.
Also, 2d drawing uses window resolution now.
One thing I'm curious about is linear texture filter when copying from FBO to default framebuffer. I would expect texels to interpolate but on my Intel it looks like this: https://s28.postimg.org/vmkqwe0nh/Untitled.png
I wonder if it's different on nVidia/AMD.
Hmm... on second thought maybe that's how interpolate texels actually look like
Something has gone wrong. Now r_useFBO = 1 is about half or less the FPS of r_useFBO = 0. Perhaps the r_fboShared cvars are being checked too often?
Also, r_useFBO 1 with postprocessing enabled produces a very dark screen. This is similar to what you see when you enable image_downsize so it seems that somehow the currentRender image is getting stretched?
|Are both r_fboShared 0 for you? What happens when either of them is 1?|
Setting r_fboSharedColor = 1 turns the screen black if postprocessing is enabled.
Setting r_fboSharedDepth = 1 improves performance a bit but the line artifacts return in water (etc).
Regardless of whether both or only 1 being set, performance is still less than rev 6712 or r_useFBO = 0.
Fixed the slowdown using GL_DEPTH_COMPONENT instead of GL_DEPTH_COMPONENT16.
By postproceesing you mean r_skippostprocess or r_postprocess?
Speed has improved with r_postprocess = 0.
r_postprocess = 1, however is about 2x worse with r_useFBO.
r_postprocess 1 has less artifacts but it's still not at parity with the
r_useFBO 0 version.
Compass toggle -> black screen
Related to the earlier-reported screen recording blackout?
Hmm, now enabling r_postprocess while r_useFBO = 0 causes the screen to shrink.
Artifacts still happen when r_postprocess is enabled with r_useFBO = 1 but they have been reduced.
|Hopefully this fixes it: svn rev 6736|
|Fixed depth in non-shared mode|
|Enabling the Compass inventory item causes the screen to go black with r_useFBO = 1 (enabled)|
As a minor comment, I have added fallback to EXT extensions if ARB version of framebuffer is not available.
However, currently it is committed only to linuxbuild_2017_06 branch *(revision 6956). I hope it would get into trunk naturally when linux build catches up with trunk.
UPDATE: the changes are already in trunk (for quite a long time actually).
The core implementation appears to be done.
Any reason why this cannot be closed and new bugs be created for additional features?
FBO exists in TDM 2.06.
Further changes can be logged as new bugs or enhancements.
|Current version FBO is slow on AMD. Needs investigating.|
|24.11.2016 10:09||duzenko||New Issue|
|24.11.2016 10:09||duzenko||Status||new => assigned|
|24.11.2016 10:09||duzenko||Assigned To||=> duzenko|
|24.11.2016 10:15||duzenko||Note Added: 0008546|
|24.11.2016 16:04||duzenko||Note Added: 0008547|
|24.11.2016 18:23||duzenko||Note Added: 0008548|
|29.11.2016 16:59||duzenko||Note Added: 0008564|
|29.11.2016 20:35||nbohr1more||Product Version||=> SVN|
|29.11.2016 20:35||nbohr1more||Target Version||=> TDM 2.06|
|30.11.2016 02:29||nbohr1more||Note Added: 0008566|
|30.11.2016 08:58||duzenko||Note Added: 0008570|
|30.11.2016 09:00||duzenko||Note Edited: 0008570||View Revisions|
|30.11.2016 09:13||duzenko||Note Edited: 0008570||View Revisions|
|30.11.2016 09:20||duzenko||Note Edited: 0008570||View Revisions|
|30.11.2016 14:06||duzenko||Note Edited: 0008570||View Revisions|
|30.11.2016 20:33||duzenko||Note Added: 0008571|
|30.11.2016 20:33||duzenko||Note Edited: 0008571||View Revisions|
|01.12.2016 03:37||nbohr1more||Note Added: 0008574|
|01.12.2016 04:15||nbohr1more||Note Edited: 0008574||View Revisions|
|01.12.2016 07:13||duzenko||Note Added: 0008576|
|01.12.2016 09:34||duzenko||Note Edited: 0008576||View Revisions|
|01.12.2016 15:43||duzenko||Note Added: 0008579|
|01.12.2016 15:44||duzenko||Note Edited: 0008579||View Revisions|
|01.12.2016 21:06||nbohr1more||Relationship added||related to 0003684|
|02.12.2016 02:24||nbohr1more||Note Added: 0008582|
|02.12.2016 08:44||duzenko||Note Added: 0008583|
|02.12.2016 16:48||nbohr1more||Note Added: 0008584|
|02.12.2016 18:21||duzenko||Note Added: 0008585|
|02.12.2016 18:35||duzenko||Note Edited: 0008585||View Revisions|
|02.12.2016 18:38||duzenko||Note Edited: 0008585||View Revisions|
|02.12.2016 19:58||duzenko||Note Edited: 0008585||View Revisions|
|03.12.2016 20:02||duzenko||Note Added: 0008587|
|04.12.2016 04:03||nbohr1more||Note Added: 0008588|
|04.12.2016 08:47||duzenko||Note Added: 0008589|
|04.12.2016 14:32||nbohr1more||Note Added: 0008590|
|04.12.2016 19:07||duzenko||Note Added: 0008592|
|04.12.2016 19:18||nbohr1more||Note Added: 0008593|
|04.12.2016 20:01||duzenko||Note Added: 0008594|
|04.12.2016 20:02||nbohr1more||Note Added: 0008595|
|04.12.2016 20:04||duzenko||Note Added: 0008596|
|04.12.2016 20:16||nbohr1more||Note Added: 0008597|
|04.12.2016 20:19||duzenko||Note Added: 0008598|
|04.12.2016 20:24||nbohr1more||Note Added: 0008599|
|05.12.2016 13:32||nbohr1more||Note Added: 0008601|
|05.12.2016 13:32||nbohr1more||Note Edited: 0008601||View Revisions|
|05.12.2016 21:29||duzenko||Note Added: 0008607|
|11.12.2016 11:32||duzenko||Note Added: 0008611|
|11.12.2016 11:32||duzenko||Note Edited: 0008611||View Revisions|
|11.12.2016 11:34||duzenko||Note Edited: 0008611||View Revisions|
|12.12.2016 04:23||nbohr1more||Note Added: 0008613|
|12.12.2016 14:52||duzenko||Note Added: 0008614|
|12.12.2016 15:17||nbohr1more||Note Added: 0008615|
|14.12.2016 12:44||duzenko||Note Added: 0008616|
|15.12.2016 02:30||nbohr1more||Note Added: 0008617|
|19.12.2016 09:20||duzenko||Note Added: 0008622|
|29.12.2016 04:48||nbohr1more||Note Added: 0008665|
|29.12.2016 10:08||duzenko||Note Added: 0008674|
|21.05.2017 11:08||duzenko||Note Added: 0008871|
|22.05.2017 03:04||nbohr1more||Note Added: 0008874|
|22.05.2017 13:45||duzenko||Note Added: 0008875|
|23.06.2017 17:04||stgatilov||Note Added: 0008924|
|14.09.2017 18:20||nbohr1more||Status||assigned => feedback|
|14.09.2017 18:21||nbohr1more||Note Added: 0009240|
|15.09.2017 16:53||stgatilov||Note Edited: 0008924||View Revisions|
|17.09.2017 21:48||nbohr1more||Status||feedback => resolved|
|17.09.2017 21:48||nbohr1more||Fixed in Version||=> TDM 2.06|
|17.09.2017 21:48||nbohr1more||Note Added: 0009283|
|16.11.2017 20:02||nbohr1more||Relationship added||related to 0004671|
|24.11.2017 13:08||duzenko||Note Added: 0009688|
|26.12.2017 19:00||nbohr1more||Relationship added||child of 0004669|
|26.12.2017 19:00||nbohr1more||Relationship added||related to 0004714|
|26.12.2017 19:00||nbohr1more||Relationship added||parent of 0004708|
|26.12.2017 19:01||nbohr1more||Relationship deleted||child of 0004669|
|26.12.2017 19:01||nbohr1more||Relationship added||parent of 0004669|
|26.12.2017 19:03||nbohr1more||Relationship added||related to 0004693|
|26.12.2017 19:09||nbohr1more||Relationship added||related to 0004684|
|26.12.2017 19:11||nbohr1more||Relationship deleted||related to 0003684|
|26.12.2017 19:11||nbohr1more||Relationship added||child of 0003684|
|10.07.2018 21:30||nbohr1more||Relationship added||parent of 0004860|
|10.07.2018 21:30||nbohr1more||Relationship added||parent of 0004697|
|10.07.2018 21:34||nbohr1more||Relationship added||parent of 0004834|
|10.07.2018 21:34||nbohr1more||Relationship added||parent of 0004850|