On Mon, Jul 30, 2012 at 4:56 PM, Jerome Glisse <j.glisse@xxxxxxxxx> wrote: > On Sun, Jul 29, 2012 at 1:04 PM, Marek Olšák <maraeo@xxxxxxxxx> wrote: >> If we don't need stencil, don't allocate it. >> If we need only stencil (like PIPE_FORMAT_S8_UINT), don't allocate depth. >> >> v2: actually do it correctly > > Big NAK > > We need to allocate stencil and depth no matter what. Otherwise it > will lockup. You can take a look by poisonning the surface and see > that when stencil is disabled or depth is disabled the hw still write > to it. :) If what you say is true, then we're in a big trouble. Regardless of this patch, we're in it right now, because we cannot fully disable depth or stencil if the user binds a NULL zbuffer. That's clearly the kind of issue that cannot be fixed in the allocator code and should be fixed in r600g where the hardware is programmed. I *think* that the correct way to disable Z or stencil is to set the Z_INVALID or STENCIL_INVALID format, respectively, and not by disabling reads and writes. (cc'ing Alex to confirm that if he can). I don't think the hardware designers have added those "invalid" formats just for the lulz. Please see my latest kernel patch "drm/radeon/kms: allow "invalid" DB formats as a means to disable DB" that tries to address this issue. For r600g, I was thinking of allocating a dummy buffer that will be always bound in case the depth or stencil buffer or both are missing. Either way, we should find how to get around this issue without wasting memory, especially when there are other options to try. BTW, before we used this allocator, we allocated the depth and stencil buffers in separate resources. We might need to get back to it in the future if Gallium grows separate depth and stencil buffer bindings. Marek _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
