On Dec 17, 2007 6:18 AM, Stefan Dösinger stefan@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