[Mesa-dev] i965/gen4: Depth buffer setup cleanup

[Pohjolainen, Topi]

On Sun, May 21, 2017 at 06:15:46PM +0300, Pohjolainen, Topi wrote:
> On Sat, May 20, 2017 at 10:29:51PM +0300, Topi Pohjolainen wrote:
> > First this series removes logic considering separate stencil 
> > gen < 6 only code paths (where we always use combined
> > depth-stencil).
> > 
> > Then patch 5 simplifies the workaround we need for aligning
> > depth buffer. On gen < 6 there is no support for telling which
> > mip-level to draw and hence the driver needs to offset the
> > buffer accordingly. Unfortunately hardware also requires
> > aligned buffer offsets forcing the driver to use temporary
> > aligned copies (which are reconciled back into the mipmapped
> > buffer later on).
> > 
> > However, in case of combined depth-stencil there are cases
> > where there is no depth attachment but stencil only (which
> > is also backed by combined depth-stencil). In those cases
> > current logic fails to offset the buffer correctly when the
> > miplevel is already aligned and doesn't need a copy. Driver
> > correctly sets the intra tile offsets (g45 and ilk) but
> > leaves the page aligned offset zero. This gets fixed
> > by patch 5.
> > I considered fixing this first and only then do the
> > cleanups but unfortunately that would make ugly even
> > uglier.
> 
> I take this back, there is a simple fix for this that can be
> backported without the clean-ups. I'm also looking at failures
> in "copyteximage 2D_ARRAY -auto", and I think I might be able to
> provide a fix for those also. So the whole series will get
> another version.

Well, fixing the rendering of arrayed depth is harder. Current logic simply
fails to move individual slice into aligned position. Depth alignment
workaround, brw_workaround_depthstencil_alignment(), detects correctly that a
slice is not aligned and kicks off intel_renderbuffer_move_to_temp(). Only
problem is that this will move the entire level including all the slices in it
(see intel_miptree_copy_teximage()). Therefore, one actually gets identical
array where the slice of interest is in non-aligned offset. The entire move
therefore is in vain.
Fixing this is not trivial, reconciling the temporary move (see
intel_finalize_mipmap_tree()), also relies on intel_miptree_copy_teximage()
which in turn is not built to handle images containing single slices of
arrays.