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 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
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
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
Re: [Mesa-dev] Status of the GLSL-TGSI translator
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
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
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
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
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
-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
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
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
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
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
