wined3d: Bind device framebuffer in ActivateContext

[Roderick Colenbrander]

> > On Nov 25, 2007 7:15 AM, Stefan Dösinger <stefan at codeweavers.com>
> wrote:
> > > Am Sonntag, 25. November 2007 00:07:15 schrieb Allan Tong:
> > > > Fixes failures in visual tests for ddraw and d3d8 when using FBO
> > > > offscreen rendering mode.
> > > >
> > > >  - Allan
> > >
> > > This doesn't look right to me. It will most likely break overall FBO
> > > support.
> > >
> > > There is indeed a problem with the fbo and ActivateContext
> integration,
> > > but fixing this is more involved than just setting the framebuffer to
> 0.
> >
> > Any hints where to start looking?  The way I understand it,
> > ActivateContext will only try to set the draw buffer to GL_FRONT,
> > GL_BACK, or GL_AUX0, which should mean that at some point before that,
> > the framebuffer would need to be set to 0, or do I have that wrong?
> > Or is it that I didn't reset the framebuffer back to its previous
> > value?
> The framebuffer setup should be merged with ActivateContext, but not by
> simply 
> setting the framebuffer to 0. Currently there are two issues: the one you
> are 
> seeing(the complaints from opengl), and multithreading issues.
> 
> Parts of the code call ActivateContext before setting the fbo: In this
> case 
> you can get errors in glDrawBuffers. Other parts call the fbo setup before
> calling ActivateContext. In this case the app can crash after a rendering 
> thread switch because no GL context is active.
> 
> The whole issue is pretty complex unfortunately. One issue is that we
> cannot 
> select context and drawable separately for onscreen rendering, and pbuffer
> offscreen rendering. In the case of fbos, the drawable can be set without 
> changing the context.
> 
> Another issue is that ActivateContext deals with one buffer only, but with
> fbo 
> we can have multiple simultaneous ones(GL_ARB_draw_buffers, or multiple 
> render targets in d3d speak). In case of onscreen rendering only one
> render 
> target may be active from the d3d side, and in case of back/aux and
> pbuffer 
> offscreen rendering we're limited to one target from the opengl side.
> 
> What has to be done in some way is to merge apply_fbo_state() with 
> ActivateContext. My original idea was to select the primary target and the
> depthstencil buffer in ActivateContext similarly to the existing code, and
> have higher render targets set in the state manager. Unfortunately drivers
> do 
> not like that, and we have to set all color and depth attachments of the
> fbo 
> at once.
> 

Also don't forget that a lot of function calls (especially in surface.c) still mess with glDrawBuffer themselves. For a lot of calls this is redundant.

Roderick
-- 
GMX FreeMail: 1 GB Postfach, 5 E-Mail-Adressen, 10 Free SMS.
Alle Infos und kostenlose Anmeldung: http://www.gmx.net/de/go/freemail