[Mesa-dev] Mesa (gallium-msaa): gallium: interface changes for multisampling

[Roland Scheidegger]

On 26.04.2010 21:31, José Fonseca wrote:
> On Mon, 2010-04-26 at 11:34 -0700, Keith Whitwell wrote:
>> On Mon, 2010-04-26 at 11:27 -0700, José Fonseca wrote:
>>> Hi Roland,
>>>
>>> Overall looks good. It's nice to finally have a way to export MSAA
>>> capabilities, and see the pipe_surfaces use being more constrained.
>>>
>>> A few comments inline, but no strong feelings so feel free to do as you
>>> wish.
>>>> diff --git a/src/gallium/include/pipe/p_screen.h b/src/gallium/include/pipe/p_screen.h
>>>> index beff1ae..1bad045 100644
>>>> --- a/src/gallium/include/pipe/p_screen.h
>>>> +++ b/src/gallium/include/pipe/p_screen.h
>>>> @@ -99,10 +99,19 @@ struct pipe_screen {
>>>>     boolean (*is_format_supported)( struct pipe_screen *,
>>>>                                     enum pipe_format format,
>>>>                                     enum pipe_texture_target target,
>>>> -                                   unsigned bindings,
>>>> +                                   unsigned bindings,
>>>>                                     unsigned geom_flags );
>>>>
>>>>     /**
>>>> +    * Check if the given pipe_format is supported with a requested
>>>> +    * number of samples for msaa.
>>>> +    * \param sample_count number of samples for multisampling
>>>> +    */
>>>> +   boolean (*is_msaa_supported)( struct pipe_screen *,
>>>> +                                 enum pipe_format format,
>>>> +                                 unsigned sample_count );
>>> Instead of a new is_msaa_support() I'd prefer see sample_count in
>>> is_format_supported or better, replace both with is_resource_supported
>>> which takes a resource template. But I understand that's a bit beyond
>>> the scope of this change.
>> Is there a reason we'd need this extra flexibility, or do you just
>> prefer having a single interface?  
> 
> No flexibility reason. I'd just prefer a single interface that mirrors
> resource_create.
> 
>> Do we need to be able to say that we can do 8x msaa for 2d rgba8
>> textures, but not cube?  Or some other combination?
> 
> No, not that I know of. I just gave a look at DirectX Caps Viewer on
> NVIDIA, and the above interface seem right for D3D10. But actually for
> D3D9 the ability of supporting non-masked msaa is exported seperately.
> 
> Perhaps we could have a special value for sample_count (e.g., -1) to
> signify non-masked msaa.

Do we really need non-maskable msaa? This is some of the things I
explicitly left out for simplicity, just like quality levels or OGL's
user-supplied coverage value - this isn't exposed directly as the idea
is to merge that with the user-supplied mask (because normal hardware
actually just uses a mask anyway)). But with non-maskable msaa, of
course masks aren't possible at all.
I'm aware that there are some msaa modes which are non-maskable by
nature, but I'm not sure it's worth bothering (nvidia's quincunx comes
to mind, for instance) about them. Of course, there's also hardware
which might not support masks at all, but I think for that we'd better
add a caps query if necessary (there might also be hardware which
doesn't support alpha-to-coverage, coverage value, and alpha-to-one,
which are in theory all required by OGL).

Roland