Otherwise, we'll often end up with gl_TexCoord being 0 length, for
example. With ir_to_mesa, things ended up working out anyway, as long
as multiple implicitly-sized arrays weren't involved.
(cherry picked from commit 586b4b500f)
Need to bring back correct fb write with header to set pixel
write mask. Fallback for now.
Note: Conflicts in intel_pixel_bitmap.c due to the removal of
intel_texture_bitmap from master.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Sandybridge's PS constant buffer payload size is decided from
push const buffer command, incorrect size would cause wrong data
in payload for position and vertex attributes. This fixes coefficients
for tex2d/tex3d.
(cherry picked from commit 81aae67e58)
Sandybridge's VF would convert quads to polygon which not required
for GS then. Current GS state still would cause hang on lineloop.
(cherry picked from commit a0b1d7b2b8)
Don't double store position in vertex attribute. This makes color
interpolation right by using barycentric coordinates.
(cherry picked from commit 41c31c2ebd)
Sending down data that doesn't get read doesn't make any sense, and
would make handling things like gl_FrontFacing and gl_PointCoord
harder.
(cherry picked from commit 2f914053bc)
It's trying to get an int smeared across all channels, not trying to
get a 1:1 mapping of a subset of a vector's channels. This usually
ended up not mattering with ir_to_mesa, since it just smears floats
into every chan of a vec4.
Fixes:
glsl1-temp array with swizzled variable indexing
(cherry picked from commit 668cdbe129)
It turns out that most people new to this IR are surprised when an
assignment to (say) 3 components on the LHS takes 4 components on the
RHS. It also makes for quite strange IR output:
(assign (constant bool (1)) (x) (var_ref color) (swiz x (var_ref v) ))
(assign (constant bool (1)) (y) (var_ref color) (swiz yy (var_ref v) ))
(assign (constant bool (1)) (z) (var_ref color) (swiz zzz (var_ref v) ))
But even worse, even we get it wrong, as shown by this line of our
current step(float, vec4):
(assign (constant bool (1)) (w)
(var_ref t)
(expression float b2f (expression bool >=
(swiz w (var_ref x))(var_ref edge))))
where we try to assign a float to the writemasked-out x channel and
don't supply anything for the actual w channel we're writing. Drivers
right now just get lucky since ir_to_mesa spams the float value across
all the source channels of a vec4.
Instead, the RHS will now have a number of components equal to the
number of components actually being written. Hopefully this confuses
everyone less, and it also makes codegen for a scalar target simpler.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
(cherry picked from commit b39e6f33b6)
Taking the W component from coords directly ignores swizzling. Instead,
take the component which is mapped to W in the TEX instruction parameter.
The same for Z.
NOTE: This is a candidate for the 7.9 branch.
(cherry picked from commit 7128e1625b)
Conflicts:
src/mesa/drivers/dri/r300/compiler/radeon_program_tex.c
NOTE: This is a candidate for the 7.9 branch.
(cherry picked from commit 6f747567ec)
Conflicts:
src/mesa/drivers/dri/r300/compiler/radeon_program_tex.c
1. We can't turn an instruction into a presubtract operation if it
writes to one of the registers it reads from.
2. If we turn an instruction into a presubtract operation, we can't
remove that intruction unless all readers can use the presubtract
operation.
This fixes fdo bug 30337.
This is a candidate for the 7.9 branch.
(cherry picked from commit 522e994a22)
