Constructing FrameBuffers is crashing some devices?

[FTLRalph]

So I keep receiving this error in my Google Analytics report from certain devices:

Code: Select all

Thread: GLThread 377, Exception: java.lang.IllegalStateException: frame buffer couldn't be constructed: unknown error 0
at com.badlogic.gdx.graphics.glutils.FrameBuffer.build(FrameBuffer.java:178)
at com.badlogic.gdx.graphics.glutils.FrameBuffer.<init>(FrameBuffer.java:97)

The error points to this code here:

Code: Select all

try
{
   _frameBuffer= new FrameBuffer(Format.RGBA4444, (int)getWidth(), (int)getHeight(), false);
}
catch (IllegalStateException e)
{
   _frameBuffer= new FrameBuffer(Format.RGBA8888, (int)getWidth(), (int)getHeight(), false); // This line, specifically, meaning the above also must fail but is caught by the try/catch
}

I originally added the try/catch because I thought these devices were crashing because they didn't support Format.RGBA4444. However, that's apparently not the case since they're still crashing with Format.RGBA8888.

Here are two of the devices that report this error (there are a few more, here are just two):
Acer Iconia Tab A100
Acer Iconia Tab A200

Anyone have any ideas? Appreciate it!

[FTLRalph]

Alright, so I found this in the OpenGL wiki:

Warning: NVIDIA's OpenGL driver has a known issue with using incomplete textures. If the texture is not texture complete, the FBO itself will be considered GL_FRAMEBUFFER_UNSUPPORTED​, or will have GL_FRAMEBUFFER_INCOMPLETE_ATTACHMENT​. This is a driver bug, as the OpenGL specification does not allow implementations to return either of these values simply because a texture is not yet complete. Until this is resolved in NVIDIA's drivers, it is advised to make sure that all textures have mipmap levels, and that all glTexParameteri​ values are properly set up for the format of the texture. For example, integral textures are not complete if the mag and min filters have any LINEAR fields.

The devices I listed in my above post have nvidia GPU's. I'm going to go ahead and assume this isn't a coincidence.

However, I would like to come up with a way around this. Can someone more knowledgeable lend some insight on how to go about constructing a FrameBuffer on these types of devices?

[slebed]

Have you tried passing a mipmap texture to the framebuffer as suggested in the warning? Are the devices still crashing with this?

[FTLRalph]

I overlooked that as I didn't see a way to construct a FrameBuffer and specify anything about mipmaps at the same time, however, upon looking further into FrameBuffer, it seems I may have to override the class and provide my own function for:

Code: Select all

/** Override this method in a derived class to set up the backing texture as you like. */
protected void setupTexture () {
   colorTexture = new Texture(width, height, format);
   colorTexture.setFilter(TextureFilter.Linear, TextureFilter.Linear);
   colorTexture.setWrap(TextureWrap.ClampToEdge, TextureWrap.ClampToEdge);
}

Where I can specify for colorTexture to use mipmaps.

I'm going to give this a try but I won't be able to see if it works until I get the next Google Analytics report in about 24 hours. If anyone more knowledgeable can confirm that I'm playing around with the correct stuff here in the meantime that'd be great.

[FTLRalph]

Alright, I extended FrameBuffer and overrode the setupTexture() function. However, the error seems to still exists.

The suspected issue, from the OpenGL wiki:

Warning: NVIDIA's OpenGL driver has a known issue with using incomplete textures. If the texture is not texture complete, the FBO itself will be considered GL_FRAMEBUFFER_UNSUPPORTED​, or will have GL_FRAMEBUFFER_INCOMPLETE_ATTACHMENT​. This is a driver bug, as the OpenGL specification does not allow implementations to return either of these values simply because a texture is not yet complete. Until this is resolved in NVIDIA's drivers, it is advised to make sure that all textures have mipmap levels, and that all glTexParameteri​ values are properly set up for the format of the texture. For example, integral textures are not complete if the mag and min filters have any LINEAR fields.

(All devices that report this error have a GeForce aka nvidia GPU.)

The error:

Code: Select all

Thread: GLThread 377, Exception: java.lang.IllegalStateException: frame buffer couldn't be constructed: unknown error 0
at com.badlogic.gdx.graphics.glutils.FrameBuffer.build(FrameBuffer.java:178)
at com.badlogic.gdx.graphics.glutils.FrameBuffer.<init>(FrameBuffer.java:97)

How I overrode the setupTexture() function in FrameBuffer, I enabled mipmaps since the quote above mentions it:

Code: Select all

@Override
protected void setupTexture()
{
   colorTexture = new Texture(new PixmapTextureData(new Pixmap(width, height, format), null, true, true));
   colorTexture.setFilter(TextureFilter.Linear, TextureFilter.Linear);
   colorTexture.setWrap(TextureWrap.ClampToEdge, TextureWrap.ClampToEdge);
}

Anyone have some ideas on what else I can try?

[xinaes]

I originally added the try/catch because I thought these devices were crashing because they didn't support Format.RGBA4444. However, that's apparently not the case since they're still crashing with Format.RGBA8888.

Here are two of the devices that report this error (there are a few more, here are just two):
Acer Iconia Tab A100
Acer Iconia Tab A200

Anyone have any ideas? Appreciate it!

FWIW, I've found that some devices crash making an RGB888 FBO but RGB565 seems safe (I've been testing an unreleased app just among Facebook friends, so not a massive sample). I'm not aware if my app has even been tested on any devices with nVidia hardware come to think of it...

I might have some more thoughts at some point. This thread seems relevant to my interests...

[tenfour04]

If you're targeting Android, I don't think that WARNING note about desktop nVidia GPU's is really applicable. Even if it were, it wouldn't be causing an error that the frame buffer couldn't be constructed...it only says that the frame buffer will not be complete.

@xinaes: If using OpenGL ES 2.0, RGBA8888 is not guaranteed to be supported by the standard, and many Android devices (even high end ones) do not. Read section 4.4.5 here in the spec. It is supported in OpenGL ES 3.0.

If you need alpha, use RGBA4444.

[FTLRalph]

@tenfour04
Yeah, the only reason I think that nvidia warning is applicable is because every single device that reports this error has a GPU "ULP GeForce" (reported by looking up the devices on gsmarena.com).

From FrameBuffer.java:

Code: Select all

if (result == GL20.GL_FRAMEBUFFER_INCOMPLETE_ATTACHMENT)
   throw new IllegalStateException("frame buffer couldn't be constructed: incomplete attachment");
if (result == GL20.GL_FRAMEBUFFER_INCOMPLETE_DIMENSIONS)
   throw new IllegalStateException("frame buffer couldn't be constructed: incomplete dimensions");
if (result == GL20.GL_FRAMEBUFFER_INCOMPLETE_MISSING_ATTACHMENT)
   throw new IllegalStateException("frame buffer couldn't be constructed: missing attachment");
if (result == GL20.GL_FRAMEBUFFER_UNSUPPORTED)
   throw new IllegalStateException("frame buffer couldn't be constructed: unsupported combination of formats");
throw new IllegalStateException("frame buffer couldn't be constructed: unknown error " + result);

I'm getting that last error (with no if-statement). The nvidia warning states that the bug will produce an "unsupported" or an "incomplete attachment", but I'm not getting those errors. So I'm really not sure if the warning is applicable or not, maybe it is just a coincidence all of the problem devices happen to have nvidia GPUs.

Anyway, are you suggesting I use RGBA4444 when constructing the FBO? I actually had that originally, but I was getting some "unsupported combination of formats" error reports (unrelated to this issue I believe). After I implemented the try-catch to catch this error and then construct with an RGBA8888 I no longer received those error reports.

I know xinaes also suggested I use RGB565 above, but if it really was the format that was wrong, wouldn't I get that "unsupported combination of formats" error and not that "unknown error" error?

[FTLRalph]

Actually, after giving the analytics some more time to report more data, it seems this crash is almost completely gone since my last fix attempt.

Instead of getting 4-6 reports of this crash per day, I now only have 2 reports after 2 days - both from the same device (possible even the exact same user), this one: http://www.gsmarena.com/samsung_galaxy_ ... 0-3894.php

I believe it's a German version of the Galaxy Tab 10.1.

I don't know if this crash is now just unique to this one model or this one actual particular device, I'd still like to completely fix it but at least it seems contained.

[xinaes]

I know xinaes also suggested I use RGB565 above, but if it really was the format that was wrong, wouldn't I get that "unsupported combination of formats" error and not that "unknown error" error?

I wasn't necessarily suggesting you should use it (particularly as alpha might be important to you), just mentioning my own experience in case it was relevant. Also, yes, I think whenever it didn't work for me with RGB888 it was indeed "unsupported combination of formats" that I saw.