Ok a cap bit sounds reasonable then I guess. Roland
Am 19.01.2015 um 16:41 schrieb Marek Olšák: > Yes, but it's only supported on r700 and later. This is one of the > things in OpenGL that a lot of hardware (r3xx-r6xx) cannot do. > r300-r500 really doesn't support it. R6xx was designed to support it, > but it doesn't work due to hw bugs. > > Marek > > On Mon, Jan 19, 2015 at 4:31 PM, Roland Scheidegger <srol...@vmware.com> > wrote: >> Ah ok makes more sense that way. This is not really something I'd call >> "resolve" though. (And isn't it already assumed drivers can do the >> blitting of such buffers already for glBlitFramebuffer?) >> >> Roland >> >> Am 19.01.2015 um 16:10 schrieb Marek Olšák: >>> BTW, this is the same as the glBlitFramebuffer behavior for MSAA depth >>> buffers. >>> >>> Marek >>> >>> On Mon, Jan 19, 2015 at 2:18 PM, Axel Davy <axel.d...@ens.fr> wrote: >>>> On 19/01/2015 11:59, Roland Scheidegger wrote : >>>>> >>>>> I always thought you can't resolve z because such an operation just >>>>> makes no sense at all. What the hell does it even mean and how do you do >>>>> it? Color resolve you just interpolate between the value to get rid of >>>>> the aliased edges. But in the depth buffer, these values represent the >>>>> depth information for different objects, an "averaged depth value" >>>>> doesn't really make any sense. Or do you blit not by interpolating but >>>>> taking the most common value per pixel or something? >>>>> bind_sampler_view flag with depth textures OTOH is definitely something >>>>> which can be done and should already work with the existing >>>>> infrastructure, if drivers don't advertize it correctly that's their >>>>> fault. >>>>> >>>>> Roland >>>>> >>>> When a multisampled depth buffer is resolved to a single sample depth >>>> buffer, >>>> only the first sample is copied. >>>> >>>> Perhaps is makes sense to add the cap just to say this behaviour is what >>>> happens with a pipe_blit, >>>> since it is different than the ability to read the texture in a shader, >>>> like >>>> the is_format_supported would indicate. >>>> >>>> Axel Davy >>> _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
