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

[Bryan Cain]

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.

Bryan