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

[José Fonseca]

On Tue, 2010-04-27 at 08:09 -0700, Roland Scheidegger wrote:
> 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).

There is no hard need AFAIK, so expressing through a caps when the need
arise sounds good to me.

Jose