As anyone visiting #radeon could see, I occasionally vented my frustration at TGSI while working on refactoring the r300 program compiler for use in Gallium.
Now to give you a bit of background: Radeon hardware is quite quirky, to the point that several hardware-specific optimizations in the program compiler are absolutely vital. Without those optimizations, we wouldn't even be able to implement the fixed function pipeline correctly! Among those hardware-specific optimizations are reordering texture instructions and being extra-careful about which components of each vector are used where so that we do not waste opportunities for native swizzling and pairing of RGB instructions with A instructions. So I'm sure you understand that I was advocating against reimplementing the compiler for Gallium, and for sharing the compiler code. This opens the interesting question as to what the internal representation for programs should be in a piece of code that is used both by classic Mesa and by a Gallium driver. I honestly wanted to use TGSI-based stuff for this. In the end I didn't; here are the reasons. Most importantly and crucially, the stream-based nature of TGSI is, in my opinion, harmful. Essentially, it forces one to use only forward-scan-based algorithms that look at one single instruction at a time. Our pre-existing Radeon compiler uses both backward scanning algorithms and an algorithm that keeps an arbitrary number of instructions in flight at any time. There are also rewritings that greatly benefit from being able to jump backwards and forwards in the instruction stream. So with TGSI there are two options: 1. Redesign the algorithm. While this would be possible, I am rather suspicious of a data structure that forces a particular choice of algorithm. 2. Decode the entire stream into an array of full instructions, then perform the algorithm in question, then re-encode the stream. While this is also obviously possible, it raises another question, namely: What's with all the constant decoding and re-encoding in TGSI anyway? Especially considering that, due to non-flexible allocation of tokens, pretty much all the places where this is done are either incorrect, or they use some magic guesswork for the number of tokens in the resulting stream. Neither makes me particularly happy. In the end, TGSI is only bearable to work with in its non-stream form. I briefly considered working with an array or similar or tgsi_full_instructions. After taking a more detailed look at that structure, I decided against it. It's all nice and cool that "extended swizzle information" is stored in an extended token while in the TGSI token. However, this is *completely irrelevant* to somebody who simply wants to implement program transformations. When I try to figure out whether a particular swizzle can be represented natively or not, I do *not* care whether the swizzle information is stored in the instruction token or in some extension token. Same goes for negate information. tgsi_full_instruction should not force me to care. Yes, there are utility functions for this, but I can just use prog_instruction and reuse existing code where such utility functions simply aren't needed. In the end, what I use as representation is a doubly linked list of prog_instructions, together with a very tiny set of additional data about inputs, outputs, and constants. Having all instructions available at the same time offers great flexibility in the choice of algorithm. I briefly hesitated between an array and a doubly linked list. In the end, I opted for the linked list for two reasons: . It simplifies memory management, especially in conjunction with memory pools (see my earlier mail about those) . It allows some nifty instruction rewrites. For example, there is no way I could write r300_transform_TEX as cleanly as it is now with an instruction array. While my criticism of the stream-based nature goes to the core of TGSI, the fact that I use prog_instruction instead of tgsi_full_instruction runs less deep. In principle, I could switch the code over to use tgsi_full_instruction, but I don't really want to because the latter are so darned impractical. Of those, that can be fixed, by essentially making tgsi_full_instruction more similar to prog_instruction. So there you have it. I'll be happy to answer questions in some of my reasons require clarification. cu, Nicolai Am Saturday 25 July 2009 01:45:12 schrieb Nicolai Hähnle: > I have spent some time refactoring the r300 classic Mesa shader compiler > (backend) to be more or less independent of Mesa. The goal is to create a > library that can be used from both classic Mesa _and_ from a Gallium driver > (thus bug fixing and other improvements will be beneficial to both projects > at the same time; in particular, the significant amount of bugfixing that > has already gone into the project will be immediately available to > Gallium). > > The code is at: > > git://anongit.freedesktop.org/~nh/mesa r300-compiler > http://cgit.freedesktop.org/~nh/mesa/log/?h=r300-compiler > > The current state is: > > . More regression testing would be good. > . Almost all assumptions about Mesa in the compiler proper are gone. > . Mesa *is* still used for its instruction printer and prog_instruction and > related structures. > > On top of that, the branch contains a significant cleanup of the vertex > program compiler. > > Internally, the compiler now uses a very simply program representation > based on prog_instruction. Both classic Mesa and Gallium will translate > their input representation into this intermediate representation. The end > result of compilation is a structure full of raw register settings and > translated instructions that can be uploaded to the hardware pretty much > directly. I have some comments with rationale for this (and a rant about > TGSI), as well as a comment about the memory pool structure, which I will > write about in a followup. > > I plan to do some more testing on the branch and then start hooking it up > into the Gallium driver over the next week or so. > > cu, > Nicolai ------------------------------------------------------------------------------ _______________________________________________ Mesa3d-dev mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
