On Tue, Dec 30, 2008 at 20:08, Zack Rusin <za...@vmware.com> wrote: > On Tuesday 30 December 2008 11:05:34 Alex wrote: >> Hello. >> >> I am very new to this mailing list so if I've missed something please >> nicely point it out. >> >> I am reading the source code of the Mesa Cell driver (branch "gallium-0.2") >> and get really confused. >> >> If I read correctly, there are two paths converting TGSI tokens to LLVM IR. >> >> The first one I called "SOA path" (please correct me if a name already >> exists), implemented in tgsi_to_llvmir(), using InstructionSoa and >> StorageSoa classes. If I understand correct, this rendering path is for the >> processor with SIMD ISA (quad), like general CPU, Cell, right? >> >> The second one I refer as non-SOA path, implemented in tgsi_to_llvm(), >> which uses the "non-SOA" version of class Instruction and Storage. This one >> supports sub-programs, function calls, loops, etc. >> >> But the second path is never used in the source code (tgsi_to_llvm() is not >> called anywhere). What is the status of this path? Is it still used and >> actively maintained? > > It's not used anymore. > Essentially both of those should be maintained (soa and aos). I started with > aos because it's semantically a little simpler. I stopped playing it with > though because soa was more important. The derivative instructions in fragment > shaders make the aos layout implementation rather tricky. So to make it all > simple soa is currently used for vertex and fragment shaders. > Dependingly on which way the instruction set of modern gpus is going to head, > aos will either become completely irrelevant soon (more likely) or aos will > get more important. Either way as it stands we should concentrate on soa for > now.
No, not with the current "SOA" code, that code cannot generate LLVM IR that is suitable for GPUs. First we have to be clear about what we're talking about : - first there is the "SOA" code. I'm using quotation marks because it's not SOA, it's SOA for SIMD CPUs (SSE, Altivec...). In its current form, "SOA" only generates horizontal vector code, which isn't suitable for GPUs, actually quite the opposite. - then there is the non SOA code. It emits scalar instructions, which is much better if you want to target GPUs, and we want to get it up to speed to target our beloved GPUs. In any case, here is what should be done in order to move forward : 1. Implement a common interface for generating CPUs and GPU LLVM IR. Basically just hide the underlying architecture type. That should be pretty easy. 2. Kill the SOA vs non-SOA difference. I think the vertex layout should be a driver-specific implementation detail; so that drivers implement what is available on the platform (for example some GPUs might not handle both SOA and AOS, or the path might be too slow...). That second bit is annoying because it touches the Storage* files, and those don't already have a common interface. But if you have weirdo requirements (for example horizontal vectors for SSE generation) that's the only way. Basically this will boil down to finding a proper abstraction for AOS, SOA and the horizontal vector layout . I've been doing 2. a couple of times already, but I don't think I'm there just yet. These days I'm thinking an interface with high level entry points like "give me one work unit" (and leave the "work unit" definition up to the driver) could work though... Stephane ------------------------------------------------------------------------------ _______________________________________________ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
