GL_INVALID_ENUM errors with FBO
hverbeet at gmail.com
Thu Jul 24 02:30:07 CDT 2008
2008/7/24 Vitaliy Margolen <wine-devel at 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.
> 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.
More information about the wine-devel