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

[Roland Scheidegger]

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 <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
>>>