On Saturday 25 July 2009 05:52:01 Nicolai Hähnle wrote:
> Am Saturday 25 July 2009 05:15:13 schrieben Sie:
> > 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.
Well, that's fairly trivial. There's a number of things that we could do. A
simple array of markers(essentially just saying which tgsi_token in the array
is a start of a new instruction) in tgsi_shader_info would probably already fix
it, or just changing the padding in tgsi_token to signify that it is a marker.
I'm not sure why you're so afraid to iterate over the shader forward in the
first place. You'll have to do it at some point anyway (from what I understand
in your case that would be to figure out for example whether to shader uses
texture sampling to make a decision whether it needs to be transformed in the
first place).
tgsi_shader_info is supposed to fill that need, so as I mentioned if you need
more things in it we could certainly add them.
So there's really a number of things that we could do and the question just
comes down to, what is most convenient.
Also you could just itertate backwards like this:
void iterate_backwards(struct tgsi_token *tokens)
{
unsigned markers[256];
unsigned num_markers = 0, i, position;
struct tgsi_header header = *(struct tgsi_header *) &tokens[1];
position = 1 + header.HeaderSize;
while (position >= (1 + header.HeaderSize + header.BodySize)) {
struct tgsi_token *itr = &tokens[position];
markers[num_markers] = position;
++num_markers;
position += itr->NrTokens;
}
for(i = num_markers - 1; i >= 0; --i) {
struct tgsi_token *itr = &tokens[markers[i]];
switch (itr->Type) {
case TGSI_TOKEN_TYPE_DECLARATION:
// do something with the declaration
case TGSI_TOKEN_TYPE_IMMEDIATE:
// do something with immediate
case TGSI_TOKEN_INSTRUCTION:
// do something with instruction
}
}
}
obviously untested, but it should give you a picture, of how to do it right
now without any changes anywhere.
> 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.
Yes, as I mentioned, if something is common then it can should be doable with
tgsi_transform. It's really just a question of whether iteration backwards is
so common to make the few lines that it takes to do it right now even easier
and export that ability to the main interface (e.g. add the info that we
compute in beginning to tgsi_shader_info or maybe create
tgsi_backwards_iterate).
z
------------------------------------------------------------------------------
_______________________________________________
Mesa3d-dev mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
