Class TGLVersion

This item has no description.

Vendor that created the OpenGL implemenetation. This is just glGetString(GL_VENDOR).

Vendor type, derived from Vendor string.

Renderer (GPU model, or software method used for rendering) of the OpenGL. This is just glGetString(GL_RENDERER).

Are we using Mesa (http://mesa3d.org/). Note that this is detected using VendorVersion, not Vendor.

Vendor-specific drivers version. Right now this is detected for Mesa and Intel.

This item has no description.

This item has no description.

ATI GPU with ATI drivers on Linux.

Buggy generation of cube maps on FBO (Intel(Windows) bug).

Symptoms: Parts of the cube map texture are uninitialized (left magenta). Reproducible with castle-model-viewer on demo_models/cube_environment_mapping/cubemap_generated_in_dynamic_world.x3dv . Using separate FBO for each cube map face doesn't help (actually, makes it worse, there's more magenta), so it's not about being unable to do RenderToTexture.SetTexture multiple times.

Observed, and this workaround is needed, at least on:

• Version string: 2.1.0 - Build 8.15.10.2104

• Vendor: Intel

• Renderer: Intel(R) HD Graphics

Buggy generation of cube maps at all (Intel(Windows) bug).

Symptoms: Parts of the cube map texture are uninitialized (left magenta). Reproducible with castle-model-viewer on demo_models/cube_environment_mapping/cubemap_generated_in_dynamic_world.x3dv . This is worse than BuggyFBOCubeMap, magenta is always seen at positiveX part of the cube map.

Observed, and this workaround is needed, at least on:

• Version string: 3.3.0 - Build 8.15.10.2778

• Vendor: Intel

• Renderer: Intel(R) HD Graphics 4000

Buggy VBO (Intel(Windows) bug).

Buggy (looks like wireframe) FBO rendering to the multi-sampling texture (ATI(Windows) and Intel(Windows) bug). This makes our screen effects broken on multi-sampled contexts.

Buggy swap buffers when glViewport does not contain whole window (ATI(Linux) bug).

Buggy 32-bit depth buffer, 24-bit depth buffer works Ok (Mesa on ATI (Linux) bug).

Buggy gl_FrontFacing in GLSL. Observed on Mesa 10.x with OpenGL 3.x (see implemenetation for details where it's observed / not observed).

Note that avoiding gl_FrontFacing (that seems to always has inverted value?) is only a part of the workaround for these GPUs. The other is to not render back faces, since it seems that normals are *always* oriented to point to the light (so, if you don't look at gl_FrontFacing, you are lit from *both* sides). So enable backface culling, or just be prepared that backfaces may be incorrectly light.

Do not read varying values in vertex shader, treat them as write-only.

MaxTextureSize above 2048 shall not be trusted.

Buggy num_steps value in bmSteepParallax and bmSteepParallaxShadowing BumpMapping modes on Adreno mobile GPU's (random crashes, sometimes variable in shader has wrong value. Observed on: - Xiaomi Mi 10 Lite (M2002J9G), Snapdragon 765G, Adreno 620: - Motorola Moto G8 (XT2045-2), Snapdragon 665, Adreno 610 - Motorola Moto G7 Plus (XT2081-2), Snapdragon 460, Adreno 610 - Xiaomi Redmi Note 8, Snapdragon 665, Adreno 610 - Xiaomi Redmi Note 7A Snapdragon 439, Adreno 505 More info in comment TGLVersion.Create().

It can be tested by https://github.com/and3md/castle-adreno-tests