On Mon, Jul 30, 2012 at 11:48 AM, Marek Olšák <maraeo@xxxxxxxxx> wrote: > 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. That is correct. I just verified with the hw team. If you allocate both buffers there are some restrictions in that they share tiling parameters, but you can set either buffer to _INVALID and allocate one or the other independently. Alex > > 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 _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
