> I use a similar approach. v_swiz contains all the native r300 swizzle
> values,
> 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.
I saw that in code but you still got a loop and test case, your
approach is well thinked. But i think it may be hard to understand
say if you look at it in 2 or 3 month.
Thus the only + arguments for a simple 2tab translation i
propose is that it the easiest thing to understand, moreover
you can easily optimize some swizzling case and don't bother
too much on other... But beside the understanding
of your mixed approach haven't a strong opinion on which solution is the
best...
> 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.
This why i think tab lookup speed isn't really revealent in
selecting this. I will try to adapt my swizzle function
to your code (shouldn't be difficult) thus you can see it.
Bascily arg checking in emit arith look like this :
id = reg & MASK_XYZCHANNEL
reg_fpi0_mask = tab1[id];
if (reg_fpi0_mask ^ ffe0 ) {
swizzle -> copy tab2[id>>5] -> r300_instruct
t = get_temp
for i<tab2[id>>5].length
r300_instr[p-i] |= t
}
Just a memcpy of instruction and a small loop
to set the correct temp reg allocated.
> I once had this in the code, but ended up stripping it down to iron out some
> 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.
What is in favor of a stack is that you easily find free temp
(just test if stack is empty), while with bitfield you have to
loop trought each temp see if bitfield set.
>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)
Yes, i saw this possible issue but didn't think too much on
solution to handle it, i will give a deeper look to your code
this evening.
> No, you haven't missed anything. This was another case where I quickly
> hacked
> 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 was thinking of tracking constant and see if they are always used
swizzle. If so easier to emit the const swizzled like you do.
As i said this is maybe a to advanced and complex optimization which
may involve complex tracking of operand in the program.
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
