[Mesa-dev] [PATCH] gallium: add MULTISAMPLE_Z_RESOLVE cap

[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 <sroland at 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.davy at 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
>>