| Summary: | Some OpenGL drivers don't support DEPTH_ATTACHMENT16 | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Chris Marrin <cmarrin> |
| Component: | WebGL | Assignee: | Kenneth Russell <kbr> |
| Status: | RESOLVED CONFIGURATION CHANGED | ||
| Severity: | Normal | CC: | cmarrin, kalyan.kondapally, kbr, kkinnunen, oliver |
| Priority: | P2 | ||
| Version: | 528+ (Nightly build) | ||
| Hardware: | All | ||
| OS: | OS X 10.5 | ||
|
Description
Chris Marrin
2009-11-24 11:56:45 PST
This should be raised in the WG -- which is the minimum to provide? We don't yet know exactly why this test case is failing. Even after changing it to use DEPTH_ATTACHMENT, which is used by the internal FBO allocated by the WebKit WebGL implementation on OS X, the test still fails on the commit bots. More experimentation is needed to understand why the test is failing. In the various implementations we will probably need to translate DEPTH_ATTACHMENT16 to some other enum better supported on desktop OpenGL. This is legal to do because the get queries explicitly state that the FBO's renderbuffer attachments might be promoted to larger sizes. I'm not sure this has anything to do with DEPTH_ATTACHMENT16. What's happening is that the FBO is not complete, so it's returning an error that says that. Looking at the FBO code in GraphicsContextMac.cpp, I am calling:
::glTexImage2D(GL_TEXTURE_2D, 0, GL_RGBA8, 1, 1, 0, GL_RGBA, GL_UNSIGNED_BYTE, 0);
I notice that in the test case, the third param is RGBA. Maybe that's not legal, and maybe some drivers are more picky about it?
We definitely need to support DEPTH_ATTACHMENT16 since it is required by GLES 2.0. We may have to translate it in some implementations.
(In reply to comment #3) > I'm not sure this has anything to do with DEPTH_ATTACHMENT16. What's happening > is that the FBO is not complete, so it's returning an error that says that. > Looking at the FBO code in GraphicsContextMac.cpp, I am calling: > > ::glTexImage2D(GL_TEXTURE_2D, 0, GL_RGBA8, 1, 1, 0, GL_RGBA, > GL_UNSIGNED_BYTE, 0); > > I notice that in the test case, the third param is RGBA. Maybe that's not > legal, and maybe some drivers are more picky about it? I noticed that difference too. However OpenGL ES doesn't expose the GL_RGBA8 constant, and the ES docs for glTexImage2D indicate that GL_RGBA is the only valid RGBA internal format constant. (GL_RGBA4, etc. are used only for glRenderbufferStorage.) One thing we will need to try is converting a texture's internal format of GL_RGBA to an internal format of GL_RGBA8. RIght, but remember the bots are OpenGL, not OpenGL ES. Maybe as a test you could try passing in the code for RGBA8 and see if that makes a difference? It would be really nice if checkFramebufferStatus gave some decent info about the failure. Ah, I think I may know what the problem is. The error being returned is FRAMEBUFFER_UNSUPPORTED. That's not one of the errors that checkFramebufferStatus is supposed to return. I wonder if it means that the version of OpenGL that is running on that machine does not support FBO's at all? They are an extension in in OpenGL so support is not guaranteed. Perhaps you could add some diagnostics that checks the availability of the FBO extension and fails gracefully if not. It will still fail the test, but with a more clear error message. If that's the case, we will need to implement FBOs on such machines using pbuffers or something. (In reply to comment #6) > Ah, I think I may know what the problem is. The error being returned is > FRAMEBUFFER_UNSUPPORTED. That's not one of the errors that > checkFramebufferStatus is supposed to return. I wonder if it means that the > version of OpenGL that is running on that machine does not support FBO's at > all? They are an extension in in OpenGL so support is not guaranteed. GL_FRAMEBUFFER_UNSUPPORTED is a valid return value from glCheckFramebufferStatus. There's a typo in the man page at http://www.khronos.org/opengles/sdk/docs/man/glCheckFramebufferStatus.xml but the ES 2.0 spec has it right. (See section 4.4, Framebuffer Objects, page 116.) Because the FBO the implementation allocates internally works (the other tests, including your triangle test, pass on the commit bots), I assume we just need to translate some constant or another to one better supported on desktop OpenGL. I'll start experimenting with this shortly. ANGLE handles this now |