gallium: clarify shift behavior with shift count >= 32
authorRoland Scheidegger <sroland@vmware.com>
Tue, 30 Jul 2013 15:08:01 +0000 (17:08 +0200)
committerRoland Scheidegger <sroland@vmware.com>
Fri, 2 Aug 2013 01:49:57 +0000 (03:49 +0200)
commit606132b4def69f7c5fa0fa436259e2fd163b0768
treecb94fbed109029f3abc85f999dfa88e60f2fabb4
parent7f2f63409a6c030130aab71b9a7528ea4e5252b1
gallium: clarify shift behavior with shift count >= 32

Previously, nothing was said what happens with shift counts exceeding
bit width of the values to shift. In theory 3 behaviors are possible:
1) undefined (classic c definition)
2) just shift out all bits (so result is zero, or -1 potentially for ashr)
3) mask the shift count to bit width - 1
API's either require 3) or are ok with 1). In particular, GLSL (as well as a
couple uninteresting legacy GL extensions) is happy with undefined, whereas
both OpenCL and d3d10 require 3). Consequently, most hw also implements 3).
So, for simplicity we just specify that 3) is required rather than saying
undefined and then needing state trackers to work around it.
Also while here specify shift count as a vector, not scalar. As far as I
can tell this was a doc bug, neither state trackers nor drivers used scalar
shift count.

Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
src/gallium/docs/source/tgsi.rst