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?

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.

z



------------------------------------------------------------------------------
_______________________________________________
Mesa3d-dev mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

Reply via email to