OpenGL 3+ RenderSystem

[saejox]

that post shows an exceptional effort for just a spam.
i like the hidden url

[masterfalcon]

I've got a list of 4.0+ features here and I'm looking for feedback on which are most important to developers. BTW, tessellation is already planned.

• - 4.0
  • Support for OpenGL Shading Language 4.00, including new fragment shader texture functions (textureLOD) that return the results of automatic level-of-detail computations that would be performed if a texture lookup were performed (GL_ARB_texture_query_lod - this extension only affects the shading language, not the API).
  • Ability to set individual blend equations and blend functions for each color output (GL_ARB_draw_buffers_blend).
  • Mechanism for supplying the arguments to a DrawArraysInstanced or DrawElementsInstancedBaseVertex drawing command from buffer object memory (GL_ARB_draw_indirect).
  • Many new features in OpenGL Shading Language 4.00 and related APIs to support capabilities of current generation GPUs (GL_ARB_gpu_shader5 - see that extension specification for a detailed summary of the features).
  • Support for double-precision floating-point uniforms, including vectors and matrices, as well as double-precision floating-point data types in shaders (GL_ARB_gpu_shader_fp64).
  • Ability to explicitly request that an implementation use a minimum number of unique set of fragment computation inputs when multisampling a pixel (GL_ARB_sample_shading).
  • Support for “indirect subroutine calls”, where a single shader can include many subroutines and dynamically select through the API which subroutine is called from each call site (GL_ARB_shader_subroutine).
  • New tessellation stages and two new corresponding shader types, tessellation control and tessellation evaluation shaders, operating on patches (fixed-sized collections of vertices) (GL_ARB_tessellation_shader).
  • Support for three-component buffer texture formats RGB32F, RGB32I, and RGB32UI (GL_ARB_texture_buffer_object_rgb32).
  • Cube map array textures, 2-dimensional array textures that may contain many cube map layers. Each cube map layer is a unique cube map image set (GL_ARB_texture_cube_map_array).
  • New texture functions (textureGather) that determine the 2x2 footprint used for linear filtering in a texture lookup, and return a vector consisting of the first component from each of the four texels in the footprint (GL_ARB_texture_gather).
  • Additional transform feedback functionality including (GL_ARB_transform_feedback2)
  – transform feedback objects which encapsulate transform feedback-related state;
  – the ability to pause and resume transform feedback operations; and
  – the ability to draw primitives captured in transform feedback mode without querying the captured primitive count
  • Additional transform feedback functionality including increased flexibility in how vertex attributes can be written to buffer objects and new support for multiple separate vertex streams (GL_ARB_transform_feedback3).
  
  - 4.1
  • Improved OpenGL ES 2.0 compatibility by adding features previously found only in OpenGL ES 2.0 and not OpenGL 4.0 (GL_ARB_ES2_compatibility).
  • Commands to retrieve and set the binary representation of a program object (GL_ARB_get_program_binary).
  • Increases in the required supported sizes for textures and renderbuffers.
  • Ability to mix-and-match separately compiled shader objects defining different shader stages (GL_ARB_separate_shader_objects).
  • Clarified restrictions on the precision requirements for shaders in the OpenGL Shading Language Specification (GL_ARB_shader_precision).
  • OpenGL Shading Language support for vertex shader inputs with 64-bit floating-point components, and OpenGL API support for specifying the values of those inputs (GL_ARB_vertex_attrib_64bit).
  • Expose multiple viewports for use with geometry shader outputs and multiple framebuffer attachments, and floating-point viewport bounds (GL_ARB_viewport_array).
  • Token change: CURRENT_PROGRAM -> ACTIVE_PROGRAM
  
  - 4.2
  • Support for BPTC compressed textures (ARB_texture_compression_bptc).
  • Allow pixel storage parameters to affect packing and unpacking of compressed textures (ARB_compressed_texture_pixel_storage).
  • Shader atomic counters (ARB_shader_atomic_counters).
  • Immutable texture images (ARB_texture_storage).
  • Instanced transformed feedback drawing (ARB_transform_feedback_instanced).
  • Allow the offset within buffer objects used for instanced rendering to be specified (ARB_base_instance).
  • OpenGL Shading Language built-in functions allowing loads from and stores to texture images from any shader stage, and application control over the ordering of image load/store operations relative to other OpenGL pipeline operations accessing the same memory (ARB_shader_image_- load_store).
  • New OpenGL Shading Language features with no OpenGL API impact (ARB_conservative_depth and ARB_shading_language_420pack - see the OpenGL Shading Language Specification for details).
  • Queries for sample counts available for a given internal format and usage (ARB_internalformat_query).
  • More restrictive alignment constraints for mapped buffers (ARB_map_buffer_alignment).

[TheSHEEEP]

Okay, the 4.2 ones are beyond my understanding of what could be useful, but these are what I would find to be most important for the 4.0 and 4.1:

• - 4.0
  • Support for OpenGL Shading Language 4.00, including new fragment shader texture functions (textureLOD) that return the results of automatic level-of-detail computations that would be performed if a texture lookup were performed (GL_ARB_texture_query_lod - this extension only affects the shading language, not the API).
  • Support for double-precision floating-point uniforms, including vectors and matrices, as well as double-precision floating-point data types in shaders (GL_ARB_gpu_shader_fp64).
  • Support for “indirect subroutine calls”, where a single shader can include many subroutines and dynamically select through the API which subroutine is called from each call site (GL_ARB_shader_subroutine).
  • Support for three-component buffer texture formats RGB32F, RGB32I, and RGB32UI (GL_ARB_texture_buffer_object_rgb32).
  • New texture functions (textureGather) that determine the 2x2 footprint used for linear filtering in a texture lookup, and return a vector consisting of the first component from each of the four texels in the footprint (GL_ARB_texture_gather).
  
  - 4.1
  • Improved OpenGL ES 2.0 compatibility by adding features previously found only in OpenGL ES 2.0 and not OpenGL 4.0 (GL_ARB_ES2_compatibility).
  • Increases in the required supported sizes for textures and renderbuffers.
  • Clarified restrictions on the precision requirements for shaders in the OpenGL Shading Language Specification (GL_ARB_shader_precision).
  • OpenGL Shading Language support for vertex shader inputs with 64-bit floating-point components, and OpenGL API support for specifying the values of those inputs (GL_ARB_vertex_attrib_64bit).

[dark_sylinc]

I've got a list of 4.0+ features here and I'm looking for feedback on which are most important to developers. BTW, tessellation is already planned.

• • Shader atomic counters (ARB_shader_atomic_counters).

I cannot stress enough the importance of that feature. It is the core of the next gen graphic techniques.
That, and GL 4.3's compute shaders. Those two are probably more important than anything else GL 4 has to offer.

Cheers
Dark Sylinc

[masterfalcon]

Agreed on the atomic counters. At the moment I'm limiting it to 4.2 features because all I have are AMD GPU's and well, they don't have 4.3 support yet.

[TheSHEEEP]

Could you give an example of what the atomic counters could be used for? I mean, not in actual shader code (but I won't prevent you if you want ), but more like a general idea.

I saw an example that showed the order in which the fragments are rendered. While that is funny, I don't see of what actual use it could be.
The way the examples showed them, the counters can not be accessed from code, only from the vertex and fragment programs.

The compute shaders would indeed be very useful, but only on a very limited number of use cases, so I agree you should probably focus on 4.0-4.2 first.

[dark_sylinc]

Could you give an example of what the atomic counters could be used for? I mean, not in actual shader code (but I won't prevent you if you want ), but more like a general idea.

I saw an example that showed the order in which the fragments are rendered. While that is funny, I don't see of what actual use it could be.

Light indexed deferred. Also known as THE future. See AMD's Leo demo.
Ultra fast Bokeh depth of field (4th technique being described)

Thing is, atomic counters are like "IncrementAdd" from the CPU. Atomic operations are atomic, even in pixel shaders. It allows write-access to variables shared across the GPU (mind you, if you abuse them, you'll force serialization).
With an output buffer, UAVs are possible (Unordered access view). You just need an index specifying where to write in memory, and if this index is guaranteed to be unique (atomic operations now allow this) then you can output arbitrary data and create linked lists, std::vector-like structures, etc. Then read the results in the next pass.

You can't do Light Indexed deferred without atomic counters. It's still possible to use DX10 (no atomics) and created the light tile buffer in the CPU. But you'll lose the ability of doing bidirectional depth checking to limit the number of lights per tile, unless you complement it with a readback from the GPU of the depth buffer, or use a depth-only SW rasterizer at the same time.

I'm going to post an article about all this in the following week. Wolfmanfx's already saw a glimpse of it

PS. It's also possible to do order-independent transparency like in ATI demo but it's freaking slow. Nice proof of concept though, and may be useful if you're writing a cinematic-quality render application (rasterization-based rendering tool for the movie industry perhaps?)

[TheSHEEEP]

Ah, okay. I see how you could use that to improve and speed up some things. Especially if you already use some other improvements (like light geometries for deferred shading).

[dark_sylinc]

It does improve the performance of deferred shading by ditching the need for light volumes (replaced by light quads).

However the point of Light indexed deferred is ditch traditional deferred and go back to forward rendering, except that now you have all the perks: Huge number of lights, transparency compatible, multiple BDRFs, & allows MSAA.
This is why this technique is THE next-gen technique. It's been presented in 2012, so expect starting seeing it commonly in 2 years.

[masterfalcon]

I'll need to get some sort of demo together to take advantage of this for testing. But yeah there are many many possibilities for atomic counters to be used in.

[masterfalcon]

Speaking of a demo. Anyone have any suggestions or know of any existing atomic counter demos that would be neat to port and show off in Ogre?

[TheSHEEEP]

This is what I was referring to in one of my last posts:

http://www.geeks3d.com/20120309/opengl- ... fragments/

But as I said, it is funny but does not show something that actually makes sense to do

[dark_sylinc]

Speaking of a demo. Anyone have any suggestions or know of any existing atomic counter demos that would be neat to port and show off in Ogre?

Sprite-based Screen space effects, like the bokeh demo should be easy to implement (or a similar one, but doing sprite-based lens flare)

All the advanced very cool stuff that uses atomic counters (Global ilumination and tile-based deferred shading or light indexed deferred) requires Compute Shaders too.

[holocronweaver]

I will have to think a bit more on the rest of the OpenGL 4 features listed above, but the 64-bit shader variables would be incredibly useful for extremely large environments. It would essentially double the size worlds can reach before I run into overflow errors.

[masterfalcon]

Oh good, I already have that implemented

[masterfalcon]

Alright everyone. I have committed the new rendersystem to the 1.9 branch. I've tested it on Windows 7(AMD), Ubuntu(AMD) and OS X(AMD & NVIDIA).

Bear in mind that I still consider it alpha, though many things work great. Several features are still unfinished or incomplete but I'll get to them.

Have fun! And as always, patches and bugs are definitely welcome.

[Wolfmanfx]

Great work - this really a big milestone for the OGRE project!

[Kojack]

I'm getting a compile error in dx9 and dx11.
Both are saying (replace 9 with 11 for dx11's error):

Code: Select all

IntelliSense: object of abstract class type "Ogre::D3D9HardwareBufferManagerBase" is not allowed:
            pure virtual function "Ogre::HardwareBufferManagerBase::createCounterBuffer" has no overrider
s:\work\ogre_test_1.9_03\RenderSystems\Direct3D9\include\OgreD3D9HardwareBufferManager.h	67

[masterfalcon]

I figured that would happen. I just didn't test out the DX render systems.

[scrawl]

Unable to build on linux:

Code: Select all

-- Configuring done
CMake Error at CMake/Utils/OgreAddTargets.cmake:100 (add_library):
  Cannot find source file:

    src/GLX/OgreFileSystemLayer.cpp

  Tried extensions .c .C .c++ .cc .cpp .cxx .m .M .mm .h .hh .h++ .hm .hpp
  .hxx .in .txx
Call Stack (most recent call first):
  OgreMain/CMakeLists.txt:731 (ogre_add_library)

After commenting out the src/GLX/OgreFileSystemLayer.cpp file in OgreMain/CMakeLists.txt, I got a step further:

Code: Select all

[ 47%] Built target OgreMain
[ 47%] Building CXX object RenderSystems/GL3Plus/CMakeFiles/RenderSystem_GL3Plus.dir/src/glew.cpp.o
/home/scrawl/ogre-gl3plus/RenderSystems/GL3Plus/src/glew.cpp:33:27: fatal error: OgreGLSupport.h: No such file or directory
compilation terminated.

[holocronweaver]

I get the same CMake error as scrawl, but only when I am try buliding with tests. A vanilla CMake configuration builds fine.

Great work! I am going to try out tessellation tonight. =)

[scrawl]

I get the error even with tests disabled.

[masterfalcon]

Let me check on it. I may have missed some stuff from linux.

[masterfalcon]

Where are you guys getting the source from? glew.cpp doesn't exist there anymore. Make sure you're getting it from the official Ogre repository, not the fork that I created a while back.

[scrawl]

Ah, I see. My bad.