| Age | Commit message (Collapse) | Author |
|---|
|
Up till now, nv20 driver has been using NV10TCL, and being
really an nv10 driver. That has changed.
Signed-off-by: Pekka Paalanen <pq@iki.fi>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
A small step toward SIMD-izing the code.
|
|
|
|
Also changes nvgl_primitive() to return zero, i.e. error, on unknown
primitive.
Signed-off-by: Pekka Paalanen <pq@iki.fi>
|
|
Signed-off-by: Pekka Paalanen <pq@iki.fi>
|
|
Signed-off-by: Pekka Paalanen <pq@iki.fi>
|
|
Fresh from renouveau.
Signed-off-by: Pekka Paalanen <pq@iki.fi>
|
|
This is nv10 commands, but is in nv20 source files.
Signed-off-by: Pekka Paalanen <pq@iki.fi>
|
|
This is still for NV10 hardware.
Signed-off-by: Pekka Paalanen <pq@iki.fi>
|
|
|
|
Also, update some comments.
|
|
Use tgsi_sampler struct as a base class. Softpipe subclasses it and adds
the fields it needs.
|
|
This is a set of changes that optimizes the memory use of fragment
operation programs (by using and transmitting only as much memory as is
needed for the fragment ops programs, instead of maximal sizes), as well
as eliminate the dependency on hard-coded maximal program sizes. State
that is not dependent on fragment facing (i.e. that isn't using
two-sided stenciling) will only save and transmit a single
fragment operation program, instead of two identical programs.
- Added the ability to emit a LNOP (No Operation (Load)) instruction.
This is used to pad the generated fragment operations programs to
a multiple of 8 bytes, which is necessary for proper operation of
the dual instruction pipeline, and also required for proper SPU-side
decoding.
- Added the ability to allocate and manage a variant-length
struct cell_command_fragment_ops. This structure now puts the
generated function field at the end, where it can be as large
as necessary.
- On the PPU side, we now combine the generated front-facing and
back-facing code into a single variant-length buffer (and only use one
if the two sets of code are identical) for transmission to the SPU.
- On the SPU side, we pull the correct sizes out of the buffer,
allocate a new code buffer if the one we have isn't large enough,
and save the code to that buffer. The buffer is deallocated when
the SPU exits.
- Commented out the emit_fetch() static function, which was not being used.
|
|
As suggested by Brian Paul: in the case of a twiddling error, instead
of reporting the bad format number (which is all but unusable), report
the more useful enum name.
|
|
|
|
Many stencil tests were failing because of a failure to read the
stencil buffer, due to "twiddling" (or "untwiddling") "an unsupported
texture format". This is fixed for the case of a stencil/Z S824Z format
(which twiddles just like the 32-bit color formats).
tests/stencilwrap.c was failing on the GL_INVERT test, because
the emitted code for "spe_xori" turned out not to be an actual
"xori" instruction, but rather a "stqd" instruction, because
of a typo in the rtasm code. This is now fixed, and
tests/stencil_wrap now works.
|
|
git+ssh://marcheu@git.freedesktop.org/git/nouveau/mesa into gallium-0.2
|
|
Signed-off-by: Pekka Paalanen <pq@iki.fi>
|
|
* commit 'origin/gallium-0.1':
Mesa: fix number of buffers in st_draw_vbo().
Nouveau: fix nv20_vertex_layout()
Nouveau: update nv20 miptree according to nv40.
Nouveau: build, link and use nv20.
Nouveau: name replace for nv20.
Nouveau: Rename nv20/ files as nv20.
Nouveau: copy nv30_vertprog.c to nv20.
Nouveau: start nv20 by copying the nv10 tree.
|
|
Fixed a boneheaded error in the generation of SPU code that calculates
the results of the stencil test. Basically, all the greater than/less than
calculations were exactly inverted: they were coded as though the
given comparison took the stencil value as a left-hand operand and the
reference value as a right-hand operand, but the actual semantics always
put the reference as the left-hand operand and the stencil as the right-hand
operand.
With this fix, tests/dinoshade runs, as do all the other Mesa tests
and samples that use stencil (and that don't use texture formats
unsupported by Cell).
|
|
|
|
|
|
|
|
With these changes, the tests/stencil_twoside test now works.
- Eliminate blending from the stencil_twoside test, as it produces an
unneeded dependency on having blending working
- The spe_splat() function will now work if the register being splatted
and the destination register are the same
- Separate fragment code generated for front-facing and back-facing
fragments. Often these are the same; if two-sided stenciling is on,
they can be different. This is easier and faster than generating
code that does both tests and merges the results.
- Fixed a cut/paste bug where if the back Z-pass stencil operation
were different from all the other operations, the back Z-fail
results were incorrect.
|
|
|
|
|
|
This allows us to use SSE codegen with debug builds again.
When PIPE_ARCH_SSE is set (w/ gcc -msse -msse2) we will also use the
gcc SSE intrinsic functions.
|
|
The function should update nv20->vertex_info, and not just a
local struct that's thrown away immediately.
Fixes a SIGFPE due to vbuf->vertex_size = 0 in vbuf_alloc_vertices().
Signed-off-by: Pekka Paalanen <pq@iki.fi>
|
|
glxinfo doesn't degfault anymore.
Signed-off-by: Pekka Paalanen <pq@iki.fi>
|
|
Signed-off-by: Pekka Paalanen <pq@iki.fi>
|
|
No functional changes, only changed function, struct, macro etc. names.
nv10 -> nv20
nv30 -> nv20
celsius -> kelvin
Did not touch fifo command macros.
Don't try to build nv20_vertprog.c for now.
Signed-off-by: Pekka Paalanen <pq@iki.fi>
|
|
Signed-off-by: Pekka Paalanen <pq@iki.fi>
|
|
Signed-off-by: Pekka Paalanen <pq@iki.fi>
|
|
Signed-off-by: Pekka Paalanen <pq@iki.fi>
|
|
This small set of changes repairs several different stenciling problems;
now redbook/stencil also runs correctly (and maybe others - I haven't
checked everything yet).
- The number of instructions that had been allocated for fragment ops
used to be 64 (in cell/common.h). With complicated stencil use, we
managed to get up to 93, which caused a segfault before we noticed
we'd overran our memory buffer. It's now been bumped to 128,
which should be enough for even complicated stencil and fragment op
usage.
- The status of cell surfaces never changed beyond the initial
PIPE_SURFACE_STATUS_UNDEFINED. When a user called glClear()
to clear just the Z buffer (but not the stencil buffer), this caused
the check_clear_depth_with_quad() function to return false (because
the surface status was believed to be undefined), and so the device
was instructed to clear the whole buffer (including the stencil buffer),
instead of correctly using a quad to clear just the depth, leaving the
stencil alone.
This has been fixed similarly to the way the i915 driver handles
the surface status: during cell_clear_surface(), the status is
set to PIPE_SURFACE_STATUS_DEFINED. Then a partial buffer clear is
handled with a quad, as expected. Note that we are *not* using
PIPE_SURFACE_STATUS_CLEAR (also similar to the i915); technically,
we should be setting the surface status to CLEAR on a clear, and
to DEFINED when we actually draw something (say on cell_vbuf_draw()),
but it's difficult to figure out exactly which surfaces are affected
by a cell_vbuf_draw(), so for now we're doing the easy thing.
- The fragment ops handling was very clever about only pulling out the
parts of the Z/stencil buffer that it needed for calculations;
but this failed when only part of the buffer was written, because
the part that was never pulled out was inadvertently cleared.
Now all the data from the combined Z/stencil buffer is pulled out,
just so the proper values can be recombined later and written back
to the buffer correctly. As a bonus, the fragment op code generation
is simplified.
|
|
|
|
|
|
|
|
Conflicts:
src/gallium/auxiliary/rtasm/rtasm_execmem.c
src/mesa/shader/slang/slang_emit.c
src/mesa/shader/slang/slang_log.c
src/mesa/state_tracker/st_atom_framebuffer.c
|
|
This prevents vertex shaders from referencing invalid memory locations when
the shader is operating on less than four vertices or fragments.
|
|
The Cell stencil tests were completely ignoring the stencil value mask.
Now the original code paths are still used if the stencil value mask
is all 1s; but code to use the mask for the stencil value and reference
value comparisons is now emitted if the mask is not all 1s.
|
|
|
|
Two definitive bugs in stenciling were fixed.
The first, reversed registers in the generated Select Bytes (selb)
instruction, caused the stenciling INCR and DECR operations to
fail dramatically, putting new values in where old values were
supposed to be and vice versa.
The second caused stencil tiles to not be read and written from
main memory by the SPUs. A per-spu flag, spu.read_depth, was used
to indicate whether the SPU should be reading depth tiles, and was set
only when depth was enabled. A second flag, spu.read_stencil, was
set when stenciling was enabled, but never referenced.
As stenciling and depth are in the same tiles on the Cell, and there
is no corresponding TAG_WRITE_TILE_STENCIL to complement
TAG_WRITE_TILE_COLOR and TAG_WRITE_TILE_Z, I fixed this by
eliminating the unused "spu.read_stencil", renaming "spu.read_depth"
to "spu.read_depth_stencil", and setting it if either stenciling or
depth is enabled.
I also added an optimization to the fragment ops generation code,
that avoids calculating stencil values and/or stencil writemask
when the stencil operations are all KEEP.
|
