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

[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 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

[Bryan Cain]

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

[Brian Paul]

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

[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

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

[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

[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 Paulmailto: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

[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 > > 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

[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

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

[Brian Paul]

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

On Thu, Jun 16, 2011 at 9:08 AM, Brian Paul 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

[Bryan Cain]

On Thu, Jun 16, 2011 at 9:08 AM, Brian Paul  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

[Brian Paul]

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

On Thu, Jun 16, 2011 at 10:08 AM, Brian Paul  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

[Jerome Glisse]

On Thu, Jun 16, 2011 at 10:08 AM, Brian Paul  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

[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

[Bryan Cain]

On Thu, Jun 16, 2011 at 12:46 AM, Dave Airlie  wrote:

>  On Thu, Jun 16, 2011 at 3:22 PM, Dave Airlie  wrote:
> > On Thu, Jun 16, 2011 at 7:38 AM, 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.
> >
> > 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

[Dave Airlie]

On Thu, Jun 16, 2011 at 3:22 PM, Dave Airlie  wrote:
> On Thu, Jun 16, 2011 at 7:38 AM, 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.
>
> 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

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

[Dave Airlie]

On Thu, Jun 16, 2011 at 7:38 AM, 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.

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

[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

[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

[Dave Airlie]

On Thu, Jun 16, 2011 at 7:38 AM, 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.

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

[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