Age | Commit message (Collapse) | Author |
|
VP outputs that should be loadable in the FP are mapped to
interpolant indices by HPOS, COL0 etc.; of course HPOS is
always written, so the highest byte of 1988 is a bitmask that
selects which components of HPOS are used for interpolants,
i.e. the FP inputs in COL0 start at index POPCNT(1988[24:28]).
|
|
Record interpolation mode for attributes while parsing declarations,
and also remember the indices of FP color inputs and FP depth output,
which has to end up in the highest output register.
|
|
We now inspect the TGSI instructions in tx_prep to determine where
temps and FP attrs are last accessed.
This will enable us to reclaim some temporaries early and we also
use it to omit pre-loading FP attributes that aren't used.
|
|
We could do even better (like just allocating 1 value in alloc_immd),
but that's fine for now I guess.
|
|
|
|
According to tgsi-instruction-set.txt, if they are written, z and w
should be set to 0 and 1 respectively in SCS, and w to 1.0 in XPD.
|
|
|
|
|
|
|
|
|
|
Use the first vertex, not the last.
|
|
In spu_tri.c:setup_sort_vertices() triangles are culled after the
vertices are sorted. This patch moves the check a little earlier
and performs the actual check a little faster through intrinsics and
a little trickery.
Reduced code size and less work is done before a triangle is deemed
OK to skip.
|
|
It was taking approximately 50 cycles to extract the vertex indices,
calculate the vertex_header pointers and call tri_draw() for each
three vertices - .
Unrolled, it takes less than 100 cycles to extract, unpack,
calculate pointers and call tri_draw() eight times. It does have a
nasty jump-tabled switch. I'm sure that there's a better way...
Code size of spu_render.o gets larger due to the extra constants and
work in the inner loop, there are extra stack saves and loads
because there are more registers in use, and an assert. spu_tri.o
gets a little smaller.
|
|
I feel so unclean.
|
|
Goddammit. This cannot be the "easy way." :C
|
|
|
|
Seems like this file is the source of all bad logic. (Pun intended.)
|
|
Less briefly... Shaders need to be recompiled if their constantbuf
offsets have changed. However, since we only change them from shaders if
immediates need to be emitted, we shouldn't bother if the shader doesn't
use immediates.
|
|
Still not correct, but really I don't care.
|
|
|
|
|
|
Per 74cb2aba on xf86-video-ati.
|
|
|
|
This fixes some silent problems in current libdrm_radeon.
surface_copy still locks up hard.
|
|
|
|
Again, thanks to agd5f.
|
|
|
|
This makes glxgears draw properly with SW TCL.
|
|
Conflicts:
Makefile
src/mesa/main/version.h
|
|
|
|
Before you get all excited, this is *not* to be construed as actual support
for GLSL shaders. The GL version is still 1.3, and stuff still sucks. Just
flicking it on so that it can be tested and developed a bit easier.
|
|
Oh, look, GLSL instructions. I wonder what I'll do next.
|
|
HW trig does a premultiply by 2pi, where Mesa does another premultiply by pi.
This is a problem.
|
|
|
|
See the previous commit for an explanation. This is just all the support code
for GB_TILE_CONFIG.
|
|
This accompanies kernel patches that make GB_TILE_CONFIG's various members
completely controlled in DRM.
GB_TILE_CONFIG has the following controls:
- The number of GB (pixel) pipes enabled
- The size and style of tiling
- Subpixel precision (either 1/12 or 1/16)
Per airlied and glisse, userspace and kernel will now agree (always) on
a subpixel precision of 1/12, and tiling will always be kernel-controlled.
|
|
GA_ENHANCE is now the kernel's problem.
|
|
Lops work fine as long as HW TCL is off. (I think I know why.)
|
|
Per agd5f.
|
|
Makes the last three commits suck much less. :3
|
|
Should work, but doesn't. Hm.
|
|
Those parts are nearly solid compared to the shaders.
|
|
|
|
Odds are good that we'll die later anyway, so we might as well do it before
we start dancing on random memory.
|
|
Even though we *can* render 10,000-pixel-wide lines, let's not advertise it.
|
|
Anisotropic filtering should work, and OQ is broken.
|
|
BEGIN/END_CS pair, a few asserts, and a slightly more correct VTE setup.
|
|
Drivers can just keep track of whether they are within a query
by monitoring the begin/end query callbacks. The flag adds no
information beyond that.
Only softpipe was examining this flag -- it has been fixed up
and retested with demos/arbocclude.
|
|
|
|
|