We are currently migrating Bugzilla to GitHub issues.
Any changes made to the bug tracker now will be lost, so please do not post new bugs or make changes to them.
When we're done, all bug URLs will redirect to their equivalent location on the new bug tracker.

Bug 5504 - Default OpenGL framebuffer "0" is not valid
Summary: Default OpenGL framebuffer "0" is not valid
Status: ASSIGNED
Alias: None
Product: SDL
Classification: Unclassified
Component: video (show other bugs)
Version: 2.0.14
Hardware: x86_64 macOS 10.15
: P2 critical
Assignee: Ryan C. Gordon
QA Contact: Sam Lantinga
URL:
Keywords: target-2.0.16
Depends on:
Blocks:
 
Reported: 2021-01-26 02:33 UTC by kagekirin
Modified: 2021-02-03 03:37 UTC (History)
0 users

See Also:

Attachments
Standalone code to reproduce the FBO 0 incomplete issue (11.02 KB, text/x-csrc)
2021-02-03 03:33 UTC, kagekirin 		Details
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description kagekirin 2021-01-26 02:33:14 UTC 
Hi,

this is a bug that I ran into after upgrading to 2.0.14. The same code used to work on 2.0.12.

In my render loop, I have this code:

```
// write to default framebuffer
glBindFramebuffer(GL_FRAMEBUFFER, 0);

int status = glCheckFramebufferStatus(GL_FRAMEBUFFER);
if (status != GL_FRAMEBUFFER_COMPLETE)
{
    fprintf(stderr, "unexpected fbo status: 0x%x\n", status);
    return;
}

glClearColor(0.0f, 0.0f, 0.0f, 0.0f);
glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);

/// render code follows
```

Expected: the default (window) framebuffer is '0' and this code works.
Results:
in 2.0.12: this code works as expected
in 2.0.14: it prints "unexpected fbo status: 0x8219" (0x8219 is the value of 'GL_FRAMEBUFFER_UNDEFINED'), and does not work anymore.

Since the OpenGL documentation (and pretty much every OpenGL example code out there) stipulates that '0' ought to be the default framebuffer, this regression might surprise a lot of developers.

Best regards.
Comment 1 kagekirin 2021-01-26 02:35:57 UTC 
A workaround exists, namely by querying the value of the default framebuffer at program start with `glGetIntegerv(GL_FRAMEBUFFER_BINDING, &defaultFramebuffer);` to use it later with glBindFramebuffer to bind the default FBO.
Comment 2 Ryan C. Gordon 2021-02-01 06:55:44 UTC 
We talked about this briefly on Twitter, but I wanted to follow up because I'm still confused and have never seen this behavior on macOS.

This is the OpenGL 4.1 Core spec on the topic:

"The initial state of DRAW_FRAMEBUFFER and READ_FRAMEBUFFER refers to the default framebuffer.  In order that access to the default framebuffer is not lost, it is treated as a framebuffer object with the name of zero. The default framebuffer is therefore rendered to and read from while zero is bound to the corresponding targets."

Can you tell me some specifics of the app that's causing this problem? Is it using the Core or Compatibility profiles (and if using compat, does this happen if you call glBindFramebufferEXT instead of glBindFramebuffer)? If this is something you can isolate in a small piece of code, can you show me?

Also: does the thing let you draw correctly anyhow, if you bind FBO 0 and either don't call or ignore a failed call to glCheckFramebufferStatus? I have to be honest and say I've never checked FBO 0 for completeness, so maybe macOS changed what happens in this scenario? (Generally you only check FBOs you create yourself for completeness).

--ryan.
Comment 3 kagekirin 2021-02-03 03:33:56 UTC 
Created attachment 4752 [details]
Standalone code to reproduce the FBO 0 incomplete issue
Comment 4 kagekirin 2021-02-03 03:37:31 UTC 
Hi Ryan,

I copy-pasted together a standalone sample code that allows to reproduce the issue. (See previous comment).

Using this, I could reproduce the issue with SDL 2.0.14, and verify that it does not happen with SDL 2.0.12.

Please let me know if you need more info, or if you find that I'm doing something wrong that could be the actual cause of the issue.

Best regards.