On Wed, 25 May 2011 16:29:37 -0500, Bryan Cain <bryanca...@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 <bryanca...@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.
pgpftdBhjoyM7.pgp
Description: PGP signature
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
