OpenGL Invalid Enum #95592

New Issue

jon denning · 2022-02-07T22:57:29+01:00

jon denning commented

2022-02-07 22:57:29 +01:00

System Information
Operating system: macOS-12.1-arm64-arm-64bit 64 Bits
Graphics card: Apple M1 Apple 4.1 Metal - 76.3

Blender Version
Broken: version: 3.1.0 Beta, branch: master, commit date: 2022-02-06 19:53, hash: 1d59a7aa77
Worked: 2.93.6, 3.0.1, 3.2.0 Alpha

Short description of error
Something in the Blender startup is causing an Invalid Enum OpenGL to occur.

Exact steps for others to reproduce the error

Run the following in the Python Console after starting Blender with default scene and factory loaded settings.

import bgl ; bgl.glGetError()  # reports 1280, which is bgl.GL_INVALID_ENUM

**System Information** Operating system: macOS-12.1-arm64-arm-64bit 64 Bits Graphics card: Apple M1 Apple 4.1 Metal - 76.3 **Blender Version** Broken: version: 3.1.0 Beta, branch: master, commit date: 2022-02-06 19:53, hash: `1d59a7aa77` Worked: 2.93.6, 3.0.1, 3.2.0 Alpha **Short description of error** Something in the Blender startup is causing an `Invalid Enum` OpenGL to occur. **Exact steps for others to reproduce the error** Run the following in the Python Console after starting Blender with default scene and factory loaded settings. ``` import bgl ; bgl.glGetError() # reports 1280, which is bgl.GL_INVALID_ENUM ```

jon denning commented

2022-02-07 22:57:29 +01:00

Added subscriber: @gfxcoder

Donovane commented

2022-02-08 00:11:52 +01:00

Added subscriber: @dodo-2

Donovane commented

2022-02-08 00:11:52 +01:00

Changed status from 'Needs Triage' to: 'Confirmed'

Donovane commented

2022-02-08 00:11:52 +01:00

Verified, i can reproduce the error.

Jacob Merrill commented

2022-02-08 02:44:00 +01:00

Added subscriber: @JacobMerrill-1

Jacob Merrill commented

2022-02-08 02:44:00 +01:00

apple does not have openGL

I think the gpu module needs to be used here (to use metal?)

apple does not have openGL I think the gpu module needs to be used here (to use metal?)

Ray molenkamp commented

2022-02-08 02:58:12 +01:00

Added subscriber: @LazyDodo

Ray molenkamp commented

2022-02-08 02:58:12 +01:00

apple does not have openGL

Yeah.... no... apple doeshave opengl and we use it, there is a metal backend for cycles, but everything else is good'ol openGL

@gfxcoder can you try starting blender with the --factory-startup --debug-gpu --log gpu.* --log-level -1 flags and attaching the log?

> apple does not have openGL Yeah.... no... apple *does*have opengl and we use it, there is a metal backend for cycles, but everything else is good'ol openGL @gfxcoder can you try starting blender with the ` --factory-startup --debug-gpu --log gpu.* --log-level -1` flags and attaching the log?

jon denning commented

2022-02-08 05:23:13 +01:00

@LazyDodo, see attached.

log

@LazyDodo, see attached. [log](https://archive.blender.org/developer/F12854437/log)

Michael commented

2022-02-08 13:16:30 +01:00

Added subscribers: @fclem, @michael64

Michael commented

2022-02-08 13:16:30 +01:00

Thank you @gfxcoder for reporting this issue. There are a few things going here.
Let's start with the symptom of the 1280 error code.
Blender uses the the function check_gl_error in gl_debug.cc to check and report OpenGL errors.
Since 8be20fcc61 check_gl_error does not even call glGetError() if blender is not run with --debug-gpu.
So if you'd run run blender with --debug-gpu you should get error code 0 again because it was read by check_gl_error.
But there actually was an error 1280 that was not reported by check_gl_error.
I think this missing error report is due to 0d1f65e516 where the logic if an error should be reported was always incorrectly inverted.
The standard logging level for gpu.debug is CLG_SEVERITY_WARN(=1) and the error that wasn't reported had CLG_SEVERITY_ERROR(=2) so more severe.

In the debug_callback which is used by check_gl_error we have the line:
```
if (((LOG.type->flag & CLG_FLAG_USE) && (LOG.type->level >= clog_severity))) {

I think comparison `>=` actually needs to be `<=` so the same log level severity and more severe levels are reported.
Actually compiling and running a build with  `<=` promptly reveals an OpenGL error on Mac and Windows as well that has been silently ignored.
@fclem, could you have a look at this?

Thank you @gfxcoder for reporting this issue. There are a few things going here. Let's start with the symptom of the 1280 error code. Blender uses the the function `check_gl_error` in `gl_debug.cc` to check and report OpenGL errors. Since 8be20fcc61 `check_gl_error` does not even call `glGetError()` if blender is not run with `--debug-gpu`. So if you'd run run blender with `--debug-gpu` you should get error code 0 again because it was read by `check_gl_error`. But there actually was an error 1280 that was not reported by `check_gl_error`. I think this missing error report is due to 0d1f65e516 where the logic if an error should be reported was always incorrectly inverted. The standard logging level for `gpu.debug` is `CLG_SEVERITY_WARN`(=1) and the error that wasn't reported had `CLG_SEVERITY_ERROR`(=2) so more severe. In the `debug_callback` which is used by `check_gl_error` we have the line: ``` if (((LOG.type->flag & CLG_FLAG_USE) && (LOG.type->level >= clog_severity))) { ``` I think comparison `>=` actually needs to be `<=` so the same log level severity and more severe levels are reported. Actually compiling and running a build with `<=` promptly reveals an OpenGL error on Mac and Windows as well that has been silently ignored. @fclem, could you have a look at this?

Clément Foucault commented

2022-02-09 13:22:39 +01:00

I think comparison >= actually needs to be <= so the same log level severity and more severe levels are reported.

I actually ran into the same issue and just forgot to push the fix.

I guess the error comes from the glGetIntegerv we do to get the capabilities and limits of the context. But it is not obvious which one is not available on all systems. I'll see if I can reproduce on my intel Mac.

>I think comparison >= actually needs to be <= so the same log level severity and more severe levels are reported. I actually ran into the same issue and just forgot to push the fix. I guess the error comes from the `glGetIntegerv` we do to get the capabilities and limits of the context. But it is not obvious which one is not available on all systems. I'll see if I can reproduce on my intel Mac.

jon denning commented

2022-03-18 11:55:35 +01:00

probably unrelated, but i'll post here as an update: when I tried building with DEBUG and running blender in lldb, it stop with an invalid enum error when creating shaders at startup (workbench_taa, workbench_composite_matcap, others?). I traced this issue to the default value for the final parameter of sampler function in gpu_shader_create_info.hh. when I changed the default value from -1 (which is not a value in eGPUSamplerState) to GPU_SAMPLER_DEFAULT (see below), lldb no longer stops when creating shaders. however, the Invalid Enum error is still getting set, so this solution does not solve the original problem.

  Self &sampler(int slot,
                ImageType type,
                StringRefNull name,
                Frequency freq = Frequency::PASS,
                eGPUSamplerState sampler = (eGPUSamplerState)GPU_SAMPLER_DEFAULT) // was -1
  {

probably unrelated, but i'll post here as an update: when I tried building with DEBUG and running blender in lldb, it stop with an invalid enum error when creating shaders at startup (`workbench_taa`, `workbench_composite_matcap`, others?). I traced this issue to the default value for the final parameter of `sampler` function in `gpu_shader_create_info.hh`. when I changed the default value from `-1` (which is not a value in `eGPUSamplerState`) to `GPU_SAMPLER_DEFAULT` (see below), lldb no longer stops when creating shaders. however, the Invalid Enum error is still getting set, so this solution does not solve the original problem. ``` Self &sampler(int slot, ImageType type, StringRefNull name, Frequency freq = Frequency::PASS, eGPUSamplerState sampler = (eGPUSamplerState)GPU_SAMPLER_DEFAULT) // was -1 { ```

blender-admin commented

2022-03-29 10:42:03 +02:00

This issue was referenced by 883326040e

This issue was referenced by 883326040ec20a8289e619446147792f62e6aa32

Clément Foucault commented

2022-03-30 15:54:42 +02:00

Changed status from 'Confirmed' to: 'Resolved'

Clément Foucault closed this issue

2022-03-30 15:54:42 +02:00

Clément Foucault self-assigned this 2022-03-30 15:54:42 +02:00

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

OpenGL Invalid Enum #95592