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

[Roland Scheidegger]

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
>