summaryrefslogtreecommitdiffstats
path: root/src/gallium/auxiliary/gallivm
Commit message (Collapse)AuthorAgeFilesLines
* gallivm: fix border color for integer texturesRoland Scheidegger2013-01-101-0/+5
| | | | | | | | Need to bitcast the float border color (luckily we already get the color as int just disguised as float). Fixes piglit texwrap GL_EXT_texture_integer bordercolor. Reviewed-by: José Fonseca <[email protected]>
* gallivm: more integer texture format fetch fixesRoland Scheidegger2013-01-106-35/+74
| | | | | | | | | | | | | | | Change the texel type to int/uint instead of float throughout the sampling code which makes it easier to catch errors (as llvm will complain about wrong types if we mistakenly treat these values as real floats somewhere). This should also get things like e.g. sampler swizzles (for unused channels) right. This fixes piglit texture_integer_glsl130 test. Border color not working (crashing) yet. (These formats are not exposed yet in llvmpipe.) v2: couple cleanups according to José's comments Reviewed-by: José Fonseca <[email protected]>
* gallivm: support more immediates in lp_build_tgsi_info()Brian Paul2013-01-041-1/+1
| | | | | | Bump limit from 32 to 128. Fixes http://bugs.freedesktop.org/show_bug.cgi?id=58545
* gallivm: fix conversion for pure integer formatsRoland Scheidegger2012-12-181-0/+1
| | | | | | | | | | | Since the idea is to just expand or shrink the bit width but not otherwise do conversion we also need to adjust the sign bit according to src, otherwise the conversion code will incorrectly clamp the values. (Since this only works for casting to ordinary floats the norm and fixed bits should always be fine.) This fixes the remaining piglit attribs GL3 failures. Reviewed-by: José Fonseca <[email protected]>
* gallivm: fix texel fetch for array textures (2)Roland Scheidegger2012-12-171-2/+3
| | | | | | | | a460aea3f14222af46f88d1bc686f82180b8a872 wasn't entirely correct, since all coords are already ints hence need to skip the iround. Passes piglit texelFetch with sampler1DArray/sampler2DArray. Reviewed-by: Dave Airlie <[email protected]>
* gallivm: fix texel fetch for array texturesRoland Scheidegger2012-12-131-17/+38
| | | | | | | | | | Since we don't call lp_build_sample_common() in the texel fetch path we missed the layer fixup code. If someone would have tried to do texelFetch with array textures it would have crashed for sure. Not really tested (can't run the piglit test being able to use texelFetch with array samplers for now with llvmpipe). Reviewed-by: José Fonseca <[email protected]>
* gallivm: Lower TGSI_OPCODE_MUL to fmul by defaultTom Stellard2012-12-101-2/+3
| | | | | | | This fixes a number of crashes on r600g due to the fact that lp_build_mul assumes vector types when optimizing mul to bit shifts. This bug was uncovered by 0ad1fefd6951aa47ab58a41dc9ee73083cbcf85c
* llvmpipe: fix txq for 1d/2d arrays. (v3)Dave Airlie2012-12-111-2/+15
| | | | | | | | | | | | | | | | | Noticed would fail, we were doing two things wrong a) 1d arrays require the layers in height b) minifying the layers field. v2: don't change height code, fixup completely inside txq as suggested by Roland. v3: just add minify before texture array size v1: Reviewed-by: Jose Fonseca <[email protected]> Reviewed-by: Roland Scheidegger <[email protected]> Signed-off-by: Dave Airlie <[email protected]>
* llvmpipe: increase texture target width to reflect increaseDave Airlie2012-12-111-1/+1
| | | | | | | Now that we've gone over 7. Reviewed-by: Jose Fonseca <[email protected]> Signed-off-by: Dave Airlie <[email protected]>
* gallivm: Rudimentary native integer support.José Fonseca2012-12-072-5/+20
| | | | | | | | | Just enough for draw module to work ok. This improves "piglit attribs GL3", though something fishy is still happening with certain unsigned integer values. Reviewed-by: Brian Paul <[email protected]>
* gallivm: Allow indirection from TEMP registers too.José Fonseca2012-12-071-3/+18
| | | | | | | | The ADDR file is cumbersome for native integer capable drivers. We should consider deprecating it eventually, but this just adds support for indirection from TEMP registers. Reviewed-by: Brian Paul <[email protected]>
* gallivm,llvmpipe,draw: Support multiple constant buffers.José Fonseca2012-12-072-3/+19
| | | | | | | | | | | Support 16 (defined in LP_MAX_TGSI_CONST_BUFFERS) as opposed to 32 (as defined by PIPE_MAX_CONSTANT_BUFFERS) because that would make the jit context become unnecessarily large. v2: Bump limit from 4 to 16 to cover ARB_uniform_buffer_object needs, per Dave Airlie. Reviewed-by: Brian Paul <[email protected]>
* gallivm: Fix lerping of (un)signed normalized numbers.José Fonseca2012-12-061-49/+43
| | | | | | | | | | | | | | | | | | Several issues actually: - Fix a regression in unsigned normalized in the rescaling [0, 255] to [0, 256] - Ensure we use signed shifts where appropriate (instead of unsigned shifts) - Refactor the code slightly -- move all the logic inside lp_build_lerp_simple(). This change, plus an adjustment in the tolerance of signed normalized results in piglit fbo-blending-formats fixes bug 57903 Reviewed-by: Brian Paul <[email protected]>
* gallivm: Fix lp_build_print_value of smaller integer types.José Fonseca2012-12-061-1/+12
| | | | | | | They need to be converted to the native integer type to prevent garbage in higher order bits from being printed. Reviewed-by: Brian Paul <[email protected]>
* gallivm: Have a default emit function for min/max opcodeVincent Lejeune2012-12-051-0/+29
| | | | Reveiwed-by: Tom Stellard <thomas.stellard at amd.com>
* gallivm: have a default emit function for fdiv/rcpVincent Lejeune2012-12-051-0/+25
| | | | Reveiwed-by: Tom Stellard <thomas.stellard at amd.com>
* gallivm: Re-add the kludge for lp_build_lerp of fixed point types.José Fonseca2012-12-041-1/+5
| | | | | | | I removed it in commit 7d44d354bdba853e453ce3991396e2b0933468f4 but texture sample code still relies on it. Not sure how to this cleanly, so put it pack for now.
* gallivm: Generalize lp_build_mul and lp_build_lerp for signed normalized types.José Fonseca2012-12-041-92/+82
| | | | | | | | This fixes fdo bug 57755 and most of the failures of piglit fbo-blending-formats GL_EXT_texture_snorm. GL_INTENSITY_SNORM is still failing, but problem is probably elsewhere, as GL_R8_SNORM works fine.
* gallivm: fix srgb format fetchRoland Scheidegger2012-12-031-1/+2
| | | | | | | | | we need to rely on util code for fetching those, just like before 9f06061d50f90bf425a5337cea1b0adb94a46d25. Fixes bugs 57699 and 57756. Reviewed-by: Brian Paul <[email protected]> Reviewed-by: José Fonseca <[email protected]>
* gallivm: drop border wrap clamping codeRoland Scheidegger2012-12-011-33/+16
| | | | | | | | | | | | | | | | | | | | | The border clamping code is unnecessary, since we don't care if a wrapped coord value is -1 or <-1 (same for length vs. >length), in either case the border handling code will mask out the offset and replace the texel value with the border color. Note that technically this is not entirely correct. Omitting clamping on the float coords means that flt->int conversion may result in undefined values for values of very large magnitude. However there's no reason we should honor this here since: a) we don't care for that for ordinary wrap modes in the aos code when converting coords and the problem is worse there (as we've got only effectively 24 instead of 32bits) b) at least in some cases the clamping was done already in int space hence doing nothing to fix that problem. c) with sse2 flt->int conversion with such values results in 0x80000000 which is just perfect (for clamp to border - not so much for the ordinary clamp to edge). Reviewed-by: Brian Paul <[email protected]>
* gallivm: Fix lp_build_float_to_half.José Fonseca2012-11-291-30/+75
| | | | | | | | | | | The current implementation was close by not fully correct: several operations that should be done in floating point were being done in integer. Fixes piglit fbo-clear-formats GL_ARB_texture_float Reviewed-by: Brian Paul <[email protected]> Reviewed-by: Roland Scheidegger <[email protected]>
* gallivm: fix a trivial txq issue for 2d shadow and cube shadow samplersRoland Scheidegger2012-11-291-2/+2
| | | | | | | | | untested (couldn't get the piglit test to run even with version overrides) but seemed blatantly wrong. In any case it would only affect an error case which when it would happen probably all hope is lost anyway. Reviewed-by: José Fonseca <[email protected]>
* gallivm: support array texturesRoland Scheidegger2012-11-296-65/+103
| | | | | | | | | | | | | Support 1d and 2d array textures (including shadow samplers), and (as a side effect mostly) also shadow cube samplers. Seems to pass the relevant piglit tests both for sampling and rendering to (though some require version overrides). Since we don't support render target indices rendering to array textures is still restricted to a single layer at a time. Also, the min/max layer in the sampler view (which is unnecessary for GL) is ignored (always use all layers). Reviewed-by: José Fonseca <[email protected]>
* util/u_format: Kill util_format_is_array().José Fonseca2012-11-292-2/+4
| | | | | | | | It is buggy (it was giving wrong results for some of the formats with padding), and util_format_description::is_array already does precisely what's intended. Reviewed-by: Roland Scheidegger <[email protected]>
* gallivm: Fix format manipulation for big-endianAdhemerval Zanella2012-11-295-12/+145
| | | | | | | | This patch fixes various format manipulation for big-endian architectures. Reviewed-by: Roland Scheidegger <[email protected]> Reviewed-by: Jose Fonseca <[email protected]>
* gallivm: Add byte-swap construct callsAdhemerval Zanella2012-11-292-0/+89
| | | | | | | | | | | This patch adds two more functions in type conversions header: * lp_build_bswap: construct a call to llvm.bswap intrinsic for an element * lp_build_bswap_vec: byte swap every element in a vector base on the input and output types. Reviewed-by: Roland Scheidegger <[email protected]> Reviewed-by: Jose Fonseca <[email protected]>
* gallivm: Fix vector constant for shuffleAdhemerval Zanella2012-11-291-1/+6
| | | | | | | | This patch fixes the vector constant generation used for vector shuffle for big-endian machines. Reviewed-by: Roland Scheidegger <[email protected]> Reviewed-by: Jose Fonseca <[email protected]>
* gallivm: clear Altivec NJ bitAdhemerval Zanella2012-11-291-0/+19
| | | | | | | | This patch enforces the clear of NJ bit in VSCR Altivec register so denormal numbers are handles as expected by IEEE standards. Reviewed-by: Roland Scheidegger <[email protected]> Reviewed-by: Jose Fonseca <[email protected]>
* gallivm: Altivec floating-point roundingAdhemerval Zanella2012-11-291-23/+70
| | | | | | | | | This patch adds Altivec intrinsics for float vector types. It changes the SSE specific definitions to a platform neutral and adds the calls to Altivec intrinsic builder. Reviewed-by: Roland Scheidegger <[email protected]> Reviewed-by: Jose Fonseca <[email protected]>
* gallivm: Altivec vector add/sub intrisicsAdhemerval Zanella2012-11-292-15/+27
| | | | | | | | | | | | | This patch add correct vector addition and substraction intrisics when using Altivec with PPC. Current code uses default path and LLVM backend ends up issuing carry-out arithmetic instruction while it is expected saturated ones. It also includes a fix for PowerPC where char are unsigned by default, resulting in bogus values for vector shifting. Reviewed-by: Roland Scheidegger <[email protected]> Reviewed-by: Jose Fonseca <[email protected]>
* gallivm: Altivec vector max/min intrisicsAdhemerval Zanella2012-11-291-2/+54
| | | | | | | | This patch adds the PPC Altivec instrics max/min instruction for supported Altivec vector types (16xi8, 8xi16, 4xi32, 4xf32). Reviewed-by: Roland Scheidegger <[email protected]> Reviewed-by: Jose Fonseca <[email protected]>
* gallivm: Altivec pack/unpack intrisicsAdhemerval Zanella2012-11-291-14/+30
| | | | | | | | This patch adds PPC Altivec support for pack/unpack operations using Altivec supported vector type (8xi8, 16xi16, 4xi32, 4xf32). Reviewed-by: Roland Scheidegger <[email protected]> Reviewed-by: Jose Fonseca <[email protected]>
* llvmpipe: Unswizzled rendering.James Benton2012-11-2812-29/+360
| | | | Reviewed-by: Jose Fonseca <[email protected]>
* gallivm: Updated lp_build_const_mask_aos to input number of channels.James Benton2012-11-285-18/+26
| | | | | | Also updated lp_build_const_mask_aos_swizzled to reflect this. Reviewed-by: Jose Fonseca <[email protected]>
* gallivm: Added support for float to half-float conversion in lp_build_conv.James Benton2012-11-282-7/+94
| | | | Reviewed-by: Jose Fonseca <[email protected]>
* gallivm: Changed lp_build_pad_vector to correctly handle scalar argument.James Benton2012-11-283-17/+22
| | | | | | Removed the lp_type argument as it was unnecessary. Reviewed-by: Jose Fonseca <[email protected]>
* gallivm: Add a function to generate lp_type for a format.James Benton2012-11-282-7/+31
| | | | Reviewed-by: Jose Fonseca <[email protected]>
* gallivm: Add support for unorm16 in lp_build_mul.James Benton2012-11-281-0/+45
| | | | Reviewed-by: Jose Fonseca <[email protected]>
* gallivm: fix multiple lods with different min/mag filter and wide vectorsRoland Scheidegger2012-11-281-0/+3
| | | | | | broken since 529fe420ba6836479619ba42e53665724755fc1c, I forgot some code, only added the comment... Fixes bug 57644.
* gallivm: Fix bug in lp_build_one which would incorrectly return a vector for ↵James Benton2012-11-271-1/+1
| | | | | | length 1. Signed-off-by: José Fonseca <[email protected]>
* gallivm: use the new mip per quad handling in texture fetch pathRoland Scheidegger2012-11-273-193/+212
| | | | | | | | | | No longer have to split fetching into quads dynamically if mip levels are not the same for all quads (aos sampling still always splits due to performance reasons). Instead handle multiple mip levels further down, minification etc. takes this into account. Reviewed-by: José Fonseca <[email protected]>
* gallivm,llvmpipe: handle TXF (texelFetch) instruction, including offsetsRoland Scheidegger2012-11-279-64/+602
| | | | | | | | | | | | | This also adds some code to handle per-quad lods for more than 4-wide fetches, because otherwise I'd have to integrate the texelFetch function into the splitting stuff... (but it is not used yet outside texelFetch). passes piglit fs-texelFetch-2D, fails fs-texelFetchOffset-2D due to I believe a test error (results are undefined for out-of-bounds fetches, we return whatever is at offset 0, whereas the test expects [0,0,0,1]). Texel offsets are only handled by texelFetch for now, though the interface can handle it for everything. Reviewed-by: José Fonseca <[email protected]>
* gallivm,draw,llvmpipe: use base ptr + mip offsets instead of mip pointersRoland Scheidegger2012-11-123-9/+19
| | | | | | | | | This might have a slight overhead but handling mip offsets more like the width (and image) strides should make some things easier (mip level being just part of the offset calculation) later. Reviewed-by: Brian Paul <[email protected]> Reviewed-by: José Fonseca <[email protected]>
* gallium/gallivm: code generation options for LLVM 3.1+Alexander V. Nikolaev2012-10-283-17/+44
| | | | | | | | | | | | | | | LLVM 3.1+ haven't more "extern unsigned llvm::StackAlignmentOverride" and friends for configuring code generation options, like stack alignment. So I restrict assiging of lvm::StackAlignmentOverride and other variables to LLVM 3.0 only, and wrote similiar code using TargetOptions. This patch fix segfaulting of WINE using llvmpipe built with LLVM 3.1 Signed-off-by: Alexander V. Nikolaev <[email protected]> Signed-off-by: José Fonseca <[email protected]>
* gallivm/llvmpipe: fix 64-bit %ll format compiler warnings for mingw32Brian Paul2012-10-261-4/+3
| | | | | Use the PRIx64 and PRIu64 format macros from inttypes.h. We made a similar change in prog_print.c in df2d81ea59993a77bd1f1ef96c5cf19ac692d5f7.
* gallivm: Hide AVX support when requested by LP_NATIVE_VECTOR_WIDTH or ↵José Fonseca2012-10-171-0/+10
| | | | | | unsupported by LLVM. Reviewed-by: Roland Scheidegger <[email protected]>
* gallivm: Use mcjit for ppc_64 architectureWill Schmidt2012-10-171-1/+4
| | | | | | | | | Per commentary and direction in the LLVM community, support for ppc64 is going into MCJIT rather than the old JIT. There is no existing support in prior llvm versions, so no need to specify LLVM version numbers. Signed-off-by: Will Schmidt <[email protected]> Signed-off-by: José Fonseca <[email protected]>
* Revert "gallivm: Don't use llvm.x86.avx.max/min.ps.256 inadvertently."José Fonseca2012-10-171-4/+4
| | | | This reverts commit bf2edc776b02a2a63862bf69a23adf666ecfcc57.
* gallivm: Don't use llvm.x86.avx.max/min.ps.256 inadvertently.José Fonseca2012-10-121-4/+4
| | | | Could happen when CPU supports AVX, but LLVM doesn't.
* gallivm: fix rsqrt failuresRoland Scheidegger2012-10-121-8/+41
| | | | | | | | | | | | | | | | | | | | | | | | | lp_build_rsqrt initially did not do any newton-raphson step. This meant that precision was only ~11 bits, but this handled both input 0.0 and +infinity correctly. It did not however handle input 1.0 accurately, and denormals always generated infinity result. Doing a newton-raphson step increased precision significantly (but notably input 1.0 still doesn't give output 1.0), however this fails for inputs 0.0 and infinity (both result in NaNs). Try to fix this up by using cmp/select but since this is all quite fishy (and still doesn't handle denormals) disable for now. Note that even with workarounds it should still have been faster since the fallback uses sqrt/div (which both use the usually unpipelined and slow divider hw). Also add some more test values to lp_test_arit and test lp_build_rcp() too while there. v2: based on José's feedback, avoid hacky infinity definition which doesn't work with msvc (unfortunately using INFINITY won't cut it neither on non-c99 compilers) in lp_build_rsqrt, and while here fix up the input infinity case too (it's disabled anyway). Only test infinity input case if we have c99, and use float cast for calculating reference rsqrt value so we really get what we expect. Reviewed-by: José Fonseca <[email protected]>
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-24 07:01:36 +0000