H. Verbeet wrote:
2008/7/24 Vitaliy Margolen wine-devel@kievinfo.com:
I've been trying to track some of the errors that I get with different games. To do that I've added some extra traces and this is what I see:
fixme:d3d_surface:read_from_framebuffer_texture glReadBuffer(0x405) was 0x8ce0 >>>>>>>>>>>>>>>>> GL_INVALID_ENUM (0x500) @ ../../../wine.git/dlls/wined3d/surface.c / 918
0x405 is GL_BACK and 0x8ce0 is GL_COLOR_ATTACHMENT0_EXT. Also when this happens I have an inverted image of the entire screen in the left bottom corner. Is this an indication that we are reading from the wrong surface? Or writing into the wrong surface?
The problem is that GL_BACK isn't a valid read buffer when an FBO is bound. Most of the problem there comes from the fact that apply_fbo_state() should happen inside ActivateContext() rather than before or after it. I'm working on trying to fix this, what I've got so far is at http://bugs.winehq.org/attachment.cgi?id=15013, you might want to give that a try to see if it fixes anything. I've already been told it introduces some other errors though (see bug 14038), so it's not quite ready yet.
Yes the patch does fix the problem for me with at least two programs I've tested - Psychonauts demo and Tomb Raider - Legend demo. And didn't see any side affects. But the full version of Psychonauts crashes after initial videos. Same as it did when we had problems with multi-threaded games.
Attached is the patch that produces the above output. BTW if it looks fine to you guys (that extra TRACE()/FIXME() call overhead) then I can send it to wine-patches as well.
checkGLcall is relatively expensive already, but that's mostly due to the glGetError() it does. I don't think an extra TRACE or FIXME will make it much worse.
I will see if there is a way to add that and also address the issue of the race between two separate messages that Chris was talking about.
Vitaliy.