| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
| |
Doesn't make any real difference but -D flags are put into DEFINES
everywhere else.
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Conflicts:
src/gallium/auxiliary/util/u_surface.c
src/gallium/drivers/llvmpipe/Makefile
src/gallium/drivers/llvmpipe/SConscript
src/gallium/drivers/llvmpipe/lp_bld_arit.c
src/gallium/drivers/llvmpipe/lp_bld_flow.c
src/gallium/drivers/llvmpipe/lp_bld_interp.c
src/gallium/drivers/llvmpipe/lp_clear.c
src/gallium/drivers/llvmpipe/lp_context.c
src/gallium/drivers/llvmpipe/lp_context.h
src/gallium/drivers/llvmpipe/lp_draw_arrays.c
src/gallium/drivers/llvmpipe/lp_jit.c
src/gallium/drivers/llvmpipe/lp_jit.h
src/gallium/drivers/llvmpipe/lp_prim_vbuf.c
src/gallium/drivers/llvmpipe/lp_setup.c
src/gallium/drivers/llvmpipe/lp_setup_point.c
src/gallium/drivers/llvmpipe/lp_state.h
src/gallium/drivers/llvmpipe/lp_state_blend.c
src/gallium/drivers/llvmpipe/lp_state_derived.c
src/gallium/drivers/llvmpipe/lp_state_fs.c
src/gallium/drivers/llvmpipe/lp_state_sampler.c
src/gallium/drivers/llvmpipe/lp_state_surface.c
src/gallium/drivers/llvmpipe/lp_tex_cache.c
src/gallium/drivers/llvmpipe/lp_tex_cache.h
src/gallium/drivers/llvmpipe/lp_tex_sample.h
src/gallium/drivers/llvmpipe/lp_tile_cache.c
|
| |
| |
| |
| |
| |
| |
| | |
Was used only as a reference, since texture sampling is now code generated.
Already axed in the lp-binning branch too.
This fixes the llvmpipe build after recent sampling changes.
|
| |
| |
| |
| |
| |
| |
| | |
Everything now goes through the draw_vbuf handler, the same as
regular drivers.
Based on Keith's commit 4fe0fc3eba1f79beda890a5016359d549bab6ad4.
|
| |
| |
| |
| |
| | |
Basically mimic the llvm 2.6 way of linking execution engines and
targets.
|
| | |
|
| | |
|
| |
| |
| |
| |
| | |
These functions will be needed to implement many of the 8bit operations,
and they are quite complex on its own.
|
| |
| |
| |
| |
| |
| |
| |
| | |
The setup tiling engine is now plugged directly into the draw module
as a rendering backend.
Removed a couple of layering violations such that the setup code no
longer reaches out into the surrounding llvmpipe state or context.
|
| | |
|
| | |
|
| |
| |
| |
| |
| | |
The queues will be used for keeping track of full and empty bins so
we can overlap setup with the rasterization threads.
|
| | |
|
| |
| |
| |
| | |
And put lp_ prefixes on some functions.
|
| | |
|
|/
|
|
|
|
|
|
| |
WIP, does't build or run.
Rasterizer code is based on Nick Capen's devmaster posts and the
larrabee articles, but currently doesn't share either the performance
or correctness of either...
|
|
|
|
|
|
|
|
|
| |
This is just a temporary change until we code generate the tile read/write
functions in runtime. The new code avoids an extra memcpy that exists in
u_tile.c functions, from which lp_tile_soa.c was originally based.
This achieves up to 5% improvement, particularly in frames with
little geometry overlap.
|
|\ |
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Finally a substantial performance improvement: framerates of apps using
texturing tripled, and furthermore, enabling/disabling texturing only
affects around 15% of the framerate, which means the bottleneck is now
somewhere else.
Generated texture sampling code is not complete though -- we always
sample from the base level -- so final figures will be different.
|
| |
| |
| |
| |
| | |
Only supports single level 2d textures, with neareast and bilinear
filtering for now.
|
|/ |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
| |
Special attention is given to the interpolation of side by side quads.
Multiplications are made only for the first quad. Interpolation of
inputs for posterior quads are done exclusively with additions, and
perspective divide if necessary.
|
| |
|
| |
|
|
|
|
| |
It had been reduced to one fixed stage.
|
|
|
|
| |
Description/rationale/to-do items, while I still remember them...
|
|
|
|
| |
lp_state_fs.c is already too big without it.
|
|
|
|
| |
Still hackish. Will document and optimize later.
|
|
|
|
| |
Not used now -- stipple done by the draw module. May code generate later.
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
The code
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
Consolidate the read-modify-write color combining code from
the blend, colormask and output stages.
|
|
|
|
|
| |
Just a small proof of concept plus a standalone test app. Not integrated
with the rest of the driver yet.
|
|
|