Re: [Mesa-dev] GLSL IR int-to-float pass
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..) Jerome ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] GLSL IR int-to-float pass
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..) 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 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] GLSL IR int-to-float pass
On Wed, May 25, 2011 at 9:41 AM, Keith Whitwell kei...@vmware.com 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..) 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 I am also in favor of getting rid of tgsi, i would prefer having the driver callback into mesa to set informations mesa needs from the shader, for instance that would allow driver to pick where they put attribute (might be a huge win on hw like r6xx or newer) and few others things like that. Cheers, Jerome ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] GLSL IR int-to-float pass
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. Bryan ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] GLSL IR int-to-float pass
On 05/25/2011 12:48 PM, Jerome Glisse wrote: On Wed, May 25, 2011 at 9:41 AM, Keith Whitwell kei...@vmware.com wrote: 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 I am also in favor of getting rid of tgsi, i would prefer having the driver callback into mesa to set informations mesa needs from the shader, for instance that would allow driver to pick where they put attribute (might be a huge win on hw like r6xx or newer) and few others things like that. Cheers, Jerome Even in that case, a GLSL int-to-float pass would still be useful for drivers for hardware that doesn't support integers. Bryan ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] GLSL IR int-to-float pass
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
[Mesa-dev] GLSL IR int-to-float pass
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 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
