Jerome Glisse wrote:
I use a similar approach. v_swiz contains all the native r300 swizzle values,I've also been working on some fragment program stuff. I have attached what I've done so far, which works quite well with Keith's texenv program generation that's in Mesa cvs. Not all arb_f_p opcodes are implemented, but I think everything's there that the texenv stuff needs.
I was planning on commiting this soon, but you may have a better
approach than I
took so I'll wait a bit.
I have tried a similar approach at first but as swizzle appear it looks awful, i haven't take a deeper look at the way you handle it but you have a bunch of if test like i got in my first version. You certainly have done cleaner version than my first attempt thought.
Anyway now what i have is the stupid way of having a table
for all swizzle case, just for the x,y,z component as w is in
sep an easier reg. Thus i got two tab one for xyz to FPI0_SRC
conv which have a special value for not native format, this
special value in an index in the second tab where i got all the
code for all differents cases (64 cases less 7 of native format).
This consumes few bytes about 1ko...
aswell as a couple of cases where we have to handle them specially. The
non-native cases have v_swiz->native set to GL_FALSE.
What I do is firstly loop through checking for matches of XYZ. If we match all
three components, the code will return a pfs_reg_t with v_swz/s_swz set to
a native type. Otherwise, we continue looping through the different outmasks
doing multiple emits to another temp until we have the desired value.
Thus what we may do is use this table or use your swizzle
function. Table lookup are faster but we doesn't have to translate
code often, no ?
The code is only translated once. In the case of the texenv stuff, whenever it needs to be regenerated Mesa will call r300ProgramStringNotify to tell us that the program has changed.
I once had this in the code, but ended up stripping it down to iron out someAnyway other part of the code is basicly the same, yours is in a more advanced state than mine thus we should use yours...
Anyone have strong feeling on this swizzle thing ? Or even an magic idea with a magic bitwise formula :)
One other interesting feature is reuse of temp register at some point i was thinking of adding a free_temp function and having a stack of free register. Then get_temp first take from the stack if not empty, or use a new temp if empty.
This get/free approach is usefull with swizzling where you know
that you will use a temps register only for 1 instruction. But there
may be case where you reuse the same swizzled src.
bugs. Now that I know that it mostly works correctly, I should be able to add
this back in easily enough. Rather than using a stack, I'm using a bitfield to
track register allocations. Freeing a register is as easy as setting the bit to
0. Care must be taken not to cause texture indirections by reusing an already
used temp as the destination for a TEX instruction (that's what rp->used_this_node
is/was for)
No, you haven't missed anything. This was another case where I quickly hackedI am wondering if you emit_const_swizzle may not consume all const if say you have an const which is used in all of the 64 possibles swizzle... I may have miss something on that thought.
But if we know that we will only use the const in a swizzled format
then your solution is the best.
something up. Constant swizzles should/could be handled exactly the same as
temp swizzles. In the swizzling code you just have to be careful that reg->type is
set correctly depending on whether or not it's a native swizzle.
I got other idea on optimizing this swizzling in program translation
(basicly tracking operand). But this are maybe useless optimization for
time being...
I've thought of similar things, but haven't attempted anything yet.
I also need to take another look at the generated code, to make sure that combining
the xyz and w instuction streams is working as I intended. When I first integrated
my test code into r300_dri it was, but I've changed much since then.
Cheers, Ben Skeggs.
Jerome Glisse
------------------------------------------------------- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_idt12&alloc_id344&op=click -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
------------------------------------------------------- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_id=7412&alloc_id=16344&op=click -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
