[LLVMdev] Questions about GPU code generation/ VS development
nijs.daan at gmail.com
Fri Jul 23 02:55:01 PDT 2010
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
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...
More information about the llvm-dev