| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When gl_ClipDistance is in use, the contents of the gl_ClipDistance
array just need to be copied directly into the clip distance VUE
slots, so we re-use the code that copies all other generic VUE slots
(this has been extracted to its own method). When gl_ClipDistance is
not in use, the vertex shader needs to calculate the clip distances
based on user-specified clipping planes.
This patch also removes the i965-specific enum values
BRW_VERT_RESULT_CLIP[01], since we now have generic Mesa enums that
serve the same purpose (VERT_RESULT_CLIP_DIST[01]).
Reviewed-by: Eric Anholt <[email protected]>
|
|
|
|
|
|
|
|
| |
When the vertex shader writes to gl_ClipDistance, we do clipping based
on clip distances rather than user clip planes, so don't waste push
constant space storing user clip planes that won't be used.
Reviewed-by: Eric Anholt <[email protected]>
|
|
|
|
|
|
|
|
| |
i965 requires gl_ClipDistance to be formatted as an array of 2 vec4's
(as opposed to an array of 8 floats), so enable the lowering pass that
performs this conversion.
Reviewed-by: Eric Anholt <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In order to support 8 clip distances, we need to properly decode when
the user sets the GL_CLIP_DISTANCE6 and GL_CLIP_DISTANCE7 enable
flags.
For clarity, this patch changes the names GL_CLIP_PLANE[0-5] in the
switch statement to the equivalent names GL_CLIP_DISTANCE[0-5], since
the GL_CLIP_PLANE names are deprecated.
Reviewed-by: Eric Anholt <[email protected]>
Tested-by: Brian Paul <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch assigns enumerated values for gl_ClipDistance in the
gl_vert_result and gl_frag_attrib enums, so that driver back-ends can
assign gl_ClipDistance to the appropriate hardware registers. It also
adjusts the functions _mesa_vert_result_to_frag_attrib() and
_mesa_frag_attrib_to_vert_result() (which translate between the two
enums) to correctly translate the new enumerated values.
Reviewed-by: Eric Anholt <[email protected]>
Tested-by: Brian Paul <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
GLSL 1.30 requires us to use gl_ClipDistance for clipping if the
vertex shader contains a static write to it, and otherwise use
user-defined clipping planes. Since the driver needs to behave
differently in these two cases, we need a flag to record whether the
shader has written to gl_ClipDistance.
The new flag is called UsesClipDistance. We initially store it in
gl_shader_program (since that is the data structure that is available
when we check to see whethe gl_ClipDistance was written to), and we
later copy it to a flag with the same name in gl_vertex_program, since
that is a more convenient place for the driver to access it (in i965,
at least).
Reviewed-by: Eric Anholt <[email protected]>
Tested-by: Brian Paul <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In i965 GEN6+ (and I suspect most other hardware), gl_ClipDistance
needs to be laid out as a pair of vec4's (the first containing clip
distances 0-3, and the second containing clip distances 4-7).
However, it is declared in GLSL as an array of 8 floats.
This lowering pass acts at the GLSL level, modifying the declaration
of gl_ClipDistance so that it is an array of vec4's rather than an
array of floats, and renaming it to gl_ClipDistanceMESA. In addition,
it modifies all accesses to the array so that they access the
appropiate component of one of the vec4's.
Since some hardware may not internally represent gl_ClipDistance as a
pair of vec4's, this lowering pass is optional. To enable it, set the
LowerClipDistance flag in gl_shader_compiler_options to true.
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch fixes a bug in ir_hirearchical_visitor: when traversing an
exec_list representing the formal or actual parameters of a function,
it modified base_ir to point to each parameter in turn, rather than
leaving it as a pointer to the enclosing statement. This was a
problem, since base_ir is used by visitor classes to locate the
statement containing the node being visited (usually so that
additional statements can be inserted before or after it). Without
this fix, visitors might attempt to insert statements into parameter
lists.
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
| |
Include mtypes.h.
Signed-off-by: Chad Versace <[email protected]>
|
| |
|
|
|
|
| |
It was always zero.
|
|
|
|
| |
Be consistent with other functions in the file. And add some comments.
|
|
|
|
| |
'shader' is more intuitive. Also s/int/unsigned/ and add assertions.
|
|
|
|
|
|
| |
Previously we were using a hodge podge of int vs. pipe_enum and
0 vs. PIPE_OK. Some functions that always returned PIPE_OK were
made void.
|
|
|
|
|
| |
Without this, apps/tests that tried to use a DXT/sRGB format would die on
a failed assertion (st_texture.c:80).
|
|
|
|
|
|
| |
Only the XYZ components are checked to be negative by SVGA3DOP_TEXKILL.
GL_ARB_fp requires all four components be checked. Emit a second texkill
for W if needed.
|
|
|
|
|
|
|
| |
We only need to do the divide by Q step for TXP instructions.
This fixes the incorrectly rendered soft shadow test in Lightsmark.
Along with the previous texture swizzle commit, this also fixes all
the piglit glsl-fs-shadow2d-XX.shader_test failures.
|
|
|
|
|
|
|
| |
This exposes the GL_EXT_texture_swizzle extension and allows the various
depth texture modes to be implemented properly. This, plus a follow-on
texture/shadow change fixes quite a few piglit GLSL shadow sampler test
failures.
|
| |
|
|
|
|
|
|
| |
Emit the SVGA3D_RS_POINTSPRITEENABLE render state.
When sprite_coord_mode=PIPE_SPRITE_COORD_LOWER_LEFT emit extra frag
shader code to invert the Y coordinate of the incoming texcoord.
|
| |
|
|
|
|
| |
See bug 688394
|
|
|
|
|
|
| |
Accurately describe what operations are supported when a format caps
entry is not advertised by the host, and which formats are never
supported, instead of making ad-hoc and often incorrect assumptions.
|
|
|
|
|
|
|
| |
sampled from.
Mitigates issues with hosts where support for these new depth formats is
flaky.
|
| |
|
| |
|
| |
|
|
|
|
| |
TODO: Can we pass this as the same texcoord as fog?
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
HWv8 feature.
Tested with GoogleEarth, Mesa demos.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
It is sometimes useful to examine the first frame or and early frame of a
quickly executing and non-repeating application, this chain introduces a new
environment variable that is checked when creating contexts. If
GALLIUM_RBUG_START_BLOCKED is set, then each context that is created is started
in a blocked state. This allows time to connect rbug before anything is
rendered in the context.
|
|
|
|
| |
draw_pt_fetch_pipeline_or_emit_llvm()
|
|
|
|
|
|
|
|
|
|
|
|
| |
There is already comments show how to detect a null texture. Fix the
code to match the comments.
This would fix the oglc divzero(basic.texQOrWEqualsZero) and
divzero(basic.texTrivialPrim) test case fail.
Signed-off-by: Yuanhan Liu <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
Reviewed-by: Eric Anholt <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fix the constant interpolation enable bit mask for flat light mode.
FRAG_BIT_COL0 attribute bit might be 0, in which case we need to
shift one more bit right.
This would fix the oglc specularColor test fail on both Sandybridge and
Ivybridge.
v2: move the constant interp bitmask setup code into for(; attr <
FRAG_ATTRIB_MAX; attr++) loop suggested by Eric.
Signed-off-by: Yuanhan Liu <[email protected]>
Signed-off-by: Xiang, Haihao <[email protected]>
|
|
|
|
| |
That helps reduce the number of texture indirections, which are very limited on i915.
|
| |
|
|
|
|
|
| |
We didn't use the face parameter and the level parameter can be found
in the gl_texture_image.
|
| |
|
| |
|
|
|
|
|
| |
Reviewed-by: Ian Romanick <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
|
| |
Since the blit gets sequenced after other batchbuffer rendering like
normal, there's no need to push things out early.
Reviewed-by: Kenneth Graunke <[email protected]>
Reviewed-by: Ian Romanick <[email protected]>
|
|
|
|
|
|
|
|
|
|
| |
All that matters here is the format of the texture, not the
internalformat (which might mean various different pixel formats). In
one case, the pbo upload for MESA_FORMAT_YCBCR would have swapped the
channels for MESA_FORMAT_YCBCR_REV.
Reviewed-by: Kenneth Graunke <[email protected]>
Reviewed-by: Ian Romanick <[email protected]>
|
|
|
|
|
|
|
|
|
| |
This also improves the debugging output in the failure paths so you
get more than just "failed", and don't get spammed with "failed" when
you didn't even have a PBO to try.
Reviewed-by: Kenneth Graunke <[email protected]>
Reviewed-by: Ian Romanick <[email protected]>
|
|
|
|
|
|
|
|
| |
This hasn't been true since dd26899ca39111e0866afed9df94bfb1618dd363
in 2009.
Reviewed-by: Kenneth Graunke <[email protected]>
Reviewed-by: Ian Romanick <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
| |
There were notes about the possibility of slowdowns due to zcopy from
a PBO due to thrashing around of the region. Slowdowns are even more
likely now that textures are generally tiled, which a zcopy wouldn't
get. Additionally, there were no checks on the buffer size to ensure
that the hardware-required rounding was present, which could result in
GPU hangs on large zcopy PBOs.
Reviewed-by: Ian Romanick <[email protected]>
|