| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
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.
|
|
Makes some difference, but suprisingly little. Barely worth the effort.
|
|
The leading underscore is meaningful... This function is used by
_warning and _error functions as well as the more common
debug_printf().
debug_printf (without underscore) gets turned off when DEBUG is
disabled, but warning/error messages still use this function to get
their message out.
|
|
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.
|
|
This is a source of ongoing confusion. TGSI has multiple names for
opcodes where the same semantics originate in multiple shader APIs.
For instance, TGSI includes both Mesa/GLSL and DX/SM30 names for
opcodes with the same semantics, but aliases those names to the same
underlying opcode number.
This makes it very difficult to visually inspect two sets of opcodes
(eg in state tracker & driver) and check if they implement the same
functionality.
This patch arbitarily rips out the versions of the opcodes not currently
favoured by the mesa state tracker and leaves us with a single name
for each distinct operation.
|
|
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.
|
|
This fixes segfaults in apps like teapot and tunnel
|
|
This reverts commit cc893d9a98255d3c26df7123ba5cc02e478c9328.
Richard has the proper fix.
|
|
|
|
|
|
|
|
|
|
|
|
not working yet
|
|
We need to emit a relocation for pitch register so that kernel can
check and properly setup tiling on the color buffer.
|
|
|
|
|
|
|
|
Compiling mesa on a system with no X headers installed in the default
include paths fails due to missing X11 includes. The header includes are
picked up by configure but not applied.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
