I apologize for the last mail, since it's tone was probably too inflammatory
(I leave final judgement on that to others).
Bottom line: I believe TGSI is good for *communicating* programs, but it's
needlessly complicated for *transforming* programs.
If you want to transform a list of instructions, it seems the most logical
thing to me is to store them as just that: a list of instructions. I don't
care much about the details, so if somebody wants to introduce a nice way of
storing a list of instructions that is driver-agnostic, I'd be happy to change
the Radeon code even if the new structure is slightly different from what the
Radeon driver is currently using. The unstructured TGSI token stream is not
it, though.
And now:
<nha> swear to myself: no more mails or discussions on the TGSI topic from now
on
Am Saturday 25 July 2009 18:55:09 schrieb Zack Rusin:
> 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
