These binops are the vector-to-bool comparisons, not vec-to-bvec. We
likely want both operations avilable as expression, since 915 and 965
FS naturally does the vector version, while 965 VS can also naturally
do the scalar version. However, we can save that until later.
Fixes:
glsl-fs-vec4-operator-equal.shader_test
glsl-fs-vec4-operator-notequal.shader_test
glsl-vs-vec4-operator-equal.shader_test
glsl-vs-vec4-operator-notequal.shader_test
Now that we have glsl2 with if flattening in place, most shaders will
just work. Remaining failing shaders will mostly be due to loop
unrolling (in progress), some possible if flattening failures in
inlining functions (planning on fixing), and the register/instruction
count limits.
While the GLSL and GLSL-ES specs say that shaders shouldn't fail to
compile/link due to register/instruction limits, in practice we're not
the first vendor to expose GLSL on hardware with these limitations.
The benefit to application developers of providing a better language
for GPU programming is greater than the pain of having to handle
instruction limits (which they had to for ARB_fp on this hardware
anyway)
This error led to an assertion failure for some constructors of
non-square matrices. It only occured in matrices where the number of
columns was greater than the number of rows. It didn't even always
occur on those.
Fixes piglit glslparsertest case constructor-16.vert.
When simplifying (vec4(1.0) / (float(x))) to rcp(float(x)), we forgot
to produce a vec4, angering ir_validate when starting alien-arena.
Fixes:
glsl-algebraic-add-zero-2
glsl-algebraic-div-one-2
glsl-algebraic-mul-one-2
glsl-algebraic-sub-zero-3
glsl-algebraic-rcp-sqrt-2
Several optimization paths, including constant folding, can lead to
accessing an ir_constant array with an out of bounds index. The GLSL
spec lets us produce "undefined" results, but it does not let us
crash.
Fixes piglit test case glsl-array-bounds-01 and glsl-array-bounds-03.
Apart from the fact that the radeon.h/r600_states.h editing is a nightmare, this
wasn't so bad.
passes piglit user-clip test now also trivial tests.
Signed-off-by: Dave Airlie <airlied@redhat.com>
This saves an extra message reg move in the program, though I'm not
clear on whether it will have any performance impact other than cache
footprint. It will also fix those math calls on Sandybridge, where
the brw_eu_emit.c brw_math() support relies on the implied move being
used.
check_os_katmai_support checks that the operating system running on a
SSE-capable processor supports SSE. This is necessary for unpatched
2.2.x and earlier kernels. 2.4.x and later kernels support SSE.
check_os_katmai_support will disable SSE capabilities for 32-bit x86
operating systems for which there is no code path. Currently, this
function handles Linux, Windows, and several BSDs. Mac OS, Cygwin, and
Solaris are several operating systems with no code paths.
Rather than add code for the unhandled operating systems, remove this
function altogether. This will fix SSE detection on all recent 32-bit
x86 operating systems. This completely breaks functionality on unpatched
2.2.x and earlier kernels, although there are likely no Gallium3D users
on such operating systems.
