| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
emitted yet though)
|
|
|
|
|
|
Seems to fix a mysteriously missing build dependency.
|
|
We may emit these instructions from GLSL instead of DP3/RCP/MUL.
Also, implement SSG (set sign) instruction in the interpreter.
|
|
|
|
|
|
|
|
|
|
Trunc is a more accurate description; there's no type conversion involved.
|
|
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.
|
|
Zero-out the index for disabled execution channels to avoid using potential
garbage values (thus avoiding bad array indexing).
|
|
Fixes progs/vp/arl.txt test.
|
|
OPCODE_NOISE4 coming later.
|
|
|
|
|
|
cherry-picked subset of a77976d2ee578d0483c64f2aa41719bbae9c1c97
|
|
Expressions like array[i] + array[j] didn't work properly before.
|
|
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
|
|
|
|
draw time
This will warn the user that the shader being run may be using uninitialized
uniform variables.
|
|
Expressions like array[i] + array[j] didn't work properly before.
|
|
This prevents vertex shaders from referencing invalid memory locations when
the shader is operating on less than four vertices or fragments.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
