Re: [Mesa-dev] Status of the GLSL-TGSI translator, part 2

2011-08-04 Thread Bryan Cain
On 08/04/2011 08:24 AM, Brian Paul wrote:
 On Tue, Aug 2, 2011 at 3:50 PM, Bryan Cain bryanca...@gmail.com 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

2011-08-04 Thread Brian Paul

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 Cainbryanca...@gmail.com  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

2011-08-02 Thread Brian Paul

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


Re: [Mesa-dev] Status of the GLSL-TGSI translator, part 2

2011-08-02 Thread Bryan Cain
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


[Mesa-dev] Status of the GLSL-TGSI translator, part 2

2011-08-01 Thread Bryan Cain
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


Re: [Mesa-dev] Status of the GLSL-TGSI translator

2011-06-23 Thread Brian Paul

On 06/22/2011 08:51 PM, Bryan Cain wrote:

On 06/16/2011 12:43 PM, Brian Paul wrote:

On 06/16/2011 10:34 AM, Bryan Cain wrote:

On Thu, Jun 16, 2011 at 9:08 AM, Brian Paulbri...@vmware.com
mailto:bri...@vmware.com  wrote:


 Looks like nice work, Bryan.

 Just a few minor questions/comments for now:

 1. The st_fragment/vertex/geometry_program structs now have a
 glsl_to_tgsi field.  I did a grep, but I couldn't find where that
 field is assigned.  Can you clue me in?

It's assigned at the end of the get_mesa_program function in
st_glsl_to_tgsi.cpp.


Thanks.  I was using grep glsl_to_tgsi *.[ch]   Duh.



 2. The above mentioned program structs contains an old Mesa
 instruction program AND/OR(?) a GLSL IR.  Do both types of
 representations co-exist sometimes?  Perhaps you could update the
 comments on those structs to explain that.

They used to co-exist, because after my first commit, st_glsl_to_tgsi
still generated Mesa IR in addition to TGSI.  But I removed the Mesa
IR generation in st/mesa: stop generating Mesa IR in
st_glsl_to_tgsi, so now it has either one or the other -
glsl_to_tgsi_visitor for GLSL shaders, Mesa IR programs for everything
else.


OK, can you update the comments with this info?



 3. Kind of a follow-on: for glDrawPixels and glBitmap we take the
 original program code (in Mesa form) and prepend extra
 instructions for fetching the fragment color or doing the fragment
 kill.  Do we always have the Mesa instructions for this?  It seems
 we don't normally want to generate Mesa instructions all the time
 but we still need them sometimes.

No, I didn't realize Mesa did that, and we don't have the Mesa
instructions for GLSL programs anymore.  I'm not sure what the
right way to handle that is.


How hard would it be to edit the IR to insert the extra operations?

For glBitmaps it's basically sample a texture and then do a
conditional fragment kill.  For glDrawPixels we need to sample the
texture representing the image, then apply the pixel transfer ops
(scale/bias, table lookup, etc).  We generate the code for that in
st_atom_pixeltransfer.c.  That program is then concatenated with the
current fragment program with _mesa_combine_program().

If we ever propogate GLSL IR through the gallium interface there's
lots of places where we'll need to do other kinds of IR editing.

-Brian



I've been working on this for the last few days, but there are some
things I still haven't figured out yet.

I've written a function to generate the shader for
glDrawPixels/glCopyPixels in the form of glsl_to_tgsi_instructions, and
I doubt I'll have any problems writing the code to merge those
instructions with an existing shader.However, for the shader to work
correctly, I need to set stfp-glsl_to_tgsi in st_fragment_program, but
all of the fragment program variables in st_atom_pixeltransfer.c and
st_cb_drawpixels.c have the type gl_program or gl_fragment_program.
When do these become st_fragment_program so they can be processed in
st_program.c?


Currently, the extra fields in st_fragment_program are 'tgsi' and 
'variants'.  They only get set/used after the base program's 
translated into tgsi so they're not relevant in the drawpixels / 
pixeltransfer code.




Will I need to move the glsl_to_tgsi attribute into
gl_fragment program and give it a name not specific to the state tracker?


Can't you just replace gl_fragment_program with st_fragment_program in 
the drawpixels and pixeltransfer code?




My other question is that if I don't have this part done before the
merge window closes, would it still be possible to merge the GLSL-TGSI
translator for 7.11 tomorrow or Friday, and for me to fix the
glBitmap/glDrawPixels/glCopyPixels issue in the stable branch before
Mesa 7.11 is released?  It's the only remaining issue I know of with the
GLSL-TGSI translator, and even it's something of a corner case.


I'm kind of on the fence.  Does this bring some real value to the 7.11 
release?  Is there a downside to putting it in 7.12?


I'm going to be on vacation next week and may not be of much help if 
there's any problems.


-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

2011-06-22 Thread Bryan Cain
On 06/16/2011 12:43 PM, Brian Paul wrote:
 On 06/16/2011 10:34 AM, Bryan Cain wrote:
 On Thu, Jun 16, 2011 at 9:08 AM, Brian Paul bri...@vmware.com
 mailto:bri...@vmware.com wrote:


 Looks like nice work, Bryan.

 Just a few minor questions/comments for now:

 1. The st_fragment/vertex/geometry_program structs now have a
 glsl_to_tgsi field.  I did a grep, but I couldn't find where that
 field is assigned.  Can you clue me in?

 It's assigned at the end of the get_mesa_program function in
 st_glsl_to_tgsi.cpp.

 Thanks.  I was using grep glsl_to_tgsi *.[ch]   Duh.


 2. The above mentioned program structs contains an old Mesa
 instruction program AND/OR(?) a GLSL IR.  Do both types of
 representations co-exist sometimes?  Perhaps you could update the
 comments on those structs to explain that.

 They used to co-exist, because after my first commit, st_glsl_to_tgsi
 still generated Mesa IR in addition to TGSI.  But I removed the Mesa
 IR generation in st/mesa: stop generating Mesa IR in
 st_glsl_to_tgsi, so now it has either one or the other -
 glsl_to_tgsi_visitor for GLSL shaders, Mesa IR programs for everything
 else.

 OK, can you update the comments with this info?


 3. Kind of a follow-on: for glDrawPixels and glBitmap we take the
 original program code (in Mesa form) and prepend extra
 instructions for fetching the fragment color or doing the fragment
 kill.  Do we always have the Mesa instructions for this?  It seems
 we don't normally want to generate Mesa instructions all the time
 but we still need them sometimes.

 No, I didn't realize Mesa did that, and we don't have the Mesa
 instructions for GLSL programs anymore.  I'm not sure what the
 right way to handle that is.

 How hard would it be to edit the IR to insert the extra operations?

 For glBitmaps it's basically sample a texture and then do a
 conditional fragment kill.  For glDrawPixels we need to sample the
 texture representing the image, then apply the pixel transfer ops
 (scale/bias, table lookup, etc).  We generate the code for that in
 st_atom_pixeltransfer.c.  That program is then concatenated with the
 current fragment program with _mesa_combine_program().

 If we ever propogate GLSL IR through the gallium interface there's
 lots of places where we'll need to do other kinds of IR editing.

 -Brian


I've been working on this for the last few days, but there are some
things I still haven't figured out yet.

I've written a function to generate the shader for
glDrawPixels/glCopyPixels in the form of glsl_to_tgsi_instructions, and
I doubt I'll have any problems writing the code to merge those
instructions with an existing shader.However, for the shader to work
correctly, I need to set stfp-glsl_to_tgsi in st_fragment_program, but
all of the fragment program variables in st_atom_pixeltransfer.c and
st_cb_drawpixels.c have the type gl_program or gl_fragment_program. 
When do these become st_fragment_program so they can be processed in
st_program.c?  Will I need to move the glsl_to_tgsi attribute into
gl_fragment program and give it a name not specific to the state tracker?

My other question is that if I don't have this part done before the
merge window closes, would it still be possible to merge the GLSL-TGSI
translator for 7.11 tomorrow or Friday, and for me to fix the
glBitmap/glDrawPixels/glCopyPixels issue in the stable branch before
Mesa 7.11 is released?  It's the only remaining issue I know of with the
GLSL-TGSI translator, and even it's something of a corner case.

-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

2011-06-16 Thread Bryan Cain
On Thu, Jun 16, 2011 at 12:46 AM, Dave Airlie airl...@gmail.com wrote:

  On Thu, Jun 16, 2011 at 3:22 PM, Dave Airlie airl...@gmail.com wrote:
  On Thu, Jun 16, 2011 at 7:38 AM, Bryan Cain bryanca...@gmail.com
 wrote:
  My work on the GLSL IR to TGSI translator I announced on the list this
  April is now at the point where I think it is ready to be merged into
  Mesa.  It is stable and doesn't regress any piglit tests on softpipe or
  nv50.
 
  I just pulled it into master here, and got this on build on an F15 box
  with gcc 4.6.0.
 
  g++ -c -o state_tracker/st_glsl_to_tgsi.o
  state_tracker/st_glsl_to_tgsi.cpp -DFEATURE_GL=1 -D_GNU_SOURCE
  -DPTHREADS -DHAVE_POSIX_MEMALIGN -DUSE_EXTERNAL_DXTN_LIB=1
  -DIN_DRI_DRIVER -DGLX_DIRECT_RENDERING -DGLX_INDIRECT_RENDERING
  -DHAVE_ALIAS -DHAVE_XEXTPROTO_71 -DGALLIUM_LLVMPIPE
  -D__STDC_CONSTANT_MACROS -DHAVE_LLVM=0x0208 -I../../include
  -I../../src/glsl -I../../src/mesa -I../../src/mapi
  -I../../src/gallium/include -I../../src/gallium/auxiliary
  -I/usr/include  -DNDEBUG -D_GNU_SOURCE -D__STDC_LIMIT_MACROS
  -D__STDC_CONSTANT_MACROS -g -O2 -Wall -fno-strict-aliasing -fPIC
  -fvisibility=hidden
  state_tracker/st_glsl_to_tgsi.cpp:392:70: error: call of overloaded
  ‘st_src_reg(gl_register_file, int, NULL)’ is ambiguous
  state_tracker/st_glsl_to_tgsi.cpp:392:70: note: candidates are:
  state_tracker/st_glsl_to_tgsi.cpp:103:4: note:
  st_src_reg::st_src_reg(gl_register_file, int, int)
  state_tracker/st_glsl_to_tgsi.cpp:90:4: note:
  st_src_reg::st_src_reg(gl_register_file, int, const glsl_type*)
  gmake[2]: *** [state_tracker/st_glsl_to_tgsi.o] Error 1

 I fixed this by casting NULL to (const glsl_type *)NULL, but not sure
 what the proper answer is,

 With that I get 0 piglit regressions due to this on r600g on evergreen.

 Dave.


Hm, I never got that error with my version of g++ (I think 4.5).  It looks
like it just doesn't know whether NULL is a pointer or an integer (stupid
C++), so casting it to (const glsl_type *)NULL is the correct fix.  I'll
commit a fix for that when I get back to my computer at home.
___
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

2011-06-16 Thread Brian Paul

On 06/15/2011 03:38 PM, Bryan Cain wrote:

My work on the GLSL IR to TGSI translator I announced on the list this
April is now at the point where I think it is ready to be merged into
Mesa.  It is stable and doesn't regress any piglit tests on softpipe or
nv50.

It adds native integer support as required by GLSL 1.30, although it is
currently disabled for all drivers since GLSL 1.30 support is not
complete yet and most Gallium drivers haven't implemented the TGSI
integer opcodes.  (This would be a good time for Gallium driver
developers to add support for TGSI's integer opcodes, which are
currently only implemented in softpipe.)

Developing this necessitated significant changes elsewhere in Mesa, and
some small changes in Gallium.  This means that some of the commits in
my branch probably need to be reviewed by the developers of those
components.

If I had commit access to Mesa, I would create a branch for this work in
the main Mesa repository.  But since I am still waiting on my
freedesktop.org account to be created, I have pushed the latest version
to the glsl-to-tgsi branch of my personal Mesa repository on GitHub:

Git clone URL: git://github.com/Plombo/mesa.git
Web interface for viewing commits:
https://github.com/Plombo/mesa/commits/glsl-to-tgsi

Hopefully my freedesktop.org account will be created soon (I have
already had my account request approved), so that I can push this to a
branch in the central repository.


Looks like nice work, Bryan.

Just a few minor questions/comments for now:

1. The st_fragment/vertex/geometry_program structs now have a 
glsl_to_tgsi field.  I did a grep, but I couldn't find where that 
field is assigned.  Can you clue me in?


2. The above mentioned program structs contains an old Mesa 
instruction program AND/OR(?) a GLSL IR.  Do both types of 
representations co-exist sometimes?  Perhaps you could update the 
comments on those structs to explain that.


3. Kind of a follow-on: for glDrawPixels and glBitmap we take the 
original program code (in Mesa form) and prepend extra instructions 
for fetching the fragment color or doing the fragment kill.  Do we 
always have the Mesa instructions for this?  It seems we don't 
normally want to generate Mesa instructions all the time but we still 
need them sometimes.


4. At least one commit message is slightly mis-named: changes to the 
gallium/util/tgsi/ files were labeled as softpipe.  Not a big deal, 
but maybe be more careful about that.


5. I also see the compilation failure that Dave mentioned.

-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

2011-06-16 Thread Jerome Glisse
On Thu, Jun 16, 2011 at 10:08 AM, Brian Paul bri...@vmware.com wrote:
 On 06/15/2011 03:38 PM, Bryan Cain wrote:

 My work on the GLSL IR to TGSI translator I announced on the list this
 April is now at the point where I think it is ready to be merged into
 Mesa.  It is stable and doesn't regress any piglit tests on softpipe or
 nv50.

 It adds native integer support as required by GLSL 1.30, although it is
 currently disabled for all drivers since GLSL 1.30 support is not
 complete yet and most Gallium drivers haven't implemented the TGSI
 integer opcodes.  (This would be a good time for Gallium driver
 developers to add support for TGSI's integer opcodes, which are
 currently only implemented in softpipe.)

 Developing this necessitated significant changes elsewhere in Mesa, and
 some small changes in Gallium.  This means that some of the commits in
 my branch probably need to be reviewed by the developers of those
 components.

 If I had commit access to Mesa, I would create a branch for this work in
 the main Mesa repository.  But since I am still waiting on my
 freedesktop.org account to be created, I have pushed the latest version
 to the glsl-to-tgsi branch of my personal Mesa repository on GitHub:

 Git clone URL: git://github.com/Plombo/mesa.git
 Web interface for viewing commits:
 https://github.com/Plombo/mesa/commits/glsl-to-tgsi

 Hopefully my freedesktop.org account will be created soon (I have
 already had my account request approved), so that I can push this to a
 branch in the central repository.

 Looks like nice work, Bryan.

 Just a few minor questions/comments for now:

 1. The st_fragment/vertex/geometry_program structs now have a glsl_to_tgsi
 field.  I did a grep, but I couldn't find where that field is assigned.  Can
 you clue me in?

 2. The above mentioned program structs contains an old Mesa instruction
 program AND/OR(?) a GLSL IR.  Do both types of representations co-exist
 sometimes?  Perhaps you could update the comments on those structs to
 explain that.

 3. Kind of a follow-on: for glDrawPixels and glBitmap we take the original
 program code (in Mesa form) and prepend extra instructions for fetching the
 fragment color or doing the fragment kill.  Do we always have the Mesa
 instructions for this?  It seems we don't normally want to generate Mesa
 instructions all the time but we still need them sometimes.

I must be missing something but why do we need to take the original program for
those ?

Cheers,
Jerome
___
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

2011-06-16 Thread Brian Paul

On 06/16/2011 08:41 AM, Jerome Glisse wrote:

On Thu, Jun 16, 2011 at 10:08 AM, Brian Paulbri...@vmware.com  wrote:

On 06/15/2011 03:38 PM, Bryan Cain wrote:


My work on the GLSL IR to TGSI translator I announced on the list this
April is now at the point where I think it is ready to be merged into
Mesa.  It is stable and doesn't regress any piglit tests on softpipe or
nv50.

It adds native integer support as required by GLSL 1.30, although it is
currently disabled for all drivers since GLSL 1.30 support is not
complete yet and most Gallium drivers haven't implemented the TGSI
integer opcodes.  (This would be a good time for Gallium driver
developers to add support for TGSI's integer opcodes, which are
currently only implemented in softpipe.)

Developing this necessitated significant changes elsewhere in Mesa, and
some small changes in Gallium.  This means that some of the commits in
my branch probably need to be reviewed by the developers of those
components.

If I had commit access to Mesa, I would create a branch for this work in
the main Mesa repository.  But since I am still waiting on my
freedesktop.org account to be created, I have pushed the latest version
to the glsl-to-tgsi branch of my personal Mesa repository on GitHub:

Git clone URL: git://github.com/Plombo/mesa.git
Web interface for viewing commits:
https://github.com/Plombo/mesa/commits/glsl-to-tgsi

Hopefully my freedesktop.org account will be created soon (I have
already had my account request approved), so that I can push this to a
branch in the central repository.


Looks like nice work, Bryan.

Just a few minor questions/comments for now:

1. The st_fragment/vertex/geometry_program structs now have a glsl_to_tgsi
field.  I did a grep, but I couldn't find where that field is assigned.  Can
you clue me in?

2. The above mentioned program structs contains an old Mesa instruction
program AND/OR(?) a GLSL IR.  Do both types of representations co-exist
sometimes?  Perhaps you could update the comments on those structs to
explain that.

3. Kind of a follow-on: for glDrawPixels and glBitmap we take the original
program code (in Mesa form) and prepend extra instructions for fetching the
fragment color or doing the fragment kill.  Do we always have the Mesa
instructions for this?  It seems we don't normally want to generate Mesa
instructions all the time but we still need them sometimes.


I must be missing something but why do we need to take the original program for
those ?


Fragment programs apply to glDrawPixels, glCopyPixels, glBitmap.

-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

2011-06-16 Thread Bryan Cain
On Thu, Jun 16, 2011 at 9:08 AM, Brian Paul bri...@vmware.com wrote:


 Looks like nice work, Bryan.

 Just a few minor questions/comments for now:

 1. The st_fragment/vertex/geometry_program structs now have a glsl_to_tgsi
 field.  I did a grep, but I couldn't find where that field is assigned.  Can
 you clue me in?


It's assigned at the end of the get_mesa_program function in
st_glsl_to_tgsi.cpp.



 2. The above mentioned program structs contains an old Mesa instruction
 program AND/OR(?) a GLSL IR.  Do both types of representations co-exist
 sometimes?  Perhaps you could update the comments on those structs to
 explain that.


They used to co-exist, because after my first commit, st_glsl_to_tgsi still
generated Mesa IR in addition to TGSI.  But I removed the Mesa IR generation
in st/mesa: stop generating Mesa IR in st_glsl_to_tgsi, so now it has
either one or the other - glsl_to_tgsi_visitor for GLSL shaders, Mesa IR
programs for everything else.



 3. Kind of a follow-on: for glDrawPixels and glBitmap we take the original
 program code (in Mesa form) and prepend extra instructions for fetching the
 fragment color or doing the fragment kill.  Do we always have the Mesa
 instructions for this?  It seems we don't normally want to generate Mesa
 instructions all the time but we still need them sometimes.


No, I didn't realize Mesa did that, and we don't have the Mesa instructions
for GLSL programs anymore.  I'm not sure what the right way to handle that
is.



 4. At least one commit message is slightly mis-named: changes to the
 gallium/util/tgsi/ files were labeled as softpipe.  Not a big deal, but
 maybe be more careful about that.


I thought only softpipe used tgsi_exec, but I'll keep in mind to be more
careful in the future.
___
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

2011-06-16 Thread Brian Paul

On 06/16/2011 10:34 AM, Bryan Cain wrote:

On Thu, Jun 16, 2011 at 9:08 AM, Brian Paul bri...@vmware.com
mailto:bri...@vmware.com wrote:


Looks like nice work, Bryan.

Just a few minor questions/comments for now:

1. The st_fragment/vertex/geometry_program structs now have a
glsl_to_tgsi field.  I did a grep, but I couldn't find where that
field is assigned.  Can you clue me in?

It's assigned at the end of the get_mesa_program function in
st_glsl_to_tgsi.cpp.


Thanks.  I was using grep glsl_to_tgsi *.[ch]   Duh.



2. The above mentioned program structs contains an old Mesa
instruction program AND/OR(?) a GLSL IR.  Do both types of
representations co-exist sometimes?  Perhaps you could update the
comments on those structs to explain that.

They used to co-exist, because after my first commit, st_glsl_to_tgsi
still generated Mesa IR in addition to TGSI.  But I removed the Mesa
IR generation in st/mesa: stop generating Mesa IR in
st_glsl_to_tgsi, so now it has either one or the other -
glsl_to_tgsi_visitor for GLSL shaders, Mesa IR programs for everything
else.


OK, can you update the comments with this info?



3. Kind of a follow-on: for glDrawPixels and glBitmap we take the
original program code (in Mesa form) and prepend extra
instructions for fetching the fragment color or doing the fragment
kill.  Do we always have the Mesa instructions for this?  It seems
we don't normally want to generate Mesa instructions all the time
but we still need them sometimes.

No, I didn't realize Mesa did that, and we don't have the Mesa
instructions for GLSL programs anymore.  I'm not sure what the
right way to handle that is.


How hard would it be to edit the IR to insert the extra operations?

For glBitmaps it's basically sample a texture and then do a 
conditional fragment kill.  For glDrawPixels we need to sample the 
texture representing the image, then apply the pixel transfer ops 
(scale/bias, table lookup, etc).  We generate the code for that in 
st_atom_pixeltransfer.c.  That program is then concatenated with the 
current fragment program with _mesa_combine_program().


If we ever propogate GLSL IR through the gallium interface there's 
lots of places where we'll need to do other kinds of IR editing.


-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

2011-06-16 Thread Ian Romanick
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 06/15/2011 06:45 PM, Tom Stellard wrote:
 On Wed, Jun 15, 2011 at 04:38:07PM -0500, Bryan Cain wrote:
 My work on the GLSL IR to TGSI translator I announced on the list this
 April is now at the point where I think it is ready to be merged into
 Mesa.  It is stable and doesn't regress any piglit tests on softpipe or
 nv50.

 
 Hi,
 
 First of all, nice work on this.  It's great to have one less IR to deal
 with.  Just two comments:
 
 1. This branch causes a few piglit regressions on R300 because there is no
 optimization pass equivalent to _mesa_simplify_cmp() in st_glsl_to_tgsi(I
 guess technically it's not really an optimization pass, since R300
 needs it to function).  Would you be able to add something similar
 in st_glsl_to_tgsi?  It should be really easy.  You can ping me on irc
 (tstellar) if you have any questions about it.

I'm working on some code that will fix this the right way.  It probably
won't land until after the 7.11 branch.  It's an optimization pass on
the GLSL IR that makes unconditional assignments out of conditional
assignments to variables with no reaching definition.

There's some ugly code in my ud-chains branch.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAk36T6AACgkQX1gOwKyEAw8rkgCfcBd5iuGGx5BZmkAOIrNp4kAG
jpsAn0578akiXTB5gsViWutQxEPElvpi
=LrQK
-END PGP SIGNATURE-
___
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

2011-06-15 Thread Bryan Cain
My work on the GLSL IR to TGSI translator I announced on the list this
April is now at the point where I think it is ready to be merged into
Mesa.  It is stable and doesn't regress any piglit tests on softpipe or
nv50.

It adds native integer support as required by GLSL 1.30, although it is
currently disabled for all drivers since GLSL 1.30 support is not
complete yet and most Gallium drivers haven't implemented the TGSI
integer opcodes.  (This would be a good time for Gallium driver
developers to add support for TGSI's integer opcodes, which are
currently only implemented in softpipe.)

Developing this necessitated significant changes elsewhere in Mesa, and
some small changes in Gallium.  This means that some of the commits in
my branch probably need to be reviewed by the developers of those
components.

If I had commit access to Mesa, I would create a branch for this work in
the main Mesa repository.  But since I am still waiting on my
freedesktop.org account to be created, I have pushed the latest version
to the glsl-to-tgsi branch of my personal Mesa repository on GitHub:

Git clone URL: git://github.com/Plombo/mesa.git
Web interface for viewing commits:
https://github.com/Plombo/mesa/commits/glsl-to-tgsi

Hopefully my freedesktop.org account will be created soon (I have
already had my account request approved), so that I can push this to a
branch in the central repository.

-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

2011-06-15 Thread Kenneth Graunke

Bryan,

Thanks for your work on this!  I'm glad to see GLSL IR-TGSI happening.

A few quick comments on mesa,st/mesa: add native support for integers 
in shaders...


glsl_type::get_vec4_type(base) is equivalent to 
glsl_type::get_instance(base, 4, 1) except that it returns error_type 
instead of NULL.  You might want to use get_instance directly or 
implement get_vec4_type on top of it.


For the ir_unop_u2f, ir_unop_bit_not, ir_binop_lshift, ir_binop_rshift, 
ir_binop_bit_and, ir_binop_bit_xor, and ir_binop_bit_or cases...you 
don't need the glsl_version = 130 check.  These were first introduced 
in GLSL 1.30 and should never occur in prior versions.  (If anything, 
I'd assert instead of emitting nothing.)


--Kenneth
___
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

2011-06-15 Thread Dave Airlie
On Thu, Jun 16, 2011 at 7:38 AM, Bryan Cain bryanca...@gmail.com wrote:
 My work on the GLSL IR to TGSI translator I announced on the list this
 April is now at the point where I think it is ready to be merged into
 Mesa.  It is stable and doesn't regress any piglit tests on softpipe or
 nv50.

For anyone not github aware, I've just pushed the latest branch to
glsl-to-tgsi in the main mesa repo.

Dave.
___
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

2011-06-15 Thread Bryan Cain
On 06/15/2011 04:59 PM, Kenneth Graunke wrote:
 Bryan,

 Thanks for your work on this!  I'm glad to see GLSL IR-TGSI happening.

 A few quick comments on mesa,st/mesa: add native support for integers
 in shaders...

 glsl_type::get_vec4_type(base) is equivalent to
 glsl_type::get_instance(base, 4, 1) except that it returns error_type
 instead of NULL.  You might want to use get_instance directly or
 implement get_vec4_type on top of it.

Thanks, I didn't notice get_instance.  I'll go ahead and make a commit
that removes get_vec4_type and uses get_instance directly instead.


 For the ir_unop_u2f, ir_unop_bit_not, ir_binop_lshift,
 ir_binop_rshift, ir_binop_bit_and, ir_binop_bit_xor, and
 ir_binop_bit_or cases...you don't need the glsl_version = 130 check. 
 These were first introduced in GLSL 1.30 and should never occur in
 prior versions.  (If anything, I'd assert instead of emitting nothing.)

Actually, they already assert when the GLSL version is less than GLSL
1.30 in order to match the behavior of ir_to_mesa.  It might not be
obvious from reading that code the first time, but the break for each of
those cases is inside the glsl_version = 130 block.  When the GLSL
version is 120 or lower for any of those cases, it falls through to the
assertion after ir_binop_round_even.

___
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

2011-06-15 Thread Tom Stellard
On Wed, Jun 15, 2011 at 04:38:07PM -0500, Bryan Cain wrote:
 My work on the GLSL IR to TGSI translator I announced on the list this
 April is now at the point where I think it is ready to be merged into
 Mesa.  It is stable and doesn't regress any piglit tests on softpipe or
 nv50.
 

Hi,

First of all, nice work on this.  It's great to have one less IR to deal
with.  Just two comments:

1. This branch causes a few piglit regressions on R300 because there is no
optimization pass equivalent to _mesa_simplify_cmp() in st_glsl_to_tgsi(I
guess technically it's not really an optimization pass, since R300
needs it to function).  Would you be able to add something similar
in st_glsl_to_tgsi?  It should be really easy.  You can ping me on irc
(tstellar) if you have any questions about it.

2. There are a number of whitespace errors.  Things like spaces and tabs
on empty lines or a mixture of tabs and spaces for indentation.  It
looks like a number of them were inherited from st_mesa_to_tgsi.c, and
I don't think you need to worry about fixing them, but it's
something to keep in mind as you are making more changes.  If you add:

Hilight trailing whitespace
:highlight ExtraWhitespace ctermbg=red guibg=red
:autocmd Syntax * syn match ExtraWhitespace /\s\+$\| \+\ze\t/

to your .vimrc, you'll see what I'm talking about.

-Tom


___
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

2011-06-15 Thread Dave Airlie
On Thu, Jun 16, 2011 at 7:38 AM, Bryan Cain bryanca...@gmail.com wrote:
 My work on the GLSL IR to TGSI translator I announced on the list this
 April is now at the point where I think it is ready to be merged into
 Mesa.  It is stable and doesn't regress any piglit tests on softpipe or
 nv50.

I just pulled it into master here, and got this on build on an F15 box
with gcc 4.6.0.

g++ -c -o state_tracker/st_glsl_to_tgsi.o
state_tracker/st_glsl_to_tgsi.cpp -DFEATURE_GL=1 -D_GNU_SOURCE
-DPTHREADS -DHAVE_POSIX_MEMALIGN -DUSE_EXTERNAL_DXTN_LIB=1
-DIN_DRI_DRIVER -DGLX_DIRECT_RENDERING -DGLX_INDIRECT_RENDERING
-DHAVE_ALIAS -DHAVE_XEXTPROTO_71 -DGALLIUM_LLVMPIPE
-D__STDC_CONSTANT_MACROS -DHAVE_LLVM=0x0208 -I../../include
-I../../src/glsl -I../../src/mesa -I../../src/mapi
-I../../src/gallium/include -I../../src/gallium/auxiliary
-I/usr/include  -DNDEBUG -D_GNU_SOURCE -D__STDC_LIMIT_MACROS
-D__STDC_CONSTANT_MACROS -g -O2 -Wall -fno-strict-aliasing -fPIC
-fvisibility=hidden
state_tracker/st_glsl_to_tgsi.cpp:392:70: error: call of overloaded
‘st_src_reg(gl_register_file, int, NULL)’ is ambiguous
state_tracker/st_glsl_to_tgsi.cpp:392:70: note: candidates are:
state_tracker/st_glsl_to_tgsi.cpp:103:4: note:
st_src_reg::st_src_reg(gl_register_file, int, int)
state_tracker/st_glsl_to_tgsi.cpp:90:4: note:
st_src_reg::st_src_reg(gl_register_file, int, const glsl_type*)
gmake[2]: *** [state_tracker/st_glsl_to_tgsi.o] Error 1

Dave.
___
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

2011-06-15 Thread Dave Airlie
On Thu, Jun 16, 2011 at 3:22 PM, Dave Airlie airl...@gmail.com wrote:
 On Thu, Jun 16, 2011 at 7:38 AM, Bryan Cain bryanca...@gmail.com wrote:
 My work on the GLSL IR to TGSI translator I announced on the list this
 April is now at the point where I think it is ready to be merged into
 Mesa.  It is stable and doesn't regress any piglit tests on softpipe or
 nv50.

 I just pulled it into master here, and got this on build on an F15 box
 with gcc 4.6.0.

 g++ -c -o state_tracker/st_glsl_to_tgsi.o
 state_tracker/st_glsl_to_tgsi.cpp -DFEATURE_GL=1 -D_GNU_SOURCE
 -DPTHREADS -DHAVE_POSIX_MEMALIGN -DUSE_EXTERNAL_DXTN_LIB=1
 -DIN_DRI_DRIVER -DGLX_DIRECT_RENDERING -DGLX_INDIRECT_RENDERING
 -DHAVE_ALIAS -DHAVE_XEXTPROTO_71 -DGALLIUM_LLVMPIPE
 -D__STDC_CONSTANT_MACROS -DHAVE_LLVM=0x0208 -I../../include
 -I../../src/glsl -I../../src/mesa -I../../src/mapi
 -I../../src/gallium/include -I../../src/gallium/auxiliary
 -I/usr/include  -DNDEBUG -D_GNU_SOURCE -D__STDC_LIMIT_MACROS
 -D__STDC_CONSTANT_MACROS -g -O2 -Wall -fno-strict-aliasing -fPIC
 -fvisibility=hidden
 state_tracker/st_glsl_to_tgsi.cpp:392:70: error: call of overloaded
 ‘st_src_reg(gl_register_file, int, NULL)’ is ambiguous
 state_tracker/st_glsl_to_tgsi.cpp:392:70: note: candidates are:
 state_tracker/st_glsl_to_tgsi.cpp:103:4: note:
 st_src_reg::st_src_reg(gl_register_file, int, int)
 state_tracker/st_glsl_to_tgsi.cpp:90:4: note:
 st_src_reg::st_src_reg(gl_register_file, int, const glsl_type*)
 gmake[2]: *** [state_tracker/st_glsl_to_tgsi.o] Error 1

I fixed this by casting NULL to (const glsl_type *)NULL, but not sure
what the proper answer is,

With that I get 0 piglit regressions due to this on r600g on evergreen.

Dave.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev