[LLVMdev] GSoC proposal: TGSI compiler back-end.

Tue Apr 23 10:51:01 PDT 2013

On Tue, Apr 23, 2013 at 05:14:46PM +0200, Francisco Jerez wrote:
> 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/a1aad41463c36220f2c5b03645843f39e6bf1b9d
>

Hi Francisco,

I would be happy to be a mentor for this project if it is accepted.  I
have a few comments about your proposal:

> I'm attaching a preliminary version of my proposal -- would be happy to
> get some feedback about it.
> 

> GSoC proposal: TGSI compiler back-end.
> 
> - Proposal
> 
> 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, fragment shaders, etc.), 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 to make it more suitable for that purpose.
> 
> The TGSI IR has some peculiarities that are unusual in a typical CPU
> instruction architecture (and slightly annoying to deal with) -- It's
> a vector-centric architecture with a variable set of typeless
> registers, no stack and no proper support for irreducible control
> flow.
> 
> The objective of this project would be to write an LLVM compiler
> back-end with the TGSI IR as target.
> 
> - Benefits
> 
> This back-end is the last piece missing for a working and fully
> open-source implementation of OpenCL running on the nVidia nv50 and
> nve4 architectures -- though there's nothing nVidia-specific in the
> TGSI language, and code generated by this back-end will be expected to
> be usable by any other driver implementing the compute API of
> Gallium3D.
> 
> - Biographical background
> 
> I'm currently a masters student in the field of theoretical physics.
> 
> I've already (successfully) participated in the GSoC program with a
> device driver development project (which had to do with
> reverse-engineering nVidia's TV encoders) mentored by the X.Org
> Foundation in 2009, after that I've remained a frequent contributor to
> the Nouveau and Mesa projects for the next few years.
> 
> Last year I wrote most of an OpenCL implementation running on nVidia
> hardware as part of the X.Org Foundation's EVoC program [1] -- the only
> piece missing being the compiler.
> 
> I've gained some experience with LLVM by writing a proof-of-concept
> TGSI back-end which is minimally working [2] -- the goal of this
> project would be to bring it to a useful state.
> 
> - Timeline
> 
> Summary of the work that would be done:

I'm not sure what the current status of your TGSI backend, but I would
recommend getting assembly generation working first, since this will
enable you to write lit tests.

> 
>   * Get object file generation working.
>     (approx. June 17 - July 8)
> 
>     The output format will be the one expected by Mesa. The
>     implementation will take advantage of the existing MC assembler
>     API as much as possible.
>

Can you elaborate a little more on the output format you will be using?
For example, will you be generating ELF binaries with special metadata
sections (This is what R600 currently does) or will you be creating your
own object format.

>   * Fix handling of the multiple OpenCL address spaces.
>     (approx. July 8 - July 22)
> 
>     Operations on __global, __local, and __private memory will be
>     dealt with using the resource access opcodes, __kernel function
>     parameters will be accessed through a special resource meant for
>     parameter passing, __constant memory will be mapped to constant
>     buffers.
> 
>   * Get function calls working reliably.
>     (approx. July 22 - August 5)
> 
>     This will involve fixing the passing of aggregate types and
>     anything that doesn't fit in a 32-bit register, fixing stack
>     allocations (i.e. the "alloca" instruction), and fixing calls to
>     functions that use the "kernel" calling convention from non-kernel
>     functions.
> 
>   * Get control flow working reliably.
>     (approx. August 5 - August 19)
> 
>     This will involve writing a control flow structurizing pass -- It
>     might be possible to promote the R600 one to a common analysis
>     pass and reuse it.
>

I have a feeling this task may take longer than two weeks.  When you
write the final version of your proposal, I think you should have a
definitive plan for how you will implement the structurization.  Whether
it's reusing existing R600 code (this is my recommendation) or writing
something from scratch.

Also, I would really prefer if your structurization solution was target
independent and could live outside of the backend in the common code,
because a good structurization solution would be a great benefit to the
LLVM project.

>   * Get the missing arithmetic and data conversion instructions
>     working.
>     (approx. August 19 - August 26)
> 
>     Most of the floating point, integer and vector operations required
>     by the OpenCL spec will be functional by the end of this period.
> 
>   * Work on the standard library and intrinsics.
>     (approx. August 26 - September 16)
> 
>     This will involve getting a reasonable subset of the OpenCL
>     standard library working, including math functions, thread
>     synchronisation functions, atomic functions, memory barriers and
>     surface sampling/write-back functions.

I'm assuming you are planning to use libclc (http://libclc.llvm.org) for
this.

While implementing standard library builtins is important, I think this
task may be a little bit outside the scope of this project.  I would
recommend dropping this from the schedule and adding it as a task to
work on if you finish everything else early.  This way you can give
yourself more time to work on the actual backend.
> 
>   * Documentation and remaining clean-up work.
>     (approx. September 16 - September 23)
>

I think your proposal should also include a plan for getting the backend
into mainline LLVM, because this is really the ultimate goal of the
project.  Your plan should include where the code repository will be
stored and how you will engage with the community to help you review
the code.  I think this is really important no just for you, but also
for the LLVM community to know what they need to do as far as helping
get the backend into the main tree.

> By the end of each period all the relevant OpenCL language tests from
> the piglit suite [3] and opencl-example [4] will be expected to pass.
> New tests will be written for implemented features that don't have
> sufficient coverage from the existing test suites.
>

I know you'll be using the nouveau drivers to test this backend on real
hardware, and I think that's OK, but I do think you need to be careful
about not spending too much time fixing bugs in the nouveau driver.  I
think piglit passes is a good goal, but I would also like to see OpenCL
or LLVM IR based lit tests added as a goal, because TGSI code gen
is the main focus of this project.

Thank you for submitting an early draft of your proposal, I think it is
really good to get developer feedback early.  I would encourage you to
continue to submit drafts up until the deadline to maximize the input
you get from LLVM developers.

-Tom

> - Contact information
> 
> Francisco Jerez <currojerez at riseup.net>
> 
> [1] http://www.x.org/wiki/XorgEVoC/GalliumCompute
> [2] https://github.com/curro/llvm
> [3] http://cgit.freedesktop.org/piglit
> [4] http://cgit.freedesktop.org/~tstellar/opencl-example

> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev