On 14.11.2011 12:28, Jose Fonseca wrote:
----- Original Message -----
Indirect addressing on TEMP should be forbidden and only allowed for
TEMPORARY_ARRAY, I'd very much like to know which values I can keep
in
registers and which ones I have to store to thread-local memory (I
can't
do things like MOV %e{%ecx}x but I have 128 registers).
Yes, separating out arrays is light years more important that typing, and on
its own right, as it seriously impairs optimization.
Totally agree on that, so far every attempt to create an optimized
register allocator for r600 hardware was torpedoed by the fact that you
don't really know at which index an temporary array starts and ends.
Then there should be a declaration per array, and we can have our
type.
It's still unclear to me what typed registers buy over typed operations.
When one translates a floating point addition operation, one immediately knows
that the inputs are floating points and the outputs as well. Ditto for integers.
And type is not truly a property of the temporaries anyway, but of the
intermediate values. And if you're doing any decent optimization, you'll
transform the IR to SSA, and you'll annotate the types on the SSA values, and
not the temporary storage, so that you can handle unions and bitcasts
efficiently.
Passes like trying to minimize the number of temporaries would be come much
harder/inefficiency with typed registers, as they would need to be type aware.
Maybe we should define a bit more clear what typed vs. untyped means
here. When we speak about typed does that include bit width?
My current understanding is that all TGSI registers are 32bit and either
threated as floats or ints depending on the operation, that is also more
or less what we currently have on radeon hardware. So as long as the
operations stay 32bit I doubt that we really need more type info inside
the register.
But what should we do about 64bit operations?
Christian.
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
