-----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. 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? ~ C. (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! ~) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkhWy0wACgkQeCCY8PC5utCTswCfUiUC/4MqzkhbtHvJ6pOdMsP8 ZU0AnjZqJfwx9H0nqCrtgS2zb4KHvthm =ZGdu -----END PGP SIGNATURE----- ------------------------------------------------------------------------- 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
