| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
| |
linear-mip-linear-repeat-POT sampling faspath, provides a very nice
speedup to apps that do this common type of texturing.
Test case: demos/terrain, turn fog off, turn texturing on.
Without patch: 12 fps
With patch: 20 fps.
|
| |
|
|
|
|
|
|
|
| |
This reverts commit 1295cf423e21dad04a947960782ffa8db2739709.
The original formulation was easier to understand & work with. Will
revisit this later.
|
|
|
|
|
| |
Unshare one function (setup_pos_vector) as we want to push this code
into the generated shader in the SSE case.
|
|
|
|
|
| |
However we do llvm integration, it will be different & more comprehensive
than this.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
Stray '- 0.5' copied from linear versions.
|
|
|
|
|
| |
All these fastpaths are examples of the types of things we'd code-generate
in a more sophisticated version of softpipe.
|
|
|
|
|
|
|
| |
Because this is interpolated (ie. early) depth, we can build in an
assumption about the quads emitted by triangle setup, ie that they
are actually linear spans. Interpolate z over those spans in z16
format to save on math & conversion.
|
|
|
|
| |
Disable blend code when no color buffer
|
| |
|
| |
|
| |
|
|
|
|
|
| |
Consolidate the read-modify-write color combining code from
the blend, colormask and output stages.
|
| |
|
| |
|
|
|
|
| |
First attempt
|
|
|
|
|
|
| |
This is part one -- we still only pass a single quad down, but
the code can now cope with more. The quads must all be from the same
tile.
|
| |
|
|
|
|
|
|
|
|
|
| |
There's no need to push out depth buffer contents on swapbuffers.
Note that this change doesn't throw away depth buffer changes, it simply
holds them in the cache over calls to swapbuffers. The hope is
that swapbuffers will be followed by a clear() which means in that case
we won't have to write the changes out.
|
| |
|
|
|
|
|
|
|
|
|
| |
The sp_tile_cache is often called repeatedly to look up the same
tile. Add a cache (to the cache) of the single tile most recently
retreived and make a quick inline check to see if this matches the
subsequent request.
Add a tile_address bitfield struct to make this check easier.
|
| |
|
| |
|
|
|
|
| |
No loss of performance, but simpler code.
|
|
|
|
| |
No performance gain yet, but the code is a bit cleaner.
|
|
|
|
|
|
|
|
| |
The tile cache is a utility, it shouldn't know anything about the
entity which is making use of it (ie softpipe).
Remove softpipe parameter to all the tilecache function calls, and
also remove the need to keep a softpipe pointer in the sampler structs.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Remove the need to have a pointer in this struct by just including
the immediate data inline. Having a pointer in the struct introduces
complications like needing to alloc/free the data pointed to, uncertainty
about who owns the data, etc. There doesn't seem to be a need for it,
and it is unlikely to make much difference plus or minus to performance.
Added some asserts as we now will trip up on immediates with more
than four elements. There were actually already quite a few such asserts,
but the >4 case could be used in the future to specify indexable immediate
ranges, such as lookup tables.
|
| |
|
|
|
|
|
| |
Flagged by the DRM command stream checker. This allows the driver to work on
non-R500 cards.
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Conflicts:
Makefile
progs/glsl/multitex.c
src/mesa/main/enums.c
src/mesa/main/state.c
src/mesa/main/texenvprogram.c
src/mesa/main/version.h
|
| | |
|
| |
| |
| |
| |
| | |
Most obvious problem is drawpixels comes out blocky, but this may be
an existing issue of KIL on the sse path.
|
| |
| |
| |
| |
| |
| | |
Pass the tgsi_exec_machine struct in directly and just hold a single
pointer to this struct, rather than keeping one for each of its
internal members.
|
| |
| |
| |
| |
| | |
Centralize the creation, initialization and destruction of this struct.
Use align_malloc instead of home-brew alternatives.
|
| |
| |
| |
| | |
default extension list
|
| |
| |
| |
| | |
Signed-off-by: Corbin Simpson <[email protected]>
|
| |
| |
| |
| | |
Signed-off-by: Corbin Simpson <[email protected]>
|
| | |
|
| |
| |
| |
| | |
Seriously.
|
| |
| |
| |
| | |
These will come back in someday, when we can properly use them.
|
| |
| |
| |
| | |
They have to cross into each other's registers.
|
| |
| |
| |
| | |
(cherry picked from commit 88c01a15da5639dd68a6a0133724994cb66f1316)
|
| |
| |
| |
| | |
As reported and initially tested by MrCooper.
|
|\|
| |
| |
| |
| |
| | |
Conflicts:
src/mesa/main/dlist.c
src/mesa/vbo/vbo_save_api.c
|
| |
| |
| |
| |
| |
| |
| |
| | |
mesa allocates both frontface and pointcoord registers within the fog
coordinate register, by using swizzling. to make it cleaner and easier
for drivers we want each of them in its own register. so when doing
compilation from the mesa IR to tgsi allocate new registers for both
and add new semantics to the respective declarations.
|