* 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.
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>
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>
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.
If an application never calls glUniform() to set sampler variable values
they'll remain 0 (the default value/unit).
Now call _mesa_update_shader_textures_used() at link time in case glUniform()
is never called. program->TextureUsed[] will then be correct for state
validation.
If an application never calls glUniform() to set sampler variable values
they'll remain 0 (the default value/unit).
Now call _mesa_update_shader_textures_used() at link time in case glUniform()
is never called. program->TextureUsed[] will then be correct for state
validation.
Now i965 also uses the vertex program created by Mesa Core, but this vertex program
is not only depend on mesa state _NEW_PROGRAM, so always check the current vertex
program is updated or not. This fixes broken demo cubemap.
