Re: [2/2] wined3d: Set the surface location to SFLAG_INSYSMEM for depth stencils on Reset

[Stefan Dösinger]

Am Montag, 2. Juni 2008 21:12:54 schrieb H. Verbeet:
> This fixes a rather major regression when using FBOs for offscreen
> rendering. Since we destroy the GL texture associated with the
> surface, and INDRAWABLE and INTEXTURE are the same for offscreen
> targets when using FBO ORM, the texture would never get recreated for
> the depth stencil. Depth stencils are special in this regard since
> they can switch between being onscreen and offscreen, for the other
> implicit surfaces this isn't an issue. This should also fix bug 12794.
> (This bug does expose issues with the surface management code, but I
> don't think those are fixable before 1.0)
> updateSurfaceDesc releases the allocated system memory, so setting INSYSMEM is 
> dangerous as well since allocatedMemory = NULL. depth stencils are't 
> lockable, so we may get away with that, but it is still dangerous I think

[2/2] wined3d: Set the surface location to SFLAG_INSYSMEM for depth stencils on Reset

[H. Verbeet]

2008/6/2 Stefan Dösinger <stefandoesinger(a)gmx.at>:
> Am Montag, 2. Juni 2008 21:12:54 schrieb H. Verbeet:
> > This fixes a rather major regression when using FBOs for offscreen
> > rendering. Since we destroy the GL texture associated with the
> > surface, and INDRAWABLE and INTEXTURE are the same for offscreen
> > targets when using FBO ORM, the texture would never get recreated for
> > the depth stencil. Depth stencils are special in this regard since
> > they can switch between being onscreen and offscreen, for the other
> > implicit surfaces this isn't an issue. This should also fix bug 12794.
> > (This bug does expose issues with the surface management code, but I
> > don't think those are fixable before 1.0)
> > updateSurfaceDesc releases the allocated system memory, so setting INSYSMEM is
> > dangerous as well since allocatedMemory = NULL. depth stencils are't
> > lockable, so we may get away with that, but it is still dangerous I think

True, but unfortunately I think this is the best we can do without
making more extensive changes to the surface management code.