2009/10/26 Petter Urkedal <[email protected]> > I've had a closer look at the basic instructions listed at > > http://docs.google.com/View?id=dfsp4qpd_41dtrrskfb#Operation_to_support_in_shader_8117638312455733 > to which I have some comments and questions. > > 1. The document list both signed and unsigned additive operations. > These are equivalent, except possibly for the flags. I suggest not to > differentiate signed and unsigned additive instructions, and instead > adapt the conventional semantics for carry and overflow flags. >
In the operations the 2 are differentiated because of 2 reason. The flag, also there is going to be a bit field in the instruction to indicate the data type to the pipeline. Maybe not that useful for the add but for the multiplication or other operations it can be critical. > > 2. Do we need to support extraction of the upper 32 bits of a > multiplication? If not, then mult and umult are also equivalent except > possibly for the flags. I think we can reuse the carry flag for > overflow of an unsigned multiplication in analogy to the additive > instructions. > The cost for supporting the selection of the upper or lower part of the multiplication is small since we can will probably use a signed 33 bits multiplier. Yes it does carry a cost to doing it that way but the multiplier will be reuse to do the shift operation in both direction. It should also support rotate instruction. > > 3. Finally on this chain of though, f2u and f2i will be equivalent > except for overflow detection. Again we can use the carry flag for the > unsigned case and overflow for the signed case. > f2i or f2u are different because the result for the dynamic range is different. one go from 0 to (2^32)-1 the other from 2^-31 to (2^31)-1. For graphical work it shouldn't matter, but for other workload it may have an impact > > 4. I like the idea of adding minimum and maximum functions in the > instruction set; if we need them, that is. They should not require much > logic. But in this case, note that there is a difference between signed > and unsigned. Do we want both? On the other hand it only takes 2 to 3 > cycles to compute any of these if my idea of the instruction set is > correct. > Support for these instruction is an extra step in the pipeline. An extra step that can carry an additional kernel instruction so the impact is minimum. Also for graphic workload it should be usefull and diminish the need for branch instruction. > > 5. To complete the set of shift instructions we need the arithmetic and > logic shift distinction (aka signed and unsigned shifts). > > 6. There may be more flags than we need. For integer division by > zero we can use the overflow, since that's the only way a division can > be out of range. For floating point division by zero, infinity seems > like a natural choice, but I recall there was some discussion on the > list some time ago about special requirement for the Inf and NaN > semantics for rendering so I'm not sure whether we need to differentiate > Inf and zero division for float. > The flag are the one present in the openCL and openGL document xonsidering the amount of register we will need to have adding those the cost is minimal for the flexibility. > > 7. Assuming we've agreed to not run threads in dependent groups, do we > care about the loop unit? Maybe a decrement-and-jump-if-nonzero would > do? > The loop unit will be mainly useful for when we do vector or matrix operation. It will allow the loop to bypass a process step in the alu and will be done by the instruction decoder. This should allow the ALU to execute another kernel in that time slot. > > 8. We are going with conventional flag-based branch instructions, > right? How many bits of address do we need in the branch instructions? > Do we need computed branches? > If we go with branch instruction with address in them we should be able to support around a 24 bits address(3*8 bits operand) it should be more than enough for any kernel who is running.
_______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
