[Mesa-dev] GLSL IR int-to-float pass

[Eric Anholt]

On Wed, 25 May 2011 16:29:37 -0500, Bryan Cain <bryancain3 at gmail.com> wrote:
> On 05/25/2011 08:41 AM, Keith Whitwell wrote:
> > On Wed, 2011-05-25 at 09:32 -0400, Jerome Glisse wrote:
> >> On Tue, May 24, 2011 at 8:09 PM, Bryan Cain <bryancain3 at gmail.com> wrote:
> >>> Hi,
> >>>
> >>> In the past few days, I've been working on native integer support in my
> >>> GLSL to TGSI translator.  Something that's come to my attention is that
> >>> supporting Gallium targets with and without integer support using a
> >>> single GLSL IR backend will more or less require a GLSL IR pass to
> >>> convert int, uint, and possibly bool variables and operations to floats.
> >>>
> >>> Currently, this is done directly in the backend, in both ir_to_mesa and
> >>> st_glsl_to_tgsi.  However, the mod_to_fract and div_to_mul_rcp lowering
> >>> passes for GLSL IR need to know whether to lower integer modulus and
> >>> division operations to their corresponding float operations.  (They both
> >>> do this in Mesa master without asking the backend, but that will be easy
> >>> to change later.)  So a GLSL IR pass will be needed to do the type lowering.
> >>>
> >>> Such a pass would also have the advantage of less duplicated
> >>> functionality between backends, since ir_to_mesa could also take
> >>> advantage of the pass to eliminate some code.
> >>>
> >>> I'm more than willing to try writing such a pass myself if no one else
> >>> is interested in doing it, but I figure I should make sure there are no
> >>> objections before starting on it.
> >>>
> >>> Bryan
> >> TGSI needs to grow type support (int, uint and possibly int8,16,32..)
> 
> TGSI actually already has opcodes for u32 and s32 operands.  For
> example, UADD, IDIV, ISGE, AND, OR, SHL, MOD, UMOD, etc.
> 
> The problem is that the only driver that supports any of them currently,
> as far as I know, is softpipe.  It will help if support for these
> opcodes is added to the drivers for hardware with integer support.
> 
> > Or go away entirely...
> >
> > I'm not trying to impose a direction on this, but it seems like the GLSL
> > IR->TGSI converter (once running) could be pushed down into the
> > individual drivers and GLSL IR or a close cousin of it could become the
> > gallium-level interface.  Then individual drivers could be modified to
> > consume IR directly.
> >
> > Keith
> 
> The problem with trying to push it into the drivers is that Mesa insists
> that uniforms must be in a prog_parameter list, which the GLSL IR
> backend (i.e., the translator) has to set up.  I've already modified it
> prog_parameter in my branch to support non-float parameters.  I
> initially wanted to remove the dependency, but that idea died when I
> realized just how much all of Mesa depends on it.
> 
> 
> If someone actually does the work to remove the prog_parameter
> dependency from Mesa, then we can consider moving the translator from
> the state tracker into the drivers.

I've also wanted to do that, and never quite succeeded.  I think if I
was attacking it seriously, I'd be storing uniform values, in their
native types, in a structure mimicing the glsl_type hierarchy, pointed
to by the ir_variables (in each target) representing the uniform.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20110525/c4fdb667/attachment.pgp>