Graphics card crash when writing data to ofFbo

Hi Folks

I have the following function which I use to write a set of data values to an ofFbo object; it seems to work well on most machines:

void testApp::set_localField(ofFbo & targetFbo){
 
    //set up an array of zeroes
    float* data = new float[bufferWidth * bufferHeight * 4];
    memset(data, 0, sizeof(float) * bufferWidth * bufferHeight * 4);
    
    //replace with data where we have it
    int num = field_Data.size();
    for(int i = 0; i<num; i++) set_local(data, i);
    
    int channel = 0;
    //send the array to the fbo texture at the right channel
    if (targetFbo.getNumTextures()>0){
        //crash occurs somewhere between here and end of the function 
        targetFbo.getTexture(channel).bind();
        glTexSubImage2D(GL_TEXTURE_RECTANGLE_ARB, 0, 0, 0, bufferWidth, bufferHeight, GL_RGBA, GL_FLOAT, data);
        targetFbo.getTexture(channel).unbind();
    }

    //crash has occurred by this point
    //clear up after
    delete [] data;
}

It (very specifically) crashes on an intel iris plus chip, but seems to run fine on lots of other models. Ug.
Can anyone suggest what might be causing the crash, and or a way of avoiding it?

Sam

Try running examples/gl/glInfoExample and get a full report out of it.
It might be that you are running out of gpu memory or something. On which OS/IDE is this happening?

Hey, thanks Roy

It’s on a mbp, 15.2, running an intel iris 655, on OSX 12.1.0. I don’t have direct access to it, but it is reporting max buffer width of 16384, which I would have thought meant I was fine memory wise. But I am out of my depth here a bit, and there are a few other fbos assigned.

The thing that I find weird is that the fbo is already assigned, this should just be updating it? or am I misreading something?

S

Hi, I see.

that literally means that you are trying to allocate an fbo (or texture) with a width larger than the max allowed. I have seen this happen, for instance when trying to load fonts with a larger number of characters at a large size.
What is this app intended for?

No, sorry, I wasn’t very clear! I meant it reports a max buffer width of 16384 when I call GL_MAX_TEXTURE_SIZE, or GL_MAX_RECTANGLE_TEXTURE_SIZE. Am only trying to make an fbo of about 1/10th that.

So, I’ve been doing a load more experimenting, and figured out how to force my mbp to use the integrated intel chip instead of the discrete chip; when I do this I can reproduce the crash.

Aaand, weirdly, running on the intel chip seems to be triggering a GPU crash (that reliably occurs on the lines above), when I include the line ofEnableAntiAliasing() elsewhere in the code. Is this a thing? When I delete the call, the app runs fine…

S

Edit. Also, if there is a method or call to definitively find out what is the max ofFbo dims, I’d really love to hear it! Am just guessing with my GL calls there.

Have you tried with a different GL version?
you just set it in the main.cpp

int main( ){
	ofGLWindowSettings settings;
	settings.setGLVersion(3,2);
	ofCreateWindow(settings);
    
	// this kicks off the running of my app
	// can be OF_WINDOW or OF_FULLSCREEN
	// pass in width and height too:
	ofRunApp(new ofApp());

}

Instead of calling this

 if (targetFbo.getNumTextures()>0){
        //crash occurs somewhere between here and end of the function 
        targetFbo.getTexture(channel).bind();
        glTexSubImage2D(GL_TEXTURE_RECTANGLE_ARB, 0, 0, 0, bufferWidth, bufferHeight, GL_RGBA, GL_FLOAT, data);
        targetFbo.getTexture(channel).unbind();
    }

why dont you simply call ?

targetFbo.getTexture(channel).loadData(data,  bufferWidth, bufferHeight, GL_RGBA, GL_FLOAT)

It is almost the same as the direct gl call but with a few extra checks in it. It feels like a safer way to use and make sure that you are passing the correct stuff to the GL command.

Actually loadData gets called whenever you load an ofImage for example, so if loading a large image does not make the app crash then I would say that the problem relies in that direct call to the gl function.

Yeah I updated the call (included it in my other reply); I only found the loadData() one earlier today when I was reading through the ofFbo file. Can’t believe I’ve missed that for the last three years :sob:

Definitely felt safer when I changed it! but the crash still happened until I removed the ofEnableAntiAliasing() call. Might that be messing up how the app handles the fbo objects or something?

well, now you know about loadData. :slight_smile:

ofEnableAntiAliasing() is directly calling glEnable(GL_MULTISAMPLE);
I am not sure how this could affect fbo. as I mentioned before, did you try using a different GL version? that might give a clue on what is going on

Hmmm yeah the different chips do report different max samples, 8 vs 16. Maybe this does trigger something.

I’ll have to put the alternative GL version on the to do list; I’m using a fair few shaders and would have to edit them all to switch GLs, annoyingly

Wonder if anyone else has hit this issue ever