Corbin Simpson wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Brian Paul wrote: >> 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 > > We're looking at writing code that can be quickly and easily ported from > r300 into a radeon pipe driver for Gallium. This FP rewrite makes most > of the porting into easy work. > > I was thinking about how transformations should be done, and whether or > not we should be asking Gallium to do them instead of individual > drivers. For example, I think nearly all drivers would benefit from > transforming LIT into its individual components. > > But if we were to implement, say, combining MUL and ADD into MAD, we > would need a different representation of the shader programs.
Can you elaborate on that? Do you need something more than a simple array of fixed-size instructions? > Would it > be better to do this stuff inside Gallium, or should each driver be > responsible for unpacking and packing shaders as much as they need? With regards to both the LIT and MUL/ADD transformations, I'd prefer to see that kind of thing done in a re-usable gallium/mesa utility function than duplicated in multiple drivers. By packing/unpacking do you mean the TGSI tokenized encode/decode steps? That's already done in TGIS utility routines. BTW, Mesa's GLSL compiler recognizes MUL/ADD combinations and generates MAD automatically. > (Oh, and I've sorta started on radeon for Gallium, although it's going > to take a VERY long time since I am still trying to figure out how it > all works! ~) Understood. -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
