GZDoom on GL 3.x core profile

[Graf Zahl]

After rewriting most of the render code to avoid writing to a vertex buffer during the rendering pass in the last few weeks I finally was able to switch it over to the new code.

So, as of today, starting GZDoom on OpenGL 3.x will only use core profile features, meaning the Mac version can now be adjusted, too.
Performance of this lies between the old compatibility profile method and persistently mapped buffers, so the new code is now the default.

A few things need to be decided next, after it is confirmed that this actually works on macOS:

- do we still need shader handling on GL 2.x? If Macs are removed from the picture, the only remaining hardware is old Intel integrated chipsets, which have really bad shader performance throughout. The same obviously applies to old NVidia and ATI hardware with no GL3 compatibility, so I really see no point supporting this stuff any further.
- how can the postprocessing code be streamlined, if these ugly edge cases are no longer relevant? What parts of the postprocessing pipeline are actually used in the non-shader case?

[dpJudas]

In the non-shader case nothing is used in the postprocessing pipeline. This is because without the present shader it has no way of copying stuff back to the back buffer. All the entry points to the post processing code begins with a IsEnabled/Setup call. Whenever they return false the code skips all post process.

As for streamlining, the main thing that can be improved is state and object management. The code manually creates framebuffers, renderbuffers, and textures. It also maintains its own OpenGL state isolation using FGLPostProcessState. Ideally it would use FRenderState for blending, FHardwareTexture for textures, some new FGLFramebuffer and FGLRenderbuffer classes for FBO, and FSamplerManager for texture filtering. Maybe also move viewport handling to its own dedicated class. The main problem here is that especially FHardwareTexture and FSamplerManager aren't flexible enough to do the job today. Especially FHardwareTexture takes on way too many responsibilities that really should be FGLTexture and friends own problem to handle (translations, render to texture).

[_mental_]

I'll try to enable core profile on macOS later today.
I decided to test with Mesa3D for now. The picture is worth thousand of words:

Screenshot_Doom_20160829_155139.png (36.88 KiB) Viewed 1483 times

Not a black screen at least

Here is the log:

Code: Select all

GL_VENDOR: VMware, Inc.
GL_RENDERER: Gallium 0.4 on llvmpipe (LLVM 3.7, 256 bits)
GL_VERSION: 3.3 (Core Profile) Mesa 11.2.2 (Core profile)
GL_SHADING_LANGUAGE_VERSION: 3.30
GL_EXTENSIONS: GL_AMD_conservative_depth GL_AMD_draw_buffers_blend GL_AMD_seamless_cubemap_per_texture GL_AMD_shader_stencil_export GL_AMD_shader_trinary_minmax GL_AMD_vertex_shader_layer GL_AMD_vertex_shader_viewport_index GL_ANGLE_texture_compression_dxt3 GL_ANGLE_texture_compression_dxt5 GL_ARB_ES2_compatibility GL_ARB_ES3_compatibility GL_ARB_arrays_of_arrays GL_ARB_base_instance GL_ARB_blend_func_extended GL_ARB_buffer_storage GL_ARB_clear_buffer_object GL_ARB_clip_control GL_ARB_compressed_texture_pixel_storage GL_ARB_conditional_render_inverted GL_ARB_conservative_depth GL_ARB_copy_buffer GL_ARB_debug_output GL_ARB_depth_buffer_float GL_ARB_depth_clamp GL_ARB_direct_state_access GL_ARB_draw_buffers GL_ARB_draw_buffers_blend GL_ARB_draw_elements_base_vertex GL_ARB_draw_indirect GL_ARB_draw_instanced GL_ARB_explicit_attrib_location GL_ARB_explicit_uniform_location GL_ARB_fragment_coord_conventions GL_ARB_fragment_layer_viewport GL_ARB_fragment_shader GL_ARB_framebuffer_object GL_ARB_framebuffer_sRGB GL_ARB_get_program_binary GL_ARB_get_texture_sub_image GL_ARB_gpu_shader_fp64 GL_ARB_half_float_pixel GL_ARB_half_float_vertex GL_ARB_instanced_arrays GL_ARB_internalformat_query GL_ARB_invalidate_subdata GL_ARB_map_buffer_alignment GL_ARB_map_buffer_range GL_ARB_multi_bind GL_ARB_multi_draw_indirect GL_ARB_occlusion_query2 GL_ARB_pixel_buffer_object GL_ARB_point_sprite GL_ARB_program_interface_query GL_ARB_provoking_vertex GL_ARB_robustness GL_ARB_sampler_objects GL_ARB_seamless_cube_map GL_ARB_seamless_cubemap_per_texture GL_ARB_separate_shader_objects GL_ARB_shader_bit_encoding GL_ARB_shader_objects GL_ARB_shader_stencil_export GL_ARB_shader_subroutine GL_ARB_shader_texture_lod GL_ARB_shading_language_420pack GL_ARB_shading_language_packing GL_ARB_stencil_texturing GL_ARB_sync GL_ARB_texture_buffer_object GL_ARB_texture_buffer_object_rgb32 GL_ARB_texture_buffer_range GL_ARB_texture_compression_rgtc GL_ARB_texture_cube_map_array GL_ARB_texture_float GL_ARB_texture_gather GL_ARB_texture_mirror_clamp_to_edge GL_ARB_texture_multisample GL_ARB_texture_non_power_of_two GL_ARB_texture_query_levels GL_ARB_texture_rectangle GL_ARB_texture_rg GL_ARB_texture_rgb10_a2ui GL_ARB_texture_stencil8 GL_ARB_texture_storage GL_ARB_texture_storage_multisample GL_ARB_texture_swizzle GL_ARB_texture_view GL_ARB_timer_query GL_ARB_transform_feedback2 GL_ARB_transform_feedback3 GL_ARB_transform_feedback_instanced GL_ARB_uniform_buffer_object GL_ARB_vertex_array_bgra GL_ARB_vertex_array_object GL_ARB_vertex_attrib_64bit GL_ARB_vertex_attrib_binding GL_ARB_vertex_shader GL_ARB_vertex_type_10f_11f_11f_rev GL_ARB_vertex_type_2_10_10_10_rev GL_ARB_viewport_array GL_ATI_blend_equation_separate GL_ATI_texture_float GL_ATI_texture_mirror_once GL_EXT_abgr GL_EXT_blend_equation_separate GL_EXT_draw_buffers2 GL_EXT_draw_instanced GL_EXT_framebuffer_blit GL_EXT_framebuffer_multisample GL_EXT_framebuffer_multisample_blit_scaled GL_EXT_framebuffer_sRGB GL_EXT_packed_depth_stencil GL_EXT_packed_float GL_EXT_pixel_buffer_object GL_EXT_polygon_offset_clamp GL_EXT_provoking_vertex GL_EXT_shader_integer_mix GL_EXT_texture_array GL_EXT_texture_compression_dxt1 GL_EXT_texture_compression_rgtc GL_EXT_texture_compression_s3tc GL_EXT_texture_integer GL_EXT_texture_mirror_clamp GL_EXT_texture_sRGB GL_EXT_texture_sRGB_decode GL_EXT_texture_shared_exponent GL_EXT_texture_snorm GL_EXT_texture_swizzle GL_EXT_timer_query GL_EXT_transform_feedback GL_EXT_vertex_array_bgra GL_IBM_multimode_draw_arrays GL_KHR_context_flush_control GL_KHR_debug GL_MESA_pack_invert GL_MESA_texture_signed_rgba GL_MESA_ycbcr_texture GL_NV_conditional_render GL_NV_depth_clamp GL_NV_packed_depth_stencil GL_OES_EGL_image GL_OES_read_format GL_S3_s3tc
Max. texture size: 8192
Max. texture units: 18
Max. varying: 128
Max. uniform block size: 65536
Uniform block alignment: 16

[_mental_]

My favorite Extreme Terror works fine with OpenGL 4.1 Core Profile on macOS. Fog and dynamic lights look as it should, found no problem using nVidia and Intel graphics. I will test on some older hardware later.
Congratulations and thanks!

[Graf Zahl]

OK. That's really good to know. I'll wait a bit for feedback from Linux users, but I think the GLSL 1.2 stuff that's still around can be retired now.

[dpJudas]

I'll try to enable core profile on macOS later today.
I decided to test with Mesa3D for now. The picture is worth thousand of words

On which OS did you run this? It looks like the viewport is somehow positioned at half the window resolution, with the texture coordinates used for sampling somehow offsetted and scaled at half what they should be as well.

[Graf Zahl]

Mesa3D and OpenGL 3.x do not mix well, I believe. I once also had problems when testing some non-Doom-related stuff.

[_mental_]

On which OS did you run this? It looks like the viewport is somehow positioned at half the window resolution, with the texture coordinates used for sampling somehow offsetted and scaled at half what they should be as well.

On Windows using my custom build of Mesa3D.
Actually before all these changes with postprocessing, renderbuffers, etc it works correctly.

[dpJudas]

Assuming that what we see in the upper right corner are the full contents of the scene texture, the main rendering goes well. The final copy to back buffer in FGLRenderer::CopyToBackbuffer seems to be what is failing.

How exactly I can't explain beyond some major failing in Mesa3D. To get what I see on the screenshot it would have to be something ala scissor active to cut off lower left, or GetClientRect failing giving wrong mOutputLetterbox values, AND at the same time the scale uniform passed to mPresentShader being wrong and/or the screen quad UV coordinates being wrong. A picture really is worth a thousand words in this case.

[_mental_]

The glitch with Mesa3D is surely present in 7576e85 and probably it was introduced in the previous commit. I can't say for sure as it shows just a black screen.
Anyway the commit before those works fine. I thought it's something more obvious... Have no idea what can be reverted to make it work with Mesa3D.

[Graf Zahl]

Before 'that previous commit' all output was routed through immediate mode calls, which is relatively useless when using a core profile. Also keep in mind that the client array code was quite a bit broken until yesterday.

[_mental_]

With the latest commit at the moment the buggy picture is rendered with the core profile only. Forcing Mesa3D to use OpenGL 2.1 and GLSL 1.20 via environment variables "fixes" the problem. Probably the bug is in the library itself.

[Graf Zahl]

Who knows? You already said it worked fine on your Mac. It also works fine on my Windows with a core profile and all 4.4 features disabled.

[_mental_]

I tried to run the latest version on macOS 10.7 and nVidia 9400M which is approx. the lowest spec supported using Core Profile. It wasn't work out of the box: garbage or black screen was displayed.
To fix it I would like to ask about this particular feature check. It prevents usage of deferred light/buffer methods but client array with software lights don't work (I didn't investigate this yet). Forcing deferred methods by commenting out if() line made it work.
The given hardware/software combination supports OpenGL 3.2 and GLSL 1.50. I'm a bit confused with the comment above the check. Should I just add comparison for GLSL version to handle it properly?

[Graf Zahl]

Which part of the 'if' is failing? What this feature needs is either OpenGL 3.3 or OpenGL 3.0 with the uniform buffer extension. Uniform buffers have only become a core feature in GL 3.3, so in GL 3.2 they have to be checked for by extension.
Since you got the affected system, please debug that line of code. What value does gl.version have, and what does CheckExtension("GL_ARB_uniform_buffer_object") return?
My guess would be that something goes wrong with the extension check. If that is the case, you have to find out why it won't get reported. Obviously the hardware in question should have this extension.

The resulting error here is that the textured lighting code that's being used as a fallback is not working with the core profile, it looks like I missed that one function when making the adjustments. Unfortunately it's also the nastiest piece of code because this cannot be easily offloaded to the processing pass like the other stuff.