summaryrefslogtreecommitdiffstats
path: root/src/gbm/backends/dri/gbm_dri.c
diff options
context:
space:
mode:
authorRoland Scheidegger <[email protected]>2013-07-30 17:08:01 +0200
committerRoland Scheidegger <[email protected]>2013-08-02 03:49:57 +0200
commit606132b4def69f7c5fa0fa436259e2fd163b0768 (patch)
treecb94fbed109029f3abc85f999dfa88e60f2fabb4 /src/gbm/backends/dri/gbm_dri.c
parent7f2f63409a6c030130aab71b9a7528ea4e5252b1 (diff)
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 <[email protected]>
Diffstat (limited to 'src/gbm/backends/dri/gbm_dri.c')
0 files changed, 0 insertions, 0 deletions