View Issue Details

IDProjectCategoryView StatusLast Update
0004425The Dark ModGraphicspublic10.07.2018 21:34
Reporterduzenko Assigned Toduzenko  
PrioritynormalSeveritynormalReproducibilityhave not tried
Status resolvedResolutionopen 
Product VersionSVN 
Target VersionTDM 2.06Fixed in VersionTDM 2.06 
Summary0004425: Framebuffer objects for color, depth, stencil
DescriptionMaking 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.
TagsNo tags attached.

Relationships

parent of 0004708 resolvedduzenko Water: big square blocks on screen when FBO is on 
parent of 0004669 resolvedduzenko Bloom \ Post-Process does not render unless you toggle r_useFBO 
parent of 0004860 resolvedduzenko Soft particles not visible with AA on 
parent of 0004697 resolvedduzenko Some console commands don't work with GLSL 1 and useFBO 0/1 
parent of 0004834 resolvedduzenko Dynamic Internal Images do not scale to match r_fboResolution Results in HOM artifact 
parent of 0004850 resolvedcabalistic Implement antialiasing compatible with FBO 
related to 0004671 resolvedduzenko HeatHaze behaving wrongly 
related to 0004714 resolvedduzenko Water surfaces broken in Volta2 
related to 0004693 resolvedstgatilov Soft shadows: some squares of shadow flicker randomly 
related to 0004684 resolvedstgatilov Graphical Artifacts in Warp Materials 
child of 0003684 new Investigate GPL Renderer Improvements 

Activities

duzenko

duzenko

24.11.2016 10:15

developer   ~0008546

Probably should also mention 16-bit color and depth buffers too.
duzenko

duzenko

24.11.2016 16:04

developer   ~0008547

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
duzenko

duzenko

24.11.2016 18:23

developer   ~0008548

Added stencil, forced 16 bit color and depth for testing.
duzenko

duzenko

29.11.2016 16:59

developer   ~0008564

If vendor is nvidia, use a single d24s8 buffer for depth and stencil
nbohr1more

nbohr1more

30.11.2016 02:29

developer   ~0008566

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.
duzenko

duzenko

30.11.2016 08:58

developer   ~0008570

Last edited: 30.11.2016 14:06

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
            GL_RGBA4,
            GL_RGB565,
            GL_RGB5_A1,
            GL_DEPTH_COMPONENT16, or
            GL_STENCIL_INDEX8.
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

duzenko

duzenko

30.11.2016 20:33

developer   ~0008571

Last edited: 30.11.2016 20:33

Apparently Intel ignores the color bits option and always renders to 32bit texture.
Fbo fullscreen: always use desktop resolution for fast Alt-Enter.

nbohr1more

nbohr1more

01.12.2016 03:37

developer   ~0008574

Last edited: 01.12.2016 04:15

WONDERFULL!!!

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. :)

duzenko

duzenko

01.12.2016 07:13

developer   ~0008576

Last edited: 01.12.2016 09:34

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.

duzenko

duzenko

01.12.2016 15:43

developer   ~0008579

Last edited: 01.12.2016 15:44

Puzzling: blitting framebuffers with different sizes fails in TDM even though demo runs fine (http://www.songho.ca/opengl/gl_fbo.html)

nbohr1more

nbohr1more

02.12.2016 02:24

developer   ~0008582

Hmm. Fogged surfaces are acting strange with r_useFBO 1 now. Fills in with white pixels and looks like motion blur.
duzenko

duzenko

02.12.2016 08:44

developer   ~0008583

Example of a fogged surface is ... water?
nbohr1more

nbohr1more

02.12.2016 16:48

developer   ~0008584

Hmm. On further testing, it seems to be isolated to No Honor Among Thieves mission 3.

Replication:

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
duzenko

duzenko

02.12.2016 18:21

developer   ~0008585

Last edited: 02.12.2016 19:58

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)

duzenko

duzenko

03.12.2016 20:02

developer   ~0008587

Skybox blurring addressed in svn rev 6712
nbohr1more

nbohr1more

04.12.2016 04:03

developer   ~0008588

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.
duzenko

duzenko

04.12.2016 08:47

developer   ~0008589

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)?
nbohr1more

nbohr1more

04.12.2016 14:32

developer   ~0008590

Nice!

_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.
duzenko

duzenko

04.12.2016 19:07

developer   ~0008592

6716 - attached the currentRender texture to FBO
You can see some feedback loop jittering as a result.
Where can I test scratch/reflection?
nbohr1more

nbohr1more

04.12.2016 19:18

developer   ~0008593

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?
duzenko

duzenko

04.12.2016 20:01

developer   ~0008594

Not sure what you mean by connecting?
nbohr1more

nbohr1more

04.12.2016 20:02

developer   ~0008595

Rather than make _currentRender it's own FBO, just read from the main framebuffer. Unless you're already doing that?
duzenko

duzenko

04.12.2016 20:04

developer   ~0008596

Actually right now there is only one fbo that does all the rendering.
Main framebuffer only used to display the fbo content.
nbohr1more

nbohr1more

04.12.2016 20:16

developer   ~0008597

Hmm. Maybe lightgem timing shenanigans akin to issue 4420 are at play here?
Not sure what else would cause the jitter.
duzenko

duzenko

04.12.2016 20:19

developer   ~0008598

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.
nbohr1more

nbohr1more

04.12.2016 20:24

developer   ~0008599

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.
nbohr1more

nbohr1more

05.12.2016 13:32

developer   ~0008601

Last edited: 05.12.2016 13:32

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).

duzenko

duzenko

05.12.2016 21:29

developer   ~0008607

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.
duzenko

duzenko

11.12.2016 11:32

developer   ~0008611

Last edited: 11.12.2016 11:34

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

nbohr1more

nbohr1more

12.12.2016 04:23

developer   ~0008613

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?
duzenko

duzenko

12.12.2016 14:52

developer   ~0008614

Are both r_fboShared 0 for you? What happens when either of them is 1?
nbohr1more

nbohr1more

12.12.2016 15:17

developer   ~0008615

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.
duzenko

duzenko

14.12.2016 12:44

developer   ~0008616

Fixed the slowdown using GL_DEPTH_COMPONENT instead of GL_DEPTH_COMPONENT16.
By postproceesing you mean r_skippostprocess or r_postprocess?
nbohr1more

nbohr1more

15.12.2016 02:30

developer   ~0008617

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.
duzenko

duzenko

19.12.2016 09:20

developer   ~0008622

Compass toggle -> black screen
Related to the earlier-reported screen recording blackout?
nbohr1more

nbohr1more

29.12.2016 04:48

developer   ~0008665

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.
duzenko

duzenko

29.12.2016 10:08

developer   ~0008674

Hopefully this fixes it: svn rev 6736
duzenko

duzenko

21.05.2017 11:08

developer   ~0008871

Fixed depth in non-shared mode
nbohr1more

nbohr1more

22.05.2017 03:04

developer   ~0008874

Enabling the Compass inventory item causes the screen to go black with r_useFBO = 1 (enabled)
duzenko

duzenko

22.05.2017 13:45

developer   ~0008875

Fixed compass
stgatilov

stgatilov

23.06.2017 17:04

administrator   ~0008924

Last edited: 15.09.2017 16:53

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).

nbohr1more

nbohr1more

14.09.2017 18:21

developer   ~0009240

The core implementation appears to be done.
Any reason why this cannot be closed and new bugs be created for additional features?
nbohr1more

nbohr1more

17.09.2017 21:48

developer   ~0009283

FBO exists in TDM 2.06.
Further changes can be logged as new bugs or enhancements.
duzenko

duzenko

24.11.2017 13:08

developer   ~0009688

Current version FBO is slow on AMD. Needs investigating.

Issue History

Date Modified Username Field Change
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
30.11.2016 09:13 duzenko Note Edited: 0008570
30.11.2016 09:20 duzenko Note Edited: 0008570
30.11.2016 14:06 duzenko Note Edited: 0008570
30.11.2016 20:33 duzenko Note Added: 0008571
30.11.2016 20:33 duzenko Note Edited: 0008571
01.12.2016 03:37 nbohr1more Note Added: 0008574
01.12.2016 04:15 nbohr1more Note Edited: 0008574
01.12.2016 07:13 duzenko Note Added: 0008576
01.12.2016 09:34 duzenko Note Edited: 0008576
01.12.2016 15:43 duzenko Note Added: 0008579
01.12.2016 15:44 duzenko Note Edited: 0008579
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
02.12.2016 18:38 duzenko Note Edited: 0008585
02.12.2016 19:58 duzenko Note Edited: 0008585
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
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
11.12.2016 11:34 duzenko Note Edited: 0008611
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
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