| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
| |
Mallocing/free eat up a noticeable amount of CPU time for no
practical benefit.
|
| |
|
| |
|
| |
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Conflicts:
configure.ac
src/gallium/auxiliary/vl/Makefile
src/gallium/auxiliary/vl/SConscript
src/gallium/auxiliary/vl/vl_compositor.c
src/gallium/auxiliary/vl/vl_compositor.h
src/gallium/auxiliary/vl/vl_mpeg12_mc_renderer.c
src/gallium/auxiliary/vl/vl_mpeg12_mc_renderer.h
src/gallium/drivers/nouveau/nouveau_winsys.h
src/gallium/drivers/softpipe/sp_video_context.c
src/gallium/include/pipe/p_video_state.h
src/gallium/include/state_tracker/drm_api.h
src/gallium/state_trackers/xorg/xvmc/surface.c
src/gallium/winsys/drm/nouveau/drm/nouveau_drm_api.c
src/gallium/winsys/drm/nouveau/drm/nouveau_drm_api.h
src/gallium/winsys/drm/radeon/core/radeon_drm.c
src/gallium/winsys/g3dvl/nouveau/Makefile
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The progs/test/texwrap demo looks pretty good, but there are still some
tiny differences from softpipe. There may be a sub-pixel texcoord
interpolation error somewhere.
There's some room for optimization. Many of the wrap modes compute
intermediate values that are constant for the texture size (see the
min/max values). These could be computed earlier and stored somewhere
for later use.
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
All the texture wrap modes are now implemented for linear and nearest
sampling.
However, texture border color is not yet supported so some wrap modes
will produce int coords outside the texture bounds. We'll get garbage
values insted of the texture border color for now.
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| | |
The lp_int_type() function was creating an unsigned type. So rename
that function to lp_uint_type() and create new lp_int_type() that
creates a signed type.
|
| | |
|
| | |
|
| | |
|
| |\ |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The only user of PIPE_FORMAT_R8G8B8_SRGB is mesa, which
per src/mesa/main/texstore.c interprets it as
R8 G8 B8
and not the other way around.
|
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | | |
There is actually no ambiguity in use -- it is always used as
R8 G8 B8
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Can't find these formats used in any state tracker or any API.
For some of these probably the reverse notation was meant, for which
formats already exist.
|
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | | |
else was broken in the outter most else statemants, plus the code
didn't need an inverted mask to compute the inverse of the current
condition.
|
| |\ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Conflicts:
src/gallium/drivers/r300/r300_blit.c
src/gallium/drivers/r300/r300_emit.c
src/gallium/drivers/r300/r300_state_derived.c
|
| | | |
| | | |
| | | |
| | | |
| | | | |
When clearing buffers, the depth is specified in the range [0, 1]
and should be passed through blitter "as is".
|
| | | |
| | | |
| | | |
| | | | |
Not tested.
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | |
| | | |
| | | |
| | | | |
Needs testing.
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
implements if/else/endif constructs and lays down the code for looping
and others. we create a conditional execution mask which decides which
of the four inputs are enabled for any store. it's used only if an
execution mask is present, otherwise we go through a direct store.
|
| | |/
| |/| |
|
| | | |
|
| | | |
|
| | | |
|
| | |
| | |
| | |
| | | |
Now trace always built.
|
| | | |
|
| | |
| | |
| | |
| | | |
Don't need special default dependency on u_format_pack.h anymore.
|
| | |
| | |
| | |
| | | |
A better approximation than uscaled...
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Should work correctly for all pixel formats except SRGB formats.
Generated code made much simpler by defining the pixel format as
a C structure. For example this is the generated structure for
PIPE_FORMAT_B6UG5SR5S_NORM:
union util_format_b6ug5sr5s_norm {
uint16_t value;
struct {
int r:5;
int g:5;
unsigned b:6;
} chan;
};
Not used everywhere yet because it seems compiled code is slower than
bitshift arithmetic by some misterious reason. So we should generate
bitshift arithmetic at least for the simple UNORM pixel formats.
|
| | | |
|
| | | |
|
| | | |
|