Other parts of the code already caught things like 'float x[4][2]'.
However, nothing caught 'float [4] x[2]'.
Fixes piglit test array-multidimensional-new-syntax.vert.
NOTE: This is candidate for the 7.11 branch.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
The idea here is to set up the message header with the Sampler State
pointer which the hardware provides as part of the PS Thread Payload in
register g0.
Unfortunately, the existing code
fs_reg(GRF, 0, BRW_REGISTER_TYPE_UD))
actually references "virtual GRF 0" rather than the hardware g0. This
is just some arbitrary GRF temporary which will get register allocated.
So, we ended up setting up the header with garbage.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
Fixes the remainder of piglit GL_EXT_packed_float/pack.c
Reviewed-by: Marek Ol ák <maraeo@gmail.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Fixes the 1000000.0 overflow cases of piglit
GL_EXT_packed_float/pack.c
Reviewed-by: Marek Ol ák <maraeo@gmail.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
From the GL_EXT_packed_float spec:
For an RGBA color, if <type> is not one of FLOAT,
UNSIGNED_INT_5_9_9_9_REV_EXT, or UNSIGNED_INT_10F_11F_11F_REV_EXT,
or if the CLAMP_READ_COLOR_ARB is TRUE, or CLAMP_READ_COLOR_ARB
is FIXED_ONLY_ARB and the selected color (or texture) buffer is
a fixed-point buffer, each component is first clamped to [0,1].
Then the appropriate conversion formula from table 4.7 is applied
the component."
(but we previously resolved that the CLAMP_READ_COLOR bit is not
relevant to glGetTexImage())
This fixes most of the cases in piglit GL_EXT_packed_float/pack.
Reviewed-by: Marek Ol ák <maraeo@gmail.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
This code was copy and pasted from the 11F unpacking, but not updated
for actually being 10 bits instead of 11.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=41206
Reviewed-by: Marek Ol ák <maraeo@gmail.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
This is only used in the code for packing to INF, and resulted in an
extra bit set that was set anyway, so it was harmless except for the
confusion caused.
Reviewed-by: Marek Olšák <maraeo@gmail.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
From page 22 (28 of PDF) of GLSL 1.30 spec:
It is an error to provide a literal integer whose magnitude is too
large to store in a variable of matching signed or unsigned type.
Unsigned integers have exactly 32 bits of precision. Signed integers
use 32 bits, including a sign bit, in two's complement form.
Fixes piglit int-literal-too-large-0[123].frag.
v2: Take care with INT_MIN, use stroull, and make it a function.
Reviewed-by: Paul Berry <stereotype441@gmail.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
There's no sense in building a broken driver. Previously, there was
the potential of building a DRI1-only driver that would work for DRI1
and fail on DRI2 because the newer libdrm code wasn't present. Now
the radeon build system should be matching intel and nouveau.
This can probably be reduced even further by moving this logic to the
scissor state update or just removing the logic entirely, but I don't
trust myself in radeon quite that much.
It's past time, and it was going to get in the way of the renderbuffer
mapping refactor. We dropped all the other DRI1 drivers for this
release, and I can't imagine anybody supporting DRI1 radeon classic in
a new release of Mesa.
Diff produced by treating kernel_mm as true, deleting the DRI1 paths
that produce kernel_mm false, and deleting code.
They have been superseded by the gallium equivalents.
Acked-by: Michel Dänzer <michel@daenzer.net>
Acked-by: Alex Deucher <alexdeucher@gmail.com>
Acked-by: Dave Airlie <airlied@gmail.com>
Acked-by: Corbin Simpson <mostawesomedude@gmail.com>
It's past time, and it was going to get in the way of the renderbuffer
mapping refactor. We dropped all the other DRI1 drivers for this
release, and I can't imagine anybody supporting DRI1 radeon classic in
a new release of Mesa.
Cleanup of the resulting dead code to follow.
Acked-by: Alex Deucher <alexander.deucher@amd.com>
These are effectively doing type->get_base_type()->base_type, which is
equivalent to type->base_type. Just use that, as it's simpler.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
And not all existing queries. The only reason we have that list is to be able
to suspend and resume the active ones.
This reduces looping over queries when suspending and resuming.
The queries no longer have to track some of their states.
We weren't setting TEX_SEM_WAIT on instructions that read the value of a
TEX instruction and also wrote the same register as the TEX instruction.
This is the sequence we were miscompiling:
1: TEX temp[0], input[2].xy__, 2D[0]
...
16: src0.xyz = temp[22], src1.xyz = temp[0], src2.xyz = temp[19]
MAD temp[0].xyz, src0.xxx, src1.xyz, src2.xxx
https://bugs.freedesktop.org/show_bug.cgi?id=42090
This required the following changes:
- WM setup now makes the appropriate set of barycentric coordinates
(perspective vs. noperspective) available to the fragment shader,
based on whether the shader requires perspective interpolation,
noperspective interpolation, both, or neither.
- The fragment shader backend now uses the appropriate set of
barycentric coordiantes when interpolating, based on the
interpolation mode returned by
ir_variable::determine_interpolation_mode().
- SF setup now uses gl_fragment_program::InterpQualifier to determine
which attributes are to be flat shaded (as opposed to the old logic,
which only flat shaded colors).
- CLIP setup now ensures that the clipper outputs non-perspective
barycentric coordinates when they are needed by the fragment shader.
Fixes the remaining piglit tests of interpolation qualifiers that were
failing:
- interpolation-flat-*-smooth-none
- interpolation-flat-other-flat-none
- interpolation-noperspective-*
- interpolation-smooth-gl_*Color-flat-*
Reviewed-by: Eric Anholt <eric@anholt.net>
The name was misleading. The actual effect of the bit is to cause
the clipper to emit *non-perspective* barycentric coordinate
information (which is only needed when doing noperspective
interpolation).
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
This patch changes how fs_visitor::emit_general_interpolation()
decides what kind of interpolation to do. Previously, it used the
shade model to determine how to interpolate colors, and used smooth
interpolation on everything else. Now it uses
ir_variable::determine_interpolation_mode(), so that it respects GLSL
1.30 interpolation qualifiers.
Fixes piglit tests interpolation-flat-*-smooth-{distance,fixed,vertex}
and interpolation-flat-other-flat-{distance,fixed,vertex}.
Reviewed-by: Eric Anholt <eric@anholt.net>
This patch modifies the fragment shader back-end so that instead of
using a single delta_x/delta_y register pair to store barycentric
coordinates, it uses an array of such register pairs, one for each
possible intepolation mode.
When setting up the WM, we intstruct it to only provide the
barycentric coordinates that are actually needed by the fragment
shader--that is computed by brw_compute_barycentric_interp_modes().
Currently this function returns just
BRW_WM_PERSPECTIVE_PIXEL_BARYCENTRIC, because this is the only
interpolation mode we support. However, that will change in a later
patch.
Reviewed-by: Eric Anholt <eric@anholt.net>
This patch modifies the special case in
fs_visitor::split_virtual_grfs() that prevents splitting from being
applied to the delta_x/delta_y register pair (this register pair needs
to remain contiguous so that it can be used by the PLN instruction).
When gen>=6, this register pair is in a fixed location, not a virtual
register, so it was in no danger of being split. And
split_virtual_grfs' attempt not to split it was preventing some other
unrelated register from being split.
Reviewed-by: Eric Anholt <eric@anholt.net>
This function determines how a variable should be interpolated based
both on interpolation qualifiers and the current shade model.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
Previously, we treated the 'smooth' qualifier as equivalent to no
qualifier at all. However, this is incorrect for the built-in color
variables (gl_FrontColor, gl_BackColor, gl_FrontSecondaryColor, and
gl_BackSecondaryColor). For those variables, if there is no qualifier
at all, interpolation should be flat if the shade model is GL_FLAT,
and smooth if the shade model is GL_SMOOTH.
To make this possible, I added a new value to the
glsl_interp_qualifier enum, INTERP_QUALIFIER_NONE.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
This patch makes GLSL interpolation qualifiers visible to drivers via
the array InterpQualifier[] in gl_fragment_program, so that they can
easily be used by driver back-ends to select the correct interpolation
mode.
Previous to this patch, the GLSL compiler was using the enum
ir_variable_interpolation to represent interpolation types. Rather
than make a duplicate enum in core mesa to represent the same thing, I
moved the enum into mtypes.h and renamed it to be more consistent with
the other enums defined there.
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
