 |
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 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 |
|
|
Apparently Intel ignores the color bits option and always renders to 32bit texture. Fbo fullscreen: always use desktop resolution for fast Alt-Enter. |
|
|
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. :) |
|
|
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. 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 |
|
|
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)? |
|
|
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. |
|
|
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) |
|
|
Fixed compass |
 |
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. |
- Anonymous
