On Sat, 2009-07-25 at 02:52 -0700, Nicolai Hähnle wrote: > Am Saturday 25 July 2009 05:15:13 schrieben Sie: > > On Friday 24 July 2009 20:25:19 Nicolai Hähnle wrote: > > > 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. > > > > I'm not sure I understand what you mean by "stream-based nature of TGSI". > > It's just just an array of struct tgsi_token's. So technically you could > > iterate from the back, middle, 2+middle or anything else. Or is the problem > > the fact that you don't know the explicit number of those tokens? That's > > what struct tgsi_shader_info is for (besides the number of tokens, it gives > > you a lot of other very useful things, which could be of course extended if > > you needed more). > > > > Have you looked at tgsi_transform_shader ? If it could simply iterate from > > the back would that, along tgsi_shader_info solve your problem? > > I have looked at tgsi_transform_shader, and if it could iterate from the back > it would already improve things. > > I wonder how you would go about iterating from the back without doing a > forward pass first to figure out where the boundaries of instructions are. As > I see it, TGSI has a similar problem to e.g. x86 opcodes: If you have a > pointer to one instruction, you can more or less easily calculate the offset > to the *next* instruction, but going to the *previous* instruction is mostly > guesswork because instructions are of variable length.
So, first up, you're right that TGSI was designed to transmit programs in a linear form, not to serve as an intermediate representation for program transformation. In all the drivers I've worked on, TGSI gets translated away pretty quickly to the compiler's preferred IR. I think this should be the normal behaviour -- the compiler chooses an IR that suits its own operations and structure, and the driver translates the shaders to that representation as efficiently as possible. So, from that point of view, what you've done (translating to a different IR to TGSI) is normal -- and further, as you put more optimization into your compiler, you'll want to change the IR again & again. Any representation of the shader that you can't evolve alongside the compiler is probably going to become a straight-jacket at some point. Beyond that, I think it's true that everybody has a bit of a love/hate relationship with TGSI, or at least not love so much as tolerance. TGSI had a different genesis to the rest of gallium and different goals -- it was designed to be a lossless/transparent transmission mechanism for shaders, as opposed to the rest of gallium which has tried to pick a "middle-ground" abstraction and map everything onto that. I think there's scope to pull TGSI into line with the rest of gallium, in particular by dropping non-core concepts like condition-codes, extended predication, etc, which double up on other more generic control mechanisms. Unfortunately, the one thing that isn't so easy to remove is the variable-length nature of the token stream. This is there really for one key reason, which is likely to get more important as we go along -- indirect and multi-dimensional array indexing. With geometry shaders, multiple constant buffers, 2 and 3-dimensional array lookups, combined with indirection in one or more dimensions, we end up wanting to support arguments that look like: cb[5][r[4].x + 4] x[r[4].y][r[5].z] This is a near-future requirement, for geometry shaders and DX10/DX11-level functionality, rather than something currently exercised by Mesa. However we're moving pretty rapidly towards it & I don't want to exclude the capability to represent these forms in TGSI. The consequence of supporting this is that fixed-layout instructions become pretty sparse when you try and accomodate all of the permutations, hence the desire for a tokenized representation for transmitting/storing shaders. Personally I'd like to see some changes to TGSI, to make it easier to work with, but I'm not sure that the variable-layout aspect of it will ever go away. Keith ------------------------------------------------------------------------------ _______________________________________________ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
