Using a CE4100 (with SGX535) platform, I’m trying to generate mipmap on a texture attached to a FBO.
I’m performing a render to texture on my FBO, and then I bind the attached texture to modify its parameters like this :
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_LINEAR);
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_LINEAR_MIPMAP_NEAREST);
The issue is that i get a crash when trying to do this (segfault at 8 ip b805ae21 sp bfbcba20 error 4 in libGLESv2.so[b8046000+58000]) while the same code works perfectly with the PC emulator (under Linux).
Is it a known issue ? Is there a way to avoid it (or may be I’m doing something wrong) ?
Thanks in advance for your answer.
Is the texture you are rendering to a power of 2 texture? If it’s not could you try changing it and seeing if that works?
Yes it is, I’m using 512x512 textures.
This is an odd problem, unfortunately I'm not sure what to tell you about this, however it looks like a driver bug. Could you tell me your driver revision (type 'cat /proc/pvr/version' into a console) and I'll have to file a bug. I'm not sure of how to work around this issue at the moment, but if I come up with anything I'll be sure to let you know!
One thing that might be worth trying is just using different filtering modes, try switching to point sampling (GL_NEAREST and GL_NEAREST_MIPMAP_NEAREST) and see if that works? It's not ideal but it might be a workaround.
Hi again Tobias,
The driver revision I have is this one:
Version 18.104.22.16856 (release) sgx_intel_ce
System Version String: SGX revision = 1.2.1
I tried other filtering modes, and the GL_NEAREST_MIPMAP_NEAREST give me the same crash as above ( segfault at 8 ip b7f95e21 sp bfd092f0 error 4 in libGLESv2.so[b7f81000+58000]).
In fact, it crashes each time I try to auto-generate mipmap using the glGenerateMipmap() call.
GL_NEAREST and GL_LINEAR work well (but then, I don’t use the automatic mipmap generation).
I will try to make a simpler sample code that reproduce the issue if I can… (Tell me if you need it, and if so, how I can send it to you).
Thanks for your help anyway.
There is one other thing I thought that *might* work, though it's a bit of a long shot. When you're calling glTexImage2D I assume you're using NULL as the pixel data argument? If so could you try uploading any generic 512x512 image to it instead?
In the meantime I've submitted this as BRN33822, if a workaround is known I'll pass that on to you. If you could produce a simple piece of sample code that would be quite useful to us, if you could send it to firstname.lastname@example.org we'll be able to pass it on to our drivers team to take a look.
Sorry I couldn't be of more help!
We may have a few suggestions for you but it depends on what you’re actually trying to do. If you could email us at email@example.com we can discuss some options with you to try and make this work!
Thanks for your help.
I’m currently trying to make a smaller sample code that can reproduce the issue.
I will email it to you as soon as possible.
I tried to use a pointer to a generic texel buffer instead of NULL in glTexImage2D, but it didn’t work either.
I’ve just emailed to you a sample code reproducing my issue.
I hope this will help.
Thanks in advance.
Just for posterity, here is the workaround for this bug should any other developers encounter this issue:
There is a simple work around you can do - if you set the
minification filter for the texture to involve MIP Maps right from the
start, the driver should ensure it sets up MIP Maps correctly. This needs to be done before any other texture calls (in particular glTexImage2D), immediately after you bind the texture. So for
and then using this texture in your FBO and generating MIP Maps should get around the problem.