Nicolai Hähnle wrote: > Hi everybody, > > as you may have noticed, I committed a refactoring of how our r300 DRI driver > compiles fragment programs, and Corbin Simpson gets credit for adapting those > changes for r500 fragment programs as well. > > My changes use an intermediate representation that is very straightforwardly > based on Mesa's prog_instruction structure. We've had a lot of discussions on > how this relates to TGSI on IRC, and Michel Dänzer asked us to not just keep > the discussion on IRC but post here as well. > > I will restrict myself to summarizing my own point of view and the rationale > for doing what I did. > > I want a compiler infrastructure that can do more than one pass over the > program that is to be compiled. I also want to be able to do passes that are > more complex than a linear walk through instructions while looking at only > one instruction at a time. For example, I'm thinking of: > - a very simple algorithm for dead code elimination that walks through the > program *backwards* > - an algorithm to merge MUL and ADD into MAD > > Given those requirements, it is obvious that some form of immediate > representation is required. I chose not go with anything TGSI-ish for the > following reasons: > > 1. Most of what has actually been written around TGSI appears to be occupied > with parsing and reassembling the token stream. However AFAICT, the token > stream is not really a good IR because walking backwards or jumping around > seems to be impossible. > > 2. The only reasonable, easily-implemented representation I could think of > was > a plain array of instruction structures. > > 3. I would have gone with an array of tgsi_full_instruction instead of an > array of prog_instruction, only I was lazy and didn't feel like changing the > (already-existing) r300_fragprog_emit.c code at the time. > > In fact, I really don't care about prog_instruction vs. tgsi_full_instruction > (except that prog_instruction was obviously the easier way to go), since > those structures seem more or less isomorphic. If the TGSI developers agree > that an array of tgsi_full_instructions is a reasonable intermediate > representation (and will remain a reasonable IR in the future), then the > following might be a good way forward: > > 1. Copy all header files that are necessary for tgsi_full_instruction, and > potentially even helper .c files into the r300 directory. Do NOT copy > anything that is only related to the token stream (i.e. parsing and > reassembly), because we would really only need those things to interface with > a Gallium state tracker. > 2. Migrate radeon_program to use the new structures. > 3. Once Gallium is merged to master > 3a. bring our copies of the files uptodate > 3b. then remove them in favour of linking to the "official" versions of these > files. > 4. Profit!? > > So much for my thoughts. Any input from Gallium developers would be very > welcome. After all, the documentation on TGSI that I've been able to find > only talks about TGSI as a static representation of programs, and not so much > about how it might be used during program transformation (there's this > transformation thing in the tgsi utils, but it only allows looking at one > instruction at a time which is simply not enough). But maybe I'm just missing > something really obvious.
Until you're actually writing a gallium driver, I think it would be confusing to pull the TGSI code into a traditional Mesa driver. The TGSI representation is pretty much intended to be the shader representation that goes through the gallium driver interface. On either side of that interface, we might have other program representations. On the outside, in the mesa/gallium state tracker we translate Mesa programs into TGSI programs. On the inside, in gallium drivers we translate TGSI into x86 code, or hardware GPU instructions. In both places, various code transformations could be done. In the longer term we'd like to use LLVM to do xforms and optimizations. For now, if you want to do transformations based on prog_instruction that's fine. I'd encourage you to put such code into device-independent files in the src/mesa/shader/ directory if possible. It should be reasonably simple to translate code that uses prog_instruction into tgsi_full_instruction when the driver's converted to gallium. -Brian ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php _______________________________________________ Mesa3d-dev mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
