Hi there,
I’ve been getting this warning from instruments in my own app, so I thought I’d check your render-to-texture demo to see if I was missing something.
I couldn’t see anything obvious, so I ran your demo through instruments and found it also triggered the same warning.
Is this a false issue instruments is throwing up, or are we both doing something wrong?
Here’s the warning message from instruments:
"Texture #5 - Your application made a drawing call using a texture that contains uninitialized data. If a draw call uses uninitialized data, the rendering results are incorrect and unpredictable. One way to fix this issue is to provide image data to any TexImage2D calls instead of a NULL pointer."
I don’t understand this message because, as I understand it, passing a NULL pointer just triggers the image width*height memory to be allocated. I’ve tried calling glClear(GL_COLOR_BUFFER_BIT) immediately afterwards which I assumed would be all I would need to do to “initialize” it, but the warning remains.
Any ideas?
Kind regards,
Andre.
Hi Andre,
I’ve had a look at the RenderToTexture example code. Although the example calls glTexImage2D() will NULL instead of a pointer, the texture is written to by the FBO render to texture pass before it is read by the draw call in the main framebuffer render pass. Because of this, the texture never contains uninitialized data when it’s read.
I suspect the Xcode tool isn’t checking for cases where every texel has been written to by an FBO render. You can safely ignore the warning in this situation.
Regards,
Joe
Thanks Joe,
So in my case, since I’m calling glClear(GL_COLOR_BUFFER_BIT) just after creating the texture and after attaching it to the frame buffer which is also bound at that point, would this qualify as writing to every part of the texture?
The reason I ask is because I’m using the texture to mark highlighted regions on my model. Initially they are all “off” then when those areas are picked they light up.
Andre.
Hi Andre,
Unfortunately, it recognising that a clear was called after the FBO is bound isn’t enough. To detect if every part of the texture is written to, the tool would have to account for the viewport size, scissor regions etc. that may be enabled.
Can you explain your use case for highlighting regions along with screenshots? I take it your use case is causing the same warnings to occur in XCode?
Joe
Hi Joe,
I just ran my code through xcode’s built in GL analyser - which I thought used instruments under the covers anyway - and curiously it does not report the warning.
I had wondered whether it was something to do with mip-mapping - is the system creating mip-levels and expecting me to write to those too? To test this hypothesis I’ve since added this line to my setup of the texture:
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAX_LEVEL_APPLE, 0);
but instruments still reports the error.
With regards to stencil and scissor test I’m not using them. I set the viewport to the size of the texture - the full screen size at the time the texture is created - the texture is recreated on rotations.
The code works really well and i’m happy with it, it’s just this instruments warning has got me worried.
You mention that glClear() is not enough to initialize the texture - looking at my code below, can you see what I am missing to initialize it properly?
I create the “highlight_texture” from scratch in my init_view method.
//create highlight frame buffer
glGenFramebuffers(1, &m_highlightFramebuffer);
glBindFramebuffer(GL_FRAMEBUFFER, m_highlightFramebuffer);
glLabelObjectEXT(GL_FRAMEBUFFER, m_highlightFramebuffer, 0, “Highlight_Framebuffer”);
glGenTextures(1, &m_currentHighlightTexture);
glBindTexture(GL_TEXTURE_2D, m_currentHighlightTexture);
glLabelObjectEXT(GL_TEXTURE, m_currentHighlightTexture, 0, “Current_Highlight_Texture”);
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_LINEAR);
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_LINEAR);
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_CLAMP_TO_EDGE);
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, GL_CLAMP_TO_EDGE);
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAX_LEVEL_APPLE, 0);
glTexImage2D(GL_TEXTURE_2D, 0, GL_RED_EXT, width, height, 0, GL_RED_EXT, GL_UNSIGNED_BYTE, 0);
//attach currentHighlightTexture to the color attachment point of the highlight frame buffer
glFramebufferTexture2D(GL_FRAMEBUFFER, GL_COLOR_ATTACHMENT0, GL_TEXTURE_2D, m_currentHighlightTexture, 0);
//check for GL errors
texSetupError = glGetError();
if (texSetupError) {
ELog(“Current Highlight Texture Set-up Error: [%x]”, texSetupError);
}
status = glCheckFramebufferStatus(GL_FRAMEBUFFER);
if (status == GL_FRAMEBUFFER_COMPLETE) {
ILog(“Created highlight framebuffer [status: %x]”, (int)status);
} else {
ELog(“Framebuffer status: %x”, (int)status);
throw std::runtime_error(“ERROR: Could not create highlight framebuffer”);
}
glViewport(0, 0, width, height);
glClear(GL_COLOR_BUFFER_BIT);
In terms of my use case, i’m using a colourized picking texture to detect touches to an object’s surface. I want to give the user feedback on the pick, so I decided to highlight that region of the object.
In order to do this I create the highlight texture and then use a shader to “switch on” just the parts of it that coincide with the picked region. The highlight texture is then used in the next rendering stage. It can either be used directly as I am doing at present, or as a switch for other shader effects.
As I said, aside from this warning it is all working as expected.
I just need to get this initialization step right.
Any thoughts on what I am missing?
Kind Regards,
Andre.
Hi Joe,
Follow up since my last post.
I’ve fixed the problem by allocating my own memory for the texture and clearing it, then passing this manually initialized memory into glTexImage2D:
std::shared_ptr<std::vector> emptyTex
= std::make_shared<std::vector>(width * height, 0);
glTexImage2D(GL_TEXTURE_2D, 0, GL_RED_EXT, width, height, 0, GL_RED_EXT,
GL_UNSIGNED_BYTE, emptyTex->data());
Not sure if this is the way people usually do it, or if i’m still missing a trick with the API somewhere? It seems a silly thing to have to do for empty memory.
What do you think?
Kind Regards,
Andre.
Hi Andre,
I believe this is an Xcode static analysis bug. The setup in our RenderToTexture Example code is completely valid. I can’t say for certain without knowing the implementation details, but it seems like Xcode is naively assuming that you’ve made a mistake because you’ve chosen to pass NULL as the glTexImage2D data pointer. If the static analysis was implemented correctly, it would recognise that your application is writing a value to every texel within the attachment before its read by the GPU later in the render.
Redundantly allocating memory to workaround the warning is wasteful. I would recommend discussing the issue with Apple in their developer forum and filing a bug report against XCode accordingly.
Regards,
Joe
Hi Joe,
Yes, you’re right, I’ll raise the issue on the Apple dev forums.
Thanks again for your help,
Andre.
You’re welcome 
Joe
Hi Joe,
Yes, you're right, I'll raise the issue on the Apple dev forums.
Thanks again for your help,
Andre.
Hey Andre, how did you get on with Apple on this? This warning has been 'bugging' me for ages also and I'd love to know if they even bothered to look into it or if they are still too busy making new programming languages.
Hi Mysticcoder,
It’s been a while, but I seem to remember filling in a long series of questions as part of the official “bug report”, and then getting nothing back.
It’s something I just ignore now, i’m sure it will get fixed eventually. If it’s bothering you why not report it again. Maybe that will push it up their priorities a bit
Andre.
