summaryrefslogtreecommitdiff
path: root/src/gallium/auxiliary/gallivm/lp_bld_format_aos.c
AgeCommit message (Collapse)Author
2010-12-17gallivm: Cleanup util_format_xxx_fetch_xxx call generation.José Fonseca
No need to register function prototypes in the module now that we call the C function pointer directly -- less LLVM objects lying around. Limited testing with lp_test_format.
2010-12-16gallivm: fix copy&paste error from previous commitBrian Paul
Fixes piglit regression, http://bugs.freedesktop.org/show_bug.cgi?id=32452 NOTE: This is a candidate for the 7.10 branch
2010-12-16gallivm: work around LLVM 2.6 bug when calling C functionsBrian Paul
Create a constant int pointer to the C function, then cast it to the function's type. This avoids using trampoline code which seem to be inadvertantly freed by LLVM in some situations (which leads to segfaults). The root issue and work-around were found by José. NOTE: This is a candidate for the 7.10 branch
2010-11-30gallivm/llvmpipe: squash merge of the llvm-context branchBrian Paul
This branch defines a gallivm_state structure which contains the LLVMBuilderRef, LLVMContextRef, etc. All data structures built with this object can be periodically freed during a "garbage collection" operation. The gallivm_state object has to be passed to most of the builder functions where LLVMBuilderRef used to be used. Conflicts: src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c src/gallium/drivers/llvmpipe/lp_state_setup.c
2010-09-11gallivm: Add a new debug flag to warn about performance issues.José Fonseca
2010-08-29util: remove util_is_pot in favor of util_is_power_of_twoMarek Olšák
The function was duplicated.
2010-08-09gallivm: Always use floating-point operators for floating-point typesnobled
This fixes the assert added in LLVM 2.8: assert(getType()->isIntOrIntVectorTy() && "Tried to create an integer operation on a non-integer type!") But it also fixes some subtle bugs, since we should've been doing this since LLVM 2.6 anyway. Includes a modified patch from steckdenis@yahoo.fr for the FNeg instructions in emit_fetch(); thanks for pointing those out. http://bugs.freedesktop.org/29404 http://bugs.freedesktop.org/29407 Signed-off-by: José Fonseca <jfonseca@vmware.com>
2010-07-02gallivm: Use util_format_description::fetch_rgba_8unorm() when available.José Fonseca
2010-07-02gallivm: Support multiple pixels in lp_build_fetch_rgba_aos().José Fonseca
This allows to do the unpacking of formats that fit in 4 x unorm8 in parallel, 4 pixels at a time.
2010-07-02gallivm: Move gather functions to its own module.José Fonseca
They need to grow, and they provide basic functionality which is not specific to sampling.
2010-07-02gallivm: Code generate YUV format unpacking.José Fonseca
2010-07-01gallivm: Support 4 x unorm8 in lp_build_fetch_rgba_aos().José Fonseca
Uses code and ideas from Brian Paul.
2010-06-14gallivm: Use func_to_pointer().José Fonseca
2010-05-13gallivm: silence casting warningBrian Paul
2010-05-12gallivm: additional commentsBrian Paul
2010-05-12gallivm: s/bool/booleanBrian Paul
2010-05-08gallivm: Don't hardcode number of args twice.José Fonseca
2010-04-27gallivm: Ensure all allocas are in the first block.José Fonseca
Refactor the code to make this easier.
2010-04-22gallivm: Remove unused variable.Vinson Lee
2010-04-20gallivm: Remove unnecessary headers.Vinson Lee
2010-04-20gallivm: Universal format support on lp_build_fetch_rgba_aos via ↵José Fonseca
util_format_description::fetch_rgba_float This therefore adds support to half float vertex buffers.
2010-04-20gallivm: Cleanups and bugfixes to aos format translation.José Fonseca
2010-04-20gallivm: New function to fetch a pixel into a 4xfloat AoS vector.José Fonseca
2010-04-20gallivm: Bring aos format back to life.José Fonseca
Useful for fetching vertices for formats that are straight arrays. This reverts commit aa364d091e7e2ef2296fb25f92efc79a8c88f77d.
2010-03-31llvmpipe: Drop the aos format conversion.José Fonseca
It's unused and incomplete. Still in git history if necessary in future.
2010-02-24gallivm: Update for UTIL_FORMAT_LAYOUT_xxx changes.José Fonseca
2010-02-08llvmpipe: export the tgsi translation code to a common layerZack Rusin
the llvmpipe tgsi translation is a lot more complete than what was in gallivm so replacing the latter with the former. this is needed since the draw llvm paths will use the same code. effectively the proven llvmpipe code becomes gallivm.