gpus_ReturnGuiltyForHardwareRestart

Question

I found more details about the bug. it seems related with the information, gpus_ReturnGuiltyForHardwareRestart. after google it, it seems that there is quite limited information about this bug. Have you ever met this before and know how to solve this?

---

I think it is necessary for me to update what i have found about the crash.

It seems that the crashed described above is not related with subview for that after i disabled all the lines for processing the subview, the crash still happens.

The related code is as follows,

{

    float scissor_x = _xMin;
    float scissor_y = _yMin;
    float scissor_w = _xAdd;
    float scissor_h = _yAdd;
    glEnable(GL_SCISSOR_TEST);
    glScissor(scissor_x, scissor_y, scissor_w, scissor_h);
    computeXY();//process some computation. 

    glDisable(GL_SCISSOR_TEST);
    drawImage();//render the result computed above to the screen.

    _xAdd++;
    _yAdd++;

    _xAdd = (_xAdd > 300) ? 100 : _xAdd;
    _yAdd = (_yAdd > 300) ? 100 : _yAdd;

}

The lines listed above will be called during each frame. I do not know whether there is some requirements for using glscissor(). If the value of _xAdd, _yAdd, is set as invariable, then the program goes successfully. But, if both of them are changed during each frame, the program is sure to crash after a few steps.

I really puzzled about it.

Here is the output of debugger,

(lldb) bt
* thread #1: tid = 0x7262e, 0x337bc94a    libGPUSupportMercury.dylib`gpus_ReturnGuiltyForHardwareRestart + 10, queue = 'com.apple.main-  thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x1)
frame #0: 0x337bc94a libGPUSupportMercury.dylib`gpus_ReturnGuiltyForHardwareRestart + 10

Answer 1

I have solved this problem. When gl_scissor() is called, you have to make sure the pixel/texel, taking part in following computation own effective values. So, before i use gl_scissor(), i will initialize all the FBO buffers to make are that all the pixels or texels own effective value.

Thx.