i965/vs: Fix setup of scratch space pointer on pre-gen6.
We were failing to relocate, so on the first draw run our scratch
would tend to get written to 0x0.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
i965/vs: Fix message setup for array read/writes on pre-gen6.
We were passing an MRF as the source argument, instead of using the
implied move and putting the MRF number in the proper place in the
instruction encoding.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
i965/vs: Make pre-gen6 math operate in vector mode instead of scalar.
On the old backend, we used scalar mode because Mesa IR math is
result.xyzw = math(op0.xxxx), which matched up well. However, in GLSL
IR we do things like result.xy = math(op0.xy), so we want vector mode.
For the common case of result.x = math(op0.x), performance will be the
same (no cost for un-executed channels), though result.xyzw =
math(op0.xxxx) would be worse.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
i965/vs: Fix gen4 comparisons used for predication.
When we tried to retype a brw_null_reg() in CMP(), the retyping didn't
take effect because HW_REG just ignores the type field.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
i965/vs: Fix GPU hangs in shaders with large virtual GRFs pre-gen6.
If you get your total GRF count wrong, you write over some other
shader's g0, and the GPU fails shortly thereafter.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
mesa: Remove support for unpacking from client memory to color-index pixels
Mesa hasn't supported color-index rendering for a long time.
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
swrast: Use GL_STENCIL_INDEX for address calculations
GL_COLOR_INDEX produced the same result (because GL_BITMAP is always
used for stencil glDrawPixels), but it was confusing to read. I spent
about 15 minutes wondering, "WTF?"
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
mesa: Remove GL_COLOR_INDEX from _mesa_{dest,source}_buffer_exists
Mesa hasn't supported color-index rendering for a long time.
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
mesa: Remove GL_COLOR_INDEX from base format assertions
_mesa_make_temp_float_image can't work on color-index textures, but
there is no such thing as a color-index texture anymore.
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
These sampling functions don't work on color-index textures, but there
is no such thing as a color-index texture anymore.
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
These enums were only valid with the paletted texture extensions.
This allows a couple other trivial clean-ups.
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
mesa: Remove dd_function_table::CopyColorTable, ::CopyColorSubTable, and ::UpdateTexturePalette
There's nothing left that can call any of these functions. This also
removes the meta-ops code that implemented the first two.
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
mesa: Remove API facing bits of EXT_paletted_texture and EXT_shared_texture_palette
This was also discussed at XDS 2010. However, actually making the
change was delayed because several drivers still exposed these
extensions to significant benefit (e.g., tdfx). Now that those
drivers have been removed, this code can be removed as well.
v2: A lot of bits that were missed in the previous patch have been removed.
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
i965: Remove two_side_color from brw_compute_vue_map().
Since we now lay out the VUE the same way regardless of whether
two-sided color is enabled, brw_compute_vue_map() no longer needs to
know whether two-sided color is enabled. This allows the two-sided
color flag to be removed from the clip, GS, and VS keys, so that fewer
GPU programs need to be recompiled when turning two-sided color on and
off.
Reviewed-by: Eric Anholt <eric@anholt.net>
i965: For GEN6+, always make front/back colors adjacent in VUE.
When doing two-sided color on GEN6+, we use the SF unit's
INPUTATTR_FACING mode to cause front colors to be used on front-facing
triangles, and back colors to be used on back-facing triangles. This
mode requires that the front and back colors be adjacent in the VUE.
Previously, we would only place front and back colors adjacent in the
VUE when two-sided color was enabled. Now we place them adjacent in
the VUE whether two-sided color is enabled or not. (We still only
swizzle the colors when two-sided color is enabled, so there should be
no user-visible change).
This simplifies the implementation of the VUE map and reduces the
amount of code that is dependent on two-sided color mode.
Reviewed-by: Eric Anholt <eric@anholt.net>
The previous computation had two bugs: (a) it used a formula based on
Gen5 for Gen6 and Gen7 as well. (b) it failed to account for the fact
that PSIZ is stored in the VUE header. Fortunately, both bugs caused
it to compute a URB size that was too large, which was benign. This
patch computes the URB size directly from the VUE map, so it gets the
result correct in all circumstances.
Reviewed-by: Eric Anholt <eric@anholt.net>
The variables offset[], idx_to_attr[], nr_bytes, nr_attrs, and
header_regs were all serving purposes which are now served by the VUE
map.
Reviewed-by: Eric Anholt <eric@anholt.net>
i965: clip: Remove assumption about VUE header from brw_clip_interp_vertex()
Previously, brw_clip_interp_vertex() iterated only through the
"non-header" elements of the VUE when performing interpolation
(because header elements don't need interpolation). This code now
refers exclusively to the VUE map to figure out which elements need
interpolation, so that brw_clip_interp_vertex() doesn't need to know
the header size.
Reviewed-by: Eric Anholt <eric@anholt.net>
i965: clip: Convert computations to ..._to_offset() for clarity.
This patch replaces some ad-hoc computations using ATTR_SIZE and the
offset[] array to use the VUE map functions
brw_vert_result_to_offset() and brw_vue_slot_to_offset().
Reviewed-by: Eric Anholt <eric@anholt.net>
i965: clip: Add a function to determine whether a vert_result is in use.
Previously we would examine the offset[] array (since an offset of 0
meant "not in use"). This paves the way for removing the offset[]
array.
Reviewed-by: Eric Anholt <eric@anholt.net>
i965: clip: Move hpos_offest and ndc_offset into local functions.
The offsets within the VUE of HPOS and NDC are needed only in a few
auxiliary clipping functions. This patch moves computation of those
offsets into the functions that need them, and does the computation
using the VUE map.
Reviewed-by: Eric Anholt <eric@anholt.net>
i965: SF: New implementation of get_attr_override using the VUE map.
This patch changes get_attr_override() (which computes the
relationship between vertex shader outputs and fragment shader inputs)
to use the VUE map.
Reviewed-by: Eric Anholt <eric@anholt.net>
This patch removes the variables nr_attrs and nr_setup_attrs, whose
purpose is now being served by the VUE map. nr_attr_regs and
nr_setup_regs are still needed, however they are now computed using
the VUE map rather than by counting the number of vertex shader
outputs (which caused subtle bugs when gl_PointSize was written).
Reviewed-by: Eric Anholt <eric@anholt.net>
i965: SF: Stop using nr_setup_attrs in compute_masks.
Previously, the SF used nr_setup_attrs to determine whether it was
looking at the last element of the VUE. Changed this code to use the
VUE map.
Reviewed-by: Eric Anholt <eric@anholt.net>
These data structures were serving the same purpose as the VUE map,
but were buggy. Now that the code has been transitioned to use the
VUE map, they are not needed.
Reviewed-by: Eric Anholt <eric@anholt.net>
i965: SF: Change calculate_masks to use the VUE map.
Previously, SF code used the idx_to_attr[] array to compute the
location of entries in the VUE map. This array didn't properly
account for gl_PointSize. Now we use the VUE map directly.
Reviewed-by: Eric Anholt <eric@anholt.net>
i965: SF: Change the flags that refer to "attr" to be based on gl_vert_result.
Previously, some of the code in SF erroneously used bitfields based on
the gl_frag_attrib enum when actually referring to vertex results.
This worked, because coincidentally the particular enum values being
used happened to match between gl_frag_attrib and gl_vert_result. But
it was fragile, because a future change to either gl_vert_result or
gl_frag_attrib would have made the enum values stop matching up. This
patch switches the SF code to use the correct enum.
Reviewed-by: Eric Anholt <eric@anholt.net>
i965: SF: change get_vert_attr to use the VUE map, and rename it.
The new function, called get_vert_result(), uses the VUE map to find
the register containing a given vertex attribute. Previously, we used
the attr_to_idx[] array, which served the same purpose but didn't
account for gl_PointSize correctly.
This fixes a bug on pre-Gen6 wherein the back side of a triangle would
be rendered incorrectyl if the vertex shader wrote to gl_PointSize.
Reviewed-by: Eric Anholt <eric@anholt.net>
Eric Anholt