Although I'm sending this as a GSoC proposal, I'm well aware that the amount of work that a project of this kind involves largely exceeds the scope of the GSoC program. I think that's okay: my work here wouldn't be finished at the end of this summer by any means, it would merely be a start. TGSI is the intermediate representation that all open-source GPU drivers using the Gallium3D architecture understand. Until now it's mainly been used for graphics (vertex and fragment shaders and such), but doing general-purpose computing with it is possible in principle (actually, necessary for GL4), and it's been the object of a number of extensions and improvements during the last couple of years to make it more suitable for that purpose. The objective of the project would be to set a basis for a compiler back-end targeting the TGSI language. The first to be benefited from such a back-end would be the Nouveau nv50 and nve4 drivers, that would get OpenCL support easily without much additional work, other Gallium drivers will also benefit from it as they implement the missing language and API bits. I think a reasonable objective for this summer would be to be able to generate correct TGSI code for a decent subset of the CL tests from the piglit suite [1]. In any case I believe that it would be more important to concentrate on writing a clean code base (that would be likely to be reviewed by others and accepted into mainline in the future) and addressing the main design challenges (ideally with the broadest possible consensus from the community and the least possible quantity of target-specific band-aids working around limitations of the common infrastructure) than to concentrate on feature completeness. Among the issues that have to be addressed is the fact that TGSI is a stack-less architecture (though it seems that some register-based calling convention could be used and some sort of emulated stack could be used for the program's automatic storage), the fact that the language has only limited (if any) support for unstructured control flow (apparently 'Target/R600/AMDGPUStructurizeCFG.cpp' could be helpful if we turned it into a generic transform pass, but I'm not convinced it's the best choice yet), the fact that the language cannot represent any arithmetic or memory access with a word width of less than 32 bits (though that seems less of an issue...), and the fact that the MC layer doesn't seem to fit the object format that Gallium expects right now especially well. Looking forward to your feedback. [1] http://cgit.freedesktop.org/piglit -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 229 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130404/220e8065/attachment.sig>
Francisco Jerez <currojerez at riseup.net> writes:> Although I'm sending this as a GSoC proposal, I'm well aware that the > amount of work that a project of this kind involves largely exceeds the > scope of the GSoC program. I think that's okay: my work here wouldn't > be finished at the end of this summer by any means, it would merely be a > start. > > TGSI is the intermediate representation that all open-source GPU drivers > using the Gallium3D architecture understand. Until now it's mainly been > used for graphics (vertex and fragment shaders and such), but doing > general-purpose computing with it is possible in principle (actually, > necessary for GL4), and it's been the object of a number of extensions > and improvements during the last couple of years to make it more > suitable for that purpose. > > The objective of the project would be to set a basis for a compiler > back-end targeting the TGSI language. > > The first to be benefited from such a back-end would be the Nouveau nv50 > and nve4 drivers, that would get OpenCL support easily without much > additional work, other Gallium drivers will also benefit from it as they > implement the missing language and API bits. > > I think a reasonable objective for this summer would be to be able to > generate correct TGSI code for a decent subset of the CL tests from the > piglit suite [1]. In any case I believe that it would be more important > to concentrate on writing a clean code base (that would be likely to be > reviewed by others and accepted into mainline in the future) and > addressing the main design challenges (ideally with the broadest > possible consensus from the community and the least possible quantity of > target-specific band-aids working around limitations of the common > infrastructure) than to concentrate on feature completeness. > > Among the issues that have to be addressed is the fact that TGSI is a > stack-less architecture (though it seems that some register-based > calling convention could be used and some sort of emulated stack could > be used for the program's automatic storage), the fact that the language > has only limited (if any) support for unstructured control flow > (apparently 'Target/R600/AMDGPUStructurizeCFG.cpp' could be helpful if > we turned it into a generic transform pass, but I'm not convinced it's > the best choice yet), the fact that the language cannot represent any > arithmetic or memory access with a word width of less than 32 bits > (though that seems less of an issue...), and the fact that the MC layer > doesn't seem to fit the object format that Gallium expects right now > especially well. > > Looking forward to your feedback. > > [1] http://cgit.freedesktop.org/piglitPity not to see any interest in this since I brought up the idea two weeks ago. I've uploaded a first attempt at writing a TGSI back-end here [2]. It's able to generate code -- though only in assembly form and with many loose ends still. Also, would it be possible for Tom Stellard (CC'ed) to mentor me? He's been working on the R600 back-end (which is similar in purpose and limitations) and the Mesa/Gallium3D project so he might be the right person? If it's OK I'll be preparing a more formal proposal during the next few days. [2] https://github.com/curro/llvm/commit/a1aad41463c36220f2c5b03645843f39e6bf1b9d -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 229 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130422/4efdff01/attachment.sig>
Francisco Jerez <currojerez at riseup.net> writes:>[...] > Pity not to see any interest in this since I brought up the idea two > weeks ago. I've uploaded a first attempt at writing a TGSI back-end > here [2]. It's able to generate code -- though only in assembly form > and with many loose ends still. > > Also, would it be possible for Tom Stellard (CC'ed) to mentor me? He's > been working on the R600 back-end (which is similar in purpose and > limitations) and the Mesa/Gallium3D project so he might be the right > person? > > If it's OK I'll be preparing a more formal proposal during the next few > days. > > [2] https://github.com/curro/llvm/commit/a1aad41463c36220f2c5b03645843f39e6bf1b9dI'm attaching a preliminary version of my proposal -- would be happy to get some feedback about it. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: llvm-tgsi-backend-proposal.text URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130423/91f152db/attachment.text> -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 229 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130423/91f152db/attachment.sig>