[LLVMdev] GSoC proposal: TGSI compiler back-end.
currojerez at riseup.net
Mon Apr 22 10:31:42 CDT 2013
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
> 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 . 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.
>  http://cgit.freedesktop.org/piglit
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 . 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
If it's OK I'll be preparing a more formal proposal during the next few
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 229 bytes
Desc: not available
More information about the LLVMdev