Skip to content

Removed features

Orka does not support all features of graphics APIs like OpenGL. Some functionality in OpenGL does not exist in Vulkan or SPIR-V, or should not be used because nowadays there are better ways to do certain things.

Vulkan

For commonality with a future Vulkan backend, several features have been removed in the OpenGL backend:

  • Atomic counter buffers. Atomic counters are implemented using SSBO atomic operations in most hardware. Furthermore, atomic_uint is not supported in SPIR-V. Use function atomicAdd() in shaders instead.

  • Shader subroutines. Shader subroutines only worked well on certain hardware/driver combinations, while causing recompilations on others like Mesa. In addition, each program needed to carry along a lot of extra data to make them easy to use. SPIR-V doesn't seem to support subroutines.

    Instead of using shader subroutines, use a switch statement with a uniform, or use program pipelines to bind stages of different shader programs.

  • Line loop and triangle fan primitive topologies. Some primitive topologies like line loop and triangle fan are not (always) supported by Vulkan. See section 20.1 Primitive Topologies and VkPrimitiveTopology of the Vulkan specification.

  • 8-bit unsigned integers for indices for indexed draws. Indices in a buffer must be 16-bit or 32-bit unsigned integers. See VkIndexType.

  • Arbitrary border colors. Only transparent, black, or white texture border colors are supported. See section 16.3.3 Texel Replacement of the Vulkan specification.

  • Non-seamless cube maps. Only seamless cube maps are supported.

Some conventions have changed to Vulkan's:

  • First vertex is the provoking vertex. The first vertex is used as the provoking vertex for vertex output attributes. It is used in flat shading where all vertices of a primitive have the value of the provoking vertex.

  • Depth of the clipping volume has range [0, 1]. The range of the depth of the clipping volume has been changed from the default of [-1, 1] to Vulkan's [0, 1].

Other removed features

Over the years, OpenGL has accumulated a lot of functionality. Some of which should no longer be used in new applications. This list helps the user to determine which features do not exist on purpose and how they can be replaced.

  • Conditional rendering. Conditional rendering in OpenGL requires submitting draw calls and has latency if you want to read back the results of the queries.

    There are better ways to do occlusion culling:

    • On the GPU in a compute shader and use indirect drawing

    • On the CPU with a software rasterizer1 if you need the results on the CPU with low latency

  • Non-indirect multi draw rendering commands. Use the indirect multi draw commands instead.

  • Most setters/getters for pixel (un)packing. Instead properly format your data in the first place. Ada's Bit_Order and Scalar_Storage_Order aspects may be used to control endianness. Row alignment can still be set because some formats like KTX require data to be (not) packed.

  • Reading pixels from the framebuffer. Read pixels from a texture attached to the framebuffer instead.

  • Renderbuffers. Renderbuffers are useless because textures support multisampling via ARB_texture_multisample since OpenGL 3.2. They provide no performance benefit in practice and removing them simplifies applications.

  • Sampler state in textures. Sampler objects are used to store sampler state. This is more how the hardware and other graphics APIs operate.

  • Shader binaries. Loading program binaries will not be supported. In the future support for SPIR-V may be added instead.

  • Transform feedback. Transform feedback is a legacy feature. With transform feedback, primitives are ordered across the draw call instead of per-pixel. Use compute shaders with SSBOs or images instead.

  • Uniform arrays. Set separate vectors and matrices, or use UBOs.

  • Vertex array objects. Vertices can be pulled programmatically in vertex shaders. This avoids having to track and pass around extra objects for vertex formats.

  • Wide lines. Wide lines have hardware-dependent limits and will raise an Invalid_Value_Error in a forward-compatible context. To render wide lines in a portable way, generate geometry or use a geometry shader.

  1. "Masked Software Occlusion Culling", Hasselgren J., Andersson M., Akenine-Möller T., High Performance Graphics, 2016. ↩