[LLVMdev] Questions about GPU code generation/ VS development

[Villmow, Micah]

Dan,
 I've been working on an OpenCL GPU language code generator for the last two years, so I can answer some of your questions.
1) I would check out the gallium 3d project as they are doing something very similar to this already, but are mainly targeting GLSL and not OpenCL. Support for vectors is very good in LLVM, as long as your vectors are power of 2 in size. Occasionally I run into a problem where vector support is non-existent, but adding it from similar code isn't too much of an issue.
2) LLVM is low level, you might want to look into HLVM for your high level optimizations.
3) I've developed on Mac, Linux and Windows and have not had trouble with LLVM from that perspective.  So there isn't really a problem to worry about here.

Some other things to take into account that are problematic for LLVM that I've ran across. For example, LLVM does not produce 'good' flow control code for vector architecture with the default passes enabled. The passes need to be tweaked to disable many flow control optimizations. Another issue is the fact that the GPU language I am targeting has constant resource ID's and a non-uniform address space. So keeping track of which pointer belongs to which resource ID is very difficult and in some cases impossible at the machine instruction level.

We use a separate compiler for ISA generation/scheduling/register allocation and not LLVM, so I can't comment to deeply on how LLVM works here, but I believe it would be difficult to fix llvm to generate ISA for our GPU architecture as the concepts that the architecture has does not exist in llvm.

Hope this helps,
Micah

From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Daan Nijs
Sent: Friday, July 23, 2010 2:55 AM
To: llvmdev at cs.uiuc.edu
Subject: [LLVMdev] Questions about GPU code generation/ VS development

Hey everyone,

I've been working for a while on a virtual machine/DSL (for lack of a more precise term) specialised for graphics. I hope to allow domain specific optimizations, eg folding together post-processing passes, or automatic LODing for procedural textures. I'm planning to make the renderer itself to be defined at runtime, to allow foward rendering, deferred rendering, raytracing, or a combination of all 3. Of course, this is lot to chew on, so for now it's more of a proof of concept than anything production-ready.

Due to my unfamiliarity with LLVM, I do have some broad questions though. If somebody can answer, or just point me to the relevant documentation/code, I would be very grateful.

Right now I use my own code to schedule between the GPU code (OpenCL and GLSL), and to generate the GPU code. In fact, I only use LLVM to generate the CPU side code.

1. Which steps would it take to implement an OpenCL/GLSL backend to LLVM? What is the level of vector integration in the core? Is there already some work done in this direction I could look at/reuse?
2. Would it make sense to use LLVM to drive the whole compilation process, considering I will operate on high level concepts, eg convolutions, frequency analysis, error metrics? Or should I do break down these things first and then use LLVM for the lower level code?
3. ATM I'm using VS2008 as my environment, and LLVM from head. Timewise, am I shooting myself in the foot? I'm hesitant to switch to another platform, as I have a lot of experience with VS, but I'm unsure how well the LLVM support stacks up to Mac/Linux support.
4. I'm using my own custom 3d engine, which should have it's routines called dynamically. Does this mean I have to run CLang on it to make it callable from LLVM generated code, or should I just be able to call it as as external code?

I apologize in advance if some of these questions are basic or too broad, I recently hit a bit of a brick wall designing the guts of the system, and would love to benefit from the opinion of experienced LLVM users. Thank you for your time.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100723/63ccf994/attachment.html>