On Mon, Jul 30, 2012 at 1:03 PM, Alex Deucher <alexdeucher@xxxxxxxxx> wrote: > On Mon, Jul 30, 2012 at 12:52 PM, Jerome Glisse <j.glisse@xxxxxxxxx> wrote: >> On Mon, Jul 30, 2012 at 12:16 PM, Alex Deucher <alexdeucher@xxxxxxxxx> wrote: >>> On Mon, Jul 30, 2012 at 12:03 PM, Alex Deucher <alexdeucher@xxxxxxxxx> wrote: >>>> 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. >>> >>> Some further clarifications from the hw team. If you want to have >>> truly independent z and stencil buffers that allows for mixing and >>> matching, you need to make sure that any z and stencil buffer that can >>> be bound together must share the same addressing parameters (except >>> tile split), and you must disable the htile buffer on evergreen and >>> before (DB_Z_INFO.TILE_SURFACE_ENABLE=0) or disable the htile buffer >>> for stencil on cayman and newer >>> (DB_STENCIL_INFO.TILE_STENCIL_DISABLE=1). If you are only interested >>> in unbinding z or stencil independently (but not mixing and matching) >>> then you don't need to the above restrictions on the htile buffer. >>> You can do so by setting the format to INVALID. >>> >>> Alex >> >> Well somehow i can't reproduce might have been fixed by something like >> render backend fix. I should have write down how i saw this back in >> the day. > > I think it was related to tiling. I remember you mentioning something > about that at the time. > > Alex Yeah might be tiling related, surface allocator probably got the bo size right. Cheers, Jerime _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
