My reasoning behind this is that the destination might well be an
output register, which as far as I can tell, there is no way to read
from on r300 hardware.
It should be possible in the future to handle both cases by checking if
"dest" is a temp or an output and acting accordingly, but I was
attempting to keep things simple(ish) until the bugs are ironed out.
Also note, that the temporary register is actually freed after it's been
used. So we're not really wasting a register. It may present a problem
if the "dest" register hasn't actually been allocated yet, and we run
out of temps when trying to allocate it.
>I've been watching the R300 CVS commits, looking forward to a day when we
>might be able to see good free 3D drivers for today's cards.
>I have a thought though, which might be fuelled by ignorance of ARB_f_p
>or of the ATI hardware. Don't hesitate to tell me why I'm wrong...
>can't FP_OPCODE_SGE and FP_OPCODE_SLT be rewritten to use the destination
>as a temporary, thereby eliminating the need for a real temporary which
>may be important for a large/ complex program ?
>If so it also seems that the remaining FP_OPCODEs already implemented can
>be rewritten to avoid a temporary in some (most?) cases.
>SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
>from IBM. Find simple to follow Roadmaps, straightforward articles,
>informative Webcasts and more! Get everything you need to get up to
>speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
>Dri-devel mailing list