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. Thanks, Nicolai ------------------------------------------------------------------------- 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
