Re: [Mesa3d-dev] [PATCH] gallium: Add a PREDICATE register file.

[Keith W. <ke...@vm...>]

On Fri, 2009-10-30 at 10:19 -0700, michal wrote:
> Brian Paul pisze:
> > Keith Whitwell wrote:
> >   
> >> On Fri, 2009-10-30 at 04:36 -0700, michal wrote:
> >>     
> >>> Keith Whitwell pisze:
> >>>       
> >>>> On Fri, 2009-10-30 at 03:43 -0700, michal wrote:
> >>>>   
> >>>>         
> >>>>> gallium: Add a PREDICATE register file.
> >>>>>
> >>>>> There's already a shader token that allows composition of predicated
> >>>>> instructions (tgsi_instruction_ext_predicate). However, there is no way
> >>>>> one can write to thos predicate registers in the first place.
> >>>>> ---
> >>>>>  src/gallium/include/pipe/p_shader_tokens.h |    1 +
> >>>>>  1 files changed, 1 insertions(+), 0 deletions(-)
> >>>>>
> >>>>> diff --git a/src/gallium/include/pipe/p_shader_tokens.h 
> >>>>> b/src/gallium/include/pipe/p_shader_tokens.h
> >>>>> index de338c4..6aa8b27 100644
> >>>>> --- a/src/gallium/include/pipe/p_shader_tokens.h
> >>>>> +++ b/src/gallium/include/pipe/p_shader_tokens.h
> >>>>> @@ -79,6 +79,7 @@ enum tgsi_file_type {
> >>>>>     TGSI_FILE_ADDRESS     =6,
> >>>>>     TGSI_FILE_IMMEDIATE   =7,
> >>>>>     TGSI_FILE_LOOP        =8,
> >>>>> +   TGSI_FILE_PREDICATE   =9,
> >>>>>     TGSI_FILE_COUNT      /**< how many TGSI_FILE_ types */
> >>>>>  };
> >>>>>     
> >>>>>           
> >>>> Michal,
> >>>>
> >>>> Is your expectation that all drivers become able to understand
> >>>> instructions with predicates?  That seems unreasonable.
> >>>>
> >>>> What is the expected way of setting a predicate register?  What
> >>>> functionality will use this?
> >>>>
> >>>>   
> >>>>         
> >>> For example:
> >>>
> >>> DECL IN[0..1]
> >>> DECL OUT[0]
> >>> DECL PRED[0]
> >>>
> >>> 1: MOV OUT[0], IN[0]
> >>> 2: SGT PRED[0], IN[0], IN[1]
> >>> 3: (PRED[0]) MOV OUT[0], IN[1]
> >>>
> >>> In (2) we set each component of PRED[0] to 1.0 if the corresponding 
> >>> components of IN[0] are greater than IN[1], and to 0.0 otherwise.
> >>> In (3) we write IN[1] to only those components of OUT[0], for which the 
> >>> respective components of PRED[0] are non-zero.
> >>>
> >>>       
> >>>> It seems there are three ways to do conditional execution in TGSI
> >>>> currently -- predicates, condition codes and IF/THEN/ELSE instructions.
> >>>>
> >>>> I'd really prefer to have at most two, and in fact preferably just one.
> >>>> Can you take a look at the three alternatives and figure out if one can
> >>>> be amputated?
> >>>>
> >>>>   
> >>>>         
> >>> We could kill off the condition codes -- no driver uses that, and it's 
> >>> easier for us to emulate them with predicates than the other way round.
> >>>       
> >> I think I agree with that.  Condition codes are pretty wierd, the only
> >> reason I'd keep them around is that there is the NV GPU4 extension
> >> sitting there as a ready-made definition of a high-end SM4-level
> >> assembly language.
> >>
> >> I don't know if Ian plans to introduce a MESA version of the program4
> >> extension that more closely matches his program3 extension (ie
> >> predicates instead of condition codes).
> >>     
> >
> > Just FYI: GL_NV_fragment_program uses condition codes but we haven't 
> > supported that extension with Gallium; only the ARB versions.
> >
> >   
> 
> We could always remove condition codes later, when Ian decides about 
> their future.
> 
> Attached is an updated patch that obsoletes one TGSI token and fixes the 
> other one, so we can specify swizzles and negation of predicate 
> registers, per GL_MESA_gpu_program3.
> 
> Thanks for comments.

OK, I think I'd prefer to remove condition codes as part of this --
there are no users for them (that we care about), and we don't want
drivers to have to implement both techniques.

If in the future we want condition codes in the mesa state tracker,
we'll have to do the work of converting them to predicates and/or
IF/THEN/ELSE, but it will probably less effort than trying to teach all
the drivers about condition codes.

Can I ask for a third version that removes condition codes?

In terms of drivers supporting this, we probably want another pipe_cap
flag, probably PIPE_CAP_GPU3, to indicate that a particular driver has
GPU3/SM3 support.  Can you add that to the interface as well?

Keith