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. > Also something that we've discussed before: tgsi transformations are > essentially useful for code that is generic (e.g. like transforming TGSI > into something that follows D3D semantics), while the hardware specific > code is a lot easier to transform in the hardware with a representation > that is most suitable for the given hardware (usually with a couple of > boolean and some kind of an array). That's essentially what we do. You can > think of this as: you code-generate hardware from tgsi, not code-generate > tgsi that is more suited for your hardware from tgsi and code-generate > hardware from that. That's what I ended up doing now, and I'm fine with it. Still, it's not like specific transformations cannot be shared between different hardware. For example, in the Radeon driver, we essentially target three different processors: The vertex shader, the fragment shader of r300 and the fragment shader of r500. These are all quite different, but they do share some characteristics, so we benefit from using the same intermediate representation as long as possible. Of course I'm not familiar with other hardware. Maybe there is simply nothing worth sharing. However, if there is something worth sharing - a kind of toolbox of program transformations that drivers can pick from as needed for their specific hardware - then this clearly needs a shared intermediate representation. cu, Nicolai ------------------------------------------------------------------------------ _______________________________________________ Mesa3d-dev mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
