- May 31, 2011 at 1:27 pm #30541
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.June 21, 2011 at 3:48 pm #34924
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?
TobiasJune 22, 2011 at 12:53 pm #34926
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.
Tobias 2011-06-22 12:54:28June 22, 2011 at 1:41 pm #34927
Hi again Tobias,
The driver revision I have is this one:
Version 126.96.36.19956 (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.
SpiquemalJune 22, 2011 at 2:28 pm #34928
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 512×512 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 email@example.com we’ll be able to pass it on to our drivers team to take a look.
Sorry I couldn’t be of more help!
Tobias 2011-06-22 14:29:09June 22, 2011 at 4:44 pm #34929June 23, 2011 at 11:21 am #34930
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.
SpiquemalJune 23, 2011 at 5:53 pm #34931
I’ve just emailed to you a sample code reproducing my issue.
I hope this will help.
Thanks in advance.
SpiquemalDecember 14, 2011 at 9:15 am #34932
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.
Tobias 2011-12-14 11:53:44