Re: [Mesa-dev] Status of the GLSL->TGSI translator, part 2
On 08/04/2011 10:53 AM, Bryan Cain wrote: On 08/04/2011 08:24 AM, Brian Paul wrote: On Tue, Aug 2, 2011 at 3:50 PM, Bryan Cain wrote: On 08/02/2011 11:27 AM, Brian Paul wrote: On 08/01/2011 12:38 PM, Bryan Cain wrote: Since Mesa 7.11 is released now, I figure it's time to discuss merging the glsl-to-tgsi branch to master again. The translator is more mature than last time. There are no regressions that I know of on any driver. The code generation has improved so that it's the same as or better than ir_to_mesa in almost every case. It also will still emit TGSI integer opcodes if you change ctx->GLSLVersion from 120 to 130 in st_extensions.c. Driver developers can use this to implement these opcodes in their drivers, since they will be needed for GLSL 1.30 eventually. Are there any objections to merging it to master now? If there aren't, I'll revise some of the commit messages for correctness and wrap long lines since cgit doesn't do that automatically, then merge it after getting approval. Sounds OK to me. I was just skimming over the new stuff - it looks like create_color_map_texture() is duplicated in two files and could be shared. -Brian Yes, where should the function go and what header should it be declared in? It appears to me that none of the functions in st_atom_*.c are declared directly in header files. How about st_texture.[ch]? That's where st_texture_create() lives. Okay, done. Is there anything else that should be done, or is it ready to merge to master? I have no objections. -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Status of the GLSL->TGSI translator, part 2
On 08/04/2011 08:24 AM, Brian Paul wrote: > On Tue, Aug 2, 2011 at 3:50 PM, Bryan Cain wrote: >> On 08/02/2011 11:27 AM, Brian Paul wrote: >>> On 08/01/2011 12:38 PM, Bryan Cain wrote: Since Mesa 7.11 is released now, I figure it's time to discuss merging the glsl-to-tgsi branch to master again. The translator is more mature than last time. There are no regressions that I know of on any driver. The code generation has improved so that it's the same as or better than ir_to_mesa in almost every case. It also will still emit TGSI integer opcodes if you change ctx->GLSLVersion from 120 to 130 in st_extensions.c. Driver developers can use this to implement these opcodes in their drivers, since they will be needed for GLSL 1.30 eventually. Are there any objections to merging it to master now? If there aren't, I'll revise some of the commit messages for correctness and wrap long lines since cgit doesn't do that automatically, then merge it after getting approval. >>> Sounds OK to me. >>> >>> I was just skimming over the new stuff - it looks like >>> create_color_map_texture() is duplicated in two files and could be >>> shared. >>> >>> -Brian >> Yes, where should the function go and what header should it be declared >> in? It appears to me that none of the functions in st_atom_*.c are >> declared directly in header files. > How about st_texture.[ch]? That's where st_texture_create() lives. Okay, done. Is there anything else that should be done, or is it ready to merge to master? Bryan ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Status of the GLSL->TGSI translator, part 2
On Tue, Aug 2, 2011 at 3:50 PM, Bryan Cain wrote: > On 08/02/2011 11:27 AM, Brian Paul wrote: >> On 08/01/2011 12:38 PM, Bryan Cain wrote: >>> Since Mesa 7.11 is released now, I figure it's time to discuss merging >>> the glsl-to-tgsi branch to master again. The translator is more mature >>> than last time. There are no regressions that I know of on any driver. >>> The code generation has improved so that it's the same as or better than >>> ir_to_mesa in almost every case. >>> >>> It also will still emit TGSI integer opcodes if you change >>> ctx->GLSLVersion from 120 to 130 in st_extensions.c. Driver developers >>> can use this to implement these opcodes in their drivers, since they >>> will be needed for GLSL 1.30 eventually. >>> >>> Are there any objections to merging it to master now? If there aren't, >>> I'll revise some of the commit messages for correctness and wrap long >>> lines since cgit doesn't do that automatically, then merge it after >>> getting approval. >> >> Sounds OK to me. >> >> I was just skimming over the new stuff - it looks like >> create_color_map_texture() is duplicated in two files and could be >> shared. >> >> -Brian > > Yes, where should the function go and what header should it be declared > in? It appears to me that none of the functions in st_atom_*.c are > declared directly in header files. How about st_texture.[ch]? That's where st_texture_create() lives. -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Status of the GLSL->TGSI translator, part 2
On 08/02/2011 11:27 AM, Brian Paul wrote: > On 08/01/2011 12:38 PM, Bryan Cain wrote: >> Since Mesa 7.11 is released now, I figure it's time to discuss merging >> the glsl-to-tgsi branch to master again. The translator is more mature >> than last time. There are no regressions that I know of on any driver. >> The code generation has improved so that it's the same as or better than >> ir_to_mesa in almost every case. >> >> It also will still emit TGSI integer opcodes if you change >> ctx->GLSLVersion from 120 to 130 in st_extensions.c. Driver developers >> can use this to implement these opcodes in their drivers, since they >> will be needed for GLSL 1.30 eventually. >> >> Are there any objections to merging it to master now? If there aren't, >> I'll revise some of the commit messages for correctness and wrap long >> lines since cgit doesn't do that automatically, then merge it after >> getting approval. > > Sounds OK to me. > > I was just skimming over the new stuff - it looks like > create_color_map_texture() is duplicated in two files and could be > shared. > > -Brian Yes, where should the function go and what header should it be declared in? It appears to me that none of the functions in st_atom_*.c are declared directly in header files. Bryan ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Status of the GLSL->TGSI translator, part 2
On 08/01/2011 12:38 PM, Bryan Cain wrote: Since Mesa 7.11 is released now, I figure it's time to discuss merging the glsl-to-tgsi branch to master again. The translator is more mature than last time. There are no regressions that I know of on any driver. The code generation has improved so that it's the same as or better than ir_to_mesa in almost every case. It also will still emit TGSI integer opcodes if you change ctx->GLSLVersion from 120 to 130 in st_extensions.c. Driver developers can use this to implement these opcodes in their drivers, since they will be needed for GLSL 1.30 eventually. Are there any objections to merging it to master now? If there aren't, I'll revise some of the commit messages for correctness and wrap long lines since cgit doesn't do that automatically, then merge it after getting approval. Sounds OK to me. I was just skimming over the new stuff - it looks like create_color_map_texture() is duplicated in two files and could be shared. -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] Status of the GLSL->TGSI translator, part 2
Since Mesa 7.11 is released now, I figure it's time to discuss merging the glsl-to-tgsi branch to master again. The translator is more mature than last time. There are no regressions that I know of on any driver. The code generation has improved so that it's the same as or better than ir_to_mesa in almost every case. It also will still emit TGSI integer opcodes if you change ctx->GLSLVersion from 120 to 130 in st_extensions.c. Driver developers can use this to implement these opcodes in their drivers, since they will be needed for GLSL 1.30 eventually. Are there any objections to merging it to master now? If there aren't, I'll revise some of the commit messages for correctness and wrap long lines since cgit doesn't do that automatically, then merge it after getting approval. Bryan ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev