| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
seems to work here ...
|
| |
|
| |
|
|
|
|
| |
And update comments.
|
| |
|
|
|
|
| |
Carried over from softpipe driver.
|
| |
|
|\
| |
| |
| |
| |
| | |
Conflicts:
src/gallium/drivers/softpipe/sp_tile_cache.c
|
| | |
|
| | |
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | | |
Conflicts:
progs/demos/cubemap.c
src/gallium/drivers/softpipe/sp_tex_sample.c
src/gallium/drivers/softpipe/sp_texture.c
|
| | |
| | |
| | |
| | |
| | | |
Before, if level was greater than the logbase2(base size) we were
doing a negative bit shift and winding up with garbage values.
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | |
| | |
| | |
| | | |
Same change as for softpipe
|
| | |
| | |
| | |
| | |
| | | |
GCC won't do this for us. Makes a bigger difference to cubemap fps
than previous set of compilcated rearrangements.
|
| | | |
|
| | |
| | |
| | |
| | |
| | | |
Remove arguments, return const float * by default. Add specialized 3d
versions and remove 3d texture support from the others.
|
| | | |
|
| | |
| | |
| | |
| | | |
For fastpaths at least, can avoid recalculating this sometimes.
|
| | |
| | |
| | |
| | |
| | | |
Everything now goes through the draw_vbuf handler, the same as
regular drivers.
|
| | | |
|
| |\ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Conflicts:
src/gallium/drivers/softpipe/sp_state_derived.c
src/gallium/drivers/softpipe/sp_state_sampler.c
src/gallium/drivers/softpipe/sp_tex_sample.c
src/gallium/drivers/softpipe/sp_tex_sample.h
src/gallium/drivers/softpipe/sp_tile_cache.c
|
| | | | |
|
| | | |
| | | |
| | | |
| | | |
| | | | |
These do similar jobs but with largely disjoint code. Will want
to evolve them separately going forward.
|
| | | | |
|
| | | |
| | | |
| | | |
| | | |
| | | | |
The texture sampling code doesn't really have any dependencies on the
rest of softpipe, just the tile cache.
|
| | | |
| | | |
| | | |
| | | | |
The tile cache code now has no hard dependencies on softpipe.
|
| | | | |
|
| | | | |
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Can't share sampler varients across multiple tex units because the texture
pointer is in the sampler varient. That prevents different textures per unit.
Fixes progs/demos/multiarb, progs/glsl/samplers, etc.
|
| | | |
| | | |
| | | |
| | | | |
Fixes progs/demos/cubemap
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Split into component pieces, stitch together at runtime using function
pointers. Make it possible to utilize the existing fastpaths as image-level
filters for generic mip-filtering routines.
Remove special case for rectangle filtering, as it can now be handled by
the 2d path.
As most of the mesa demo texturing was already covered by fast paths, its
harder to find examples of speedups, but tunnel gets a boost as mip-nearest
filtering is now able to access the img_2d_linear_wrap_POT functions
for sampling within a mipmap level.
|
| | | | |
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Let eg. sp_get_samples_rect be hooked directly in as the tgsi sampler
routine.
Add a field to determine whether this is a vertex or fragment sampling
call, and massage parameters to match the tgsi call.
|
| | | | |
|
| | | | |
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Fixes two issues - firstly for mipmap levels with one or more
dimensions smaller than tilesize, the code was sampling off the edge
of the texture (but still within the tile).
Secondly, in the linear_mipmap_linear case, both the default code and
new fastpath were incorrect. This change fixes the fastpath and adds
a comment to the default path, which still needs to be fixed.
Basically the issue is that the coordinates in the smaller texture
level are/were being computed by just dividing thecoordinates from the
larger texture level by two, as in:
x0[j] /= 2;
y0[j] /= 2;
x1[j] /= 2;
y1[j] /= 2;
The issues with this are signficant. Initially x1 is most often equal
to x0+1, but after this, it will likely be equal to x0, so we will not
actually be performing the linear blend within the smaller mipmap.
The fastpath code avoided this (recalculated x1), but was still using
the weighting factors from the larger mipmap level (xw, yw), which
were incorrect.
Change the fastpath code to do two full, independent linear samples of
the two mipmap levels before blending. The default code needs to do
the same thing.
|