This patch implements proper support for gl_ClipVertex by causing the
new VS backend to populate the clip distance VUE slots using
VERT_RESULT_CLIP_VERTEX when appropriate, and by using the
untransformed clip planes in ctx->Transform.EyeUserPlane rather than
the transformed clip planes in ctx->Transform._ClipUserPlane when a
GLSL-based vertex shader is in use.
When not using a GLSL-based vertex shader, we use
ctx->Transform._ClipUserPlane (which is what we used prior to this
patch). This ensures that clipping is still performed correctly for
fixed function and ARB vertex programs. A new function,
brw_select_clip_planes() is used to determine whether to use
_ClipUserPlane or EyeUserPlane, so that the logic for making this
decision is shared between the new and old vertex shaders.
Fixes the following Piglit tests on i965 Gen6:
- vs-clip-vertex-const-accept
- vs-clip-vertex-const-reject
- vs-clip-vertex-different-from-position
- vs-clip-vertex-equal-to-position
- vs-clip-vertex-homogeneity
- vs-clip-based-on-position
- vs-clip-based-on-position-homogeneity
- clip-plane-transformation clipvert_pos
- clip-plane-transformation pos_clipvert
- clip-plane-transformation pos
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Chad Versace <chad@chad-versace.us>
Before this patch, clip planes didn't work properly in Mesa when using
vertex shaders, because Mesa assigned both gl_ClipVertex and
gl_Position to the same gl_vert_result (VERT_RESULT_HPOS). As a
result, backends couldn't distinguish between the two variables, so
any shader that wrote different values to them would fail to work
properly.
This patch paves the way for proper support of gl_ClipVertex by
creating a new enumerated value in gl_vert_result for it
(VERT_RESULT_CLIP_VERTEX). After this patch, a back-end may add
support for gl_ClipVertex using the following algorithm:
- If using a user-supplied GLSL vertex shader:
- If the bit corresponding to VERT_RESULT_CLIP_VERTEX is set in
gl_program::OutputsWritten:
- Clip using the vertex shader output VERT_RESULT_CLIP_VERTEX and
the clip planes defined in gl_context::Transform.EyeUserPlane.
- Else:
- Clip using the vertex shader output VERT_RESULT_HPOS and the
clip planes defined in gl_context::Transform.EyeUserPlane.
- Else (either using fixed function or an ARB vertex program):
- Clip using the vertex shader output VERT_RESULT_HPOS and the clip
planes defined in gl_context::Transform._ClipUserPlane (*)
where (*) represents the normal Mesa behavior before this patch.
An example of implementing the above algorithm can be found in the
patch that follows this one, which implements gl_ClipVertex in i965
Gen6.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
The previous change was not effective for lines, because there is no
4 planes 4x4 block rasterization path: it is handled by the 16x16 block
case too, and the 16x16 block was not being budged as it should.
This fixes assertion failures on line rasterization.
llvmpipe has a few special rasterization paths for triangles contained in
16x16 blocks, but it allows the 16x16 block to be aligned only to a 4x4
grid.
Some 16x16 blocks could actually intersect the tile
if the triangle is 16 pixels in one dimension but 4 in the other, causing
a buffer overflow.
The fix consists of budging the 16x16 blocks back inside the tile.
This just adds the entries to the table and fixes the asserts up.
The int32 one is definitely wrong, since it uses a float temp
which will lose precision, but its no worse than now.
Signed-off-by: Dave Airlie <airlied@redhat.com>
This is taken from reading EXT_texture_integer + EXT_texture_rg in combination,
Comments on necessity of each format, naming of formats and bugs in the
formats tables please.
Is there any formats I've missed?
Eric looked over this to make sure its consistent at least.
As I've changed the ordering of things in the format table, the follow
patches are required to avoid regression.
Signed-off-by: Dave Airlie <airlied@redhat.com>
As per Brian's suggestion we can generate this table at first start
to make sure its correct. This is a sad workaround for compilers which
don't support named initialiser. (its 2011).
Signed-off-by: Dave Airlie <airlied@redhat.com>
Commit d1fda903 (radeon: Drop mapping we were doing around
glGetTexImage()) removed the common Radeon source file
radeon_tex_getimage.c, and pulled it out of the r200, r300, r600, and
radeon makefiles. But it left behind the symlinks that were being
used to share that file among the four directories.
This patch removes the dangling symlinks.
Reviewed-by: Brian Paul <brianp@vmware.com>
We want quad/pixel Z values to be interpolated exactly the same for
multi-pass algorithms. Because of how the optimized Z-test code is
written, we can't cull the first quad in a run even if it's totally
killed. See the comment for more info.
NOTE: This is a candidate for the 7.11 branch.
Instead of relying on the mirror in the Mesa IR assembly shader, just
use the variables actually stored in the GLSL IR. This will be a bit
slower, but nobody cares about the performance of glGetActiveAttrib.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
This just folds get_active_attrib into _mesa_GetActiveAttribARB
and moves the resulting function function to the other source file.
More changes are coming soon.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
This currently mirrors the state tracking
gl_shader_program::Attributes, but I'm working towards eliminating
that.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
This just folds bind_attrib_location into _mesa_BindAttribLocationARB
and moves the resulting function function to the other source file.
More changes are coming soon.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
hash_table_replace doesn't use get_node to avoid having to hash the key twice.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
This allows querying the linked shader itself rather than the Mesa IR.
This is the first step towards removing gl_program::Attributes.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
The symbol table in the linked shaders may contain references to
variables that were removed (e.g., unused uniforms). Since it may
contain junk, there is no possible valid use. Delete it and set the
pointer to NULL.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
All drivers in Mesa have supported this extension for eons. This
extension is an optional features in desktop OpenGL (via
GL_ARB_draw_buffers) and OpenGL ES 2.x (via GL_NV_draw_buffers).
The extension is not usable in OpenGL ES 1.x. There is no
glDrawBuffers* entry point in OpenGL ES 1.x contexts, and glGet*v
generate errors when MAX_DRAW_BUFFERS or DRAW_BUFFERi is queried.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
This also moves ATI_draw_buffers. This is to facilitate enabling
NV_draw_buffers in OpenGL ES 2.0.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Us poor souls who cross compile mesa want to be able to specify which pkg-config to pick, or at least just change one place.
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
