wined3d: Bind device framebuffer in ActivateContext

[Allan Tong]

On Dec 17, 2007 6:18 AM, Stefan Dösinger <stefan at codeweavers.com> wrote:
> Am Samstag, 15. Dezember 2007 19:19:25 schrieb Allan Tong:
>
> Sorry for the late reply, your mail got stuck in my messy inbox :-(

No problem.

> > The second patch moves FBO draw buffer selection to ActivateContext.
> > For onscreen rendering, not much changes except binding framebuffer 0.
> >  For offscreen rendering, the behavior depends on the specified
> > context usage.  For BLIT and RESOURCE_LOAD, the target surface is
> > attached to dst_fbo and used as the draw buffer.  For DRAWPRIM and
> > CLEAR, I simply call apply_fbo_state.  This assumes that DRAWPRIM and
> > CLEAR will always be used with device->render_targets[0].
> There is a problem with GL_COLOR_ATTACHMENT1_EXT and higher, and the depth
> attachment. You're only applying the first color attachment, but that can
> lead to incomplete fbos, if for example the render target and depth stencil
> are changed. If you're only reapplying the first color attachment, you can
> get a size mismatch, which makes the driver pretty angry and can slow
> everything down.

As far as I can tell, the only thing that's ever attached to
device->dst_fbo is the first color attachment, so I wouldn't think
there's any chance for a size mismatch.  Do I still need to unset the
depth attachment or the higher color attachments?  I'm assuming
there's no reason to have a depth attachment for a blit operation.

> You don't have to apply the fbo state in CTXUSAGE_RESOURCELOAD in theory.
> Resourceload never draws anything, nor does it read from the framebuffer, so
> it should be fine with any drawable / framebuffer.

I left it in since some places call ActivateContext using
CTXUSAGE_RESOURCELOAD but with something other than
device->lastActiveRenderTarget, e.g. SetRenderTarget.  I wasn't sure
if there is any code that's relying on the draw buffer being set by
these calls.

 - Allan