Is it possible to support deferred rendering in OpenGL-based graphics?

Unity Engine
,
1

URP deferred rendering dosen’t support the OpenGL-based graphics API, while it seems that build-in pipeline supports deferred rendering in OpenGL ES3.0.
What causes the difference between SRP and build-in pipeline ? Is it possible to support deferred rendering in OpenGL ES3.0 ? And is there a risk to use MRTs in OpenGL-based graphics API ?

1 Like
2

devices supporting only opengl es 3.0 ended in 2008.
Their performance is not enough even to draw a simple defferd scene with 1 cube. Why did you decide that deferred rendering would help you?
Let opengl es / directx9 die.

2 Likes
3

OpenGLES3.0 is indeed old enough. However, urp even doesn’t support OpenGLES3.2, which means we can hardly use deferred rendering in mobile devices.

1 Like
4

Vulcan supported on ~74% devices.
https://developer.android.com/about/dashboards

I think we should focus on these devices.

5

That sounds like bigotry.
According to your link OpenGL 3.2 supports 77% , which is significantly larger than VULKAN.
The focus should clearly be on common devices.

1 Like
6
  1. All mobiles which supported opengles 3.2 also supported Vulcan.
    Note, in a couple of weeks, vulcan support has become 77%, instead of 74%.
    Also, 74% vs 77% it’s not “significantly larger”

2 )Why are you talking about opengl es 3.2? If he wrote about opengl es 3.0?

“bigotry” is trying to run deferred rendering on mobile GPU ~10 years old, like open gles 3.1 or 3.0
For example TOP gpu which not supported Vulcan api (and only opengles 3.1)
adreno 330 (2012 year), ~100-160 GFlops
Mali-T678 (2013 year), ~ 25 GFlops

and current mobile top GPU
adreno 690, ~1800 Gflops
Mali-G78, ~1100 Gflops.

Is there a reason why it is necessary to support opengl es if the devices that support it (for example from Mali) are 44 times weaker than modern mobile GPUs?

Unity already supports a lot of outdated code. Let opengl es die (like direct9), use standard rendering for older devices if you need it.

1 Like
7

Not bigotry at all.

In fact, he corrected himself and clarified that the 3.2 support is also not. More supported interfaces always better.
Most likely along with 3.2 as a nice bonus it can implement 3.1/3.0 in a limited way.

8

People who still use an old phone from 10 years ago won’t buy your game.
For old phones you can use old unity versions and standard rendering.
Maybe you need the direct8 support for pc from 1990? Why not? “More supported interfaces always better.” lol

the problem with opengl is that it makes it impossible to use modern and fast code
For example URP lighting code:

#elif !defined(SHADER_API_GLES)
    // since index is uint shader compiler will implement
    // div & mod as bitfield ops (shift and mask).

    // TODO: Can we index a float4? Currently compiler is
    // replacing unity_LightIndicesX[i] with a dp4 with identity matrix.
    // u_xlat16_40 = dot(unity_LightIndices[int(u_xlatu13)], ImmCB_0_0_0[u_xlati1]);
    // This increases both arithmetic and register pressure.
    return unity_LightIndices[index / 4][index % 4];
#else
    // Fallback to GLES2. No bitfield magic here :(.
    // We limit to 4 indices per object and only sample unity_4LightIndices0.
    // Conditional moves are branch free even on mali-400
    // small arithmetic cost but no extra register pressure from ImmCB_0_0_0 matrix.
    half2 lightIndex2 = (index < 2.0h) ? unity_LightIndices[0].xy : unity_LightIndices[0].zw;
    half i_rem = (index < 2.0h) ? index : index - 2.0h;
    return (i_rem < 1.0h) ? lightIndex2.x : lightIndex2.y;
#endif
}

or shadows code

// GLES3 causes a performance regression in some devices when using CBUFFER.
#ifndef SHADER_API_GLES3
CBUFFER_START(AdditionalLightShadows)
#endif
float4x4    _AdditionalLightsWorldToShadow[MAX_VISIBLE_LIGHTS];
half4       _AdditionalShadowParams[MAX_VISIBLE_LIGHTS];
half4       _AdditionalShadowOffset0;
half4       _AdditionalShadowOffset1;
half4       _AdditionalShadowOffset2;
half4       _AdditionalShadowOffset3;
float4      _AdditionalShadowmapSize; // (xy: 1/width and 1/height, zw: width and height)
#ifndef SHADER_API_GLES3
CBUFFER_END
#endif
#endif

Opengles does not have a clear standard and works like shit. For example, UAV textures with UINT16 works on half of devices, but must work everywhere.
GLES api it’s hell. And so it is everywhere

9

Don’t compare apples and pears.

Fast in what? VULKAN still shows worse performance in real projects.

https://www.reddit.com/r/Unity3D/comments/pfxad0/the_little_default_setting_that_kills_mobile/
or
https://issuetracker.unity3d.com/issues/vulkan-performance-is-worse-than-opengles3-and-opelgles2

1 Like
10

The problem is that as soon as you start to push beyond basic rendering features many GLES drivers fall apart and show their shoddy implementation. Even features which are supposed to be standard requirements sometimes work terribly or not at all.

Bad drivers combined with the fact that a majority of Android phones don’t have anywhere enough bandwidth for MRT mean very few devices would be able to do deferred rendering at playable framerates, making it not worth the maintenance effort.

TL/DR: the “common device” is too weak and too buggy to run deferred rendering.

If you disagree, there’s nothing stopping you from modifying URP and remove the code which disables deferred on OpenGL: the source code is all there.

2 Likes
11

Meanwhile, OpenGLES won’t work on half of the devices :slight_smile:

becase this