Zack Rusin wrote: >> Sure, it would be very reasonable to make these target-specific >> builtins when targeting a GPU, the same way we have target-specific >> builtins for SSE. > > Actually currently the plan is to have essentially a "two pass" LLVM IR. I > wanted the first one to never lower any of the GPU instructions so we'd have > intrinsics or maybe even just function calls like gallium.lit, gallium.dot, > gallium.noise and such. Then gallium should query the driver to figure out > which instructions the GPU supports and runs our custom llvm lowering pass > that decomposes those into things the GPU supports. Essentially I'd like to > make as many complicated things in gallium as possible to make the GPU llvm > backends in drivers as simple as possible and this would help us make the > pattern matching in the generator /a lot/ easier (matching gallium.lit vs 9+ > instructions it would be be decomposed to) and give us a more generic GPU > independent layer above. But that hasn't been done yet, I hope to be able to > write that code while working on the OpenCL implementation for Gallium.
Um, whichever. Honestly, I'm gonna do s/R300VS/R300FS/g on my current work, commit it, and then forget about for the next two months while I get a pipe working. I've got a skeleton that does nothing, and I won't do anything else until we're solid on how to proceed. I'm definitely not very experienced in this area, so I defer to you all. R300 Radeons have insts that operate on vectors, and insts that operate only on the .w of each operand. I don't know how to best represent them. So far, the strange (read: non-LLVM) things seem to be: - No pointers. - No traditional load and store concepts. - Only one type, v4f32. - No modifiable stack, no frame pointers, no calling conventions. - No variable-length loops. I can tell you for sure that the ATI HLSL compiler unwinds and unrolls everything, so that they don't have to deal with call and ret. Other than that, I don't know how to handle this stuff. ~ C. ------------------------------------------------------------------------------ _______________________________________________ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
