fdo-mirrors/mesa
1
0
Fork 0
mirror of https://gitlab.freedesktop.org/mesa/mesa.git synced 2025-12-22 20:00:10 +01:00
Code Issues Projects Releases Packages Wiki Activity Actions 1
mesa/src/mesa/drivers/dri/i965/brw_vec4_emit.cpp

930 lines
26 KiB
C++
Raw Normal View History

i965/vs: Add support for scratch read/write codegen.
2011-08-07 13:36:11 -07:00
/* Copyright © 2011 Intel Corporation
i965: Start adding the VS visitor and codegen. The low-level IR is a mashup of brw_fs.cpp and ir_to_mesa.cpp. It's currently controlled by the INTEL_NEW_VS=1 environment variable, and only tested for the trivial "gl_Position = gl_Vertex;" shader so far.
2011-05-02 09:45:40 -07:00
*
* Permission is hereby granted, free of charge, to any person obtaining a
* copy of this software and associated documentation files (the "Software"),
* to deal in the Software without restriction, including without limitation
* the rights to use, copy, modify, merge, publish, distribute, sublicense,
* and/or sell copies of the Software, and to permit persons to whom the
* Software is furnished to do so, subject to the following conditions:
*
* The above copyright notice and this permission notice (including the next
* paragraph) shall be included in all copies or substantial portions of the
* Software.
*
* THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
* IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
* FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
* THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
* LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
* FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
* IN THE SOFTWARE.
*/
#include "brw_vec4.h"
extern "C" {
#include "brw_eu.h"
i965/vs: Take attributes into account when deciding urb_entry_size. Both the VF and VS share space in the URB. First, the VF stores attributes (shader inputs) there. The VS then reads the attributes, executes, and reuses the space to store varyings (shader outputs). Thus, we need to calculate the amount of URB space necessary for inputs, outputs, and pick whichever is greater. The old VS backend correctly did this (brw_vs_emit.c:408), but the new VS backend only considered outputs. Fixes vertex scrambling in GLBenchmark PRO on Ivybridge. NOTE: This is a candidate for the 8.0 branch. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=41318 Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Eric Anholt <eric@anholt.net>
2012-01-18 04:53:40 -08:00
#include "main/macros.h"
i965/vs: Replace brw_vs_emit.c with dumping code into the vec4_visitor. Rather than having two separate backends, just create a small layer that translates the subset of Mesa IR used for ARB_vertex_program and fixed function programs to the Vec4 IR. This allows us to use the same optimization passes, code generator, register allocator as for GLSL. v2: Incorporate Eric's review comments. - Fix use of uninitialized src_swiz[] values in the SWIZZLE_ZERO/ONE case: just initialize it to 0 (.x) since the value doesn't matter (those channels get writemasked out anyway). - Properly reswizzle source register's swizzles, rather than overwriting the swizzle. - Port the old brw_vs_emit code for computing .x of the EXP2 opcode. - Update comments, removing mention of NV_vertex_program, etc. - Delete remaining #warning lines and debug comments. Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Eric Anholt <eric@anholt.net>
2012-10-08 10:21:30 -07:00
#include "program/prog_print.h"
#include "program/prog_parameter.h"
i965: Start adding the VS visitor and codegen. The low-level IR is a mashup of brw_fs.cpp and ir_to_mesa.cpp. It's currently controlled by the INTEL_NEW_VS=1 environment variable, and only tested for the trivial "gl_Position = gl_Vertex;" shader so far.
2011-05-02 09:45:40 -07:00
};
namespace brw {
struct brw_reg
vec4_instruction::get_dst(void)
{
struct brw_reg brw_reg;
switch (dst.file) {
case GRF:
brw_reg = brw_vec8_grf(dst.reg + dst.reg_offset, 0);
brw_reg = retype(brw_reg, dst.type);
brw_reg.dw1.bits.writemask = dst.writemask;
break;
i965/vs: Handle destinations in the MRF file. We've been referencing MRFs through the HW_REG file so far, but that makes it harder to handle compute-to-MRF and similar optimizations.
2011-09-06 12:29:15 -07:00
case MRF:
brw_reg = brw_message_reg(dst.reg + dst.reg_offset);
brw_reg = retype(brw_reg, dst.type);
brw_reg.dw1.bits.writemask = dst.writemask;
break;
i965: Start adding the VS visitor and codegen. The low-level IR is a mashup of brw_fs.cpp and ir_to_mesa.cpp. It's currently controlled by the INTEL_NEW_VS=1 environment variable, and only tested for the trivial "gl_Position = gl_Vertex;" shader so far.
2011-05-02 09:45:40 -07:00
case HW_REG:
brw_reg = dst.fixed_hw_reg;
break;
case BAD_FILE:
brw_reg = brw_null_reg();
break;
default:
assert(!"not reached");
brw_reg = brw_null_reg();
break;
}
return brw_reg;
}
struct brw_reg
vec4_instruction::get_src(int i)
{
struct brw_reg brw_reg;
switch (src[i].file) {
case GRF:
brw_reg = brw_vec8_grf(src[i].reg + src[i].reg_offset, 0);
brw_reg = retype(brw_reg, src[i].type);
brw_reg.dw1.bits.swizzle = src[i].swizzle;
if (src[i].abs)
brw_reg = brw_abs(brw_reg);
if (src[i].negate)
brw_reg = negate(brw_reg);
break;
case IMM:
switch (src[i].type) {
case BRW_REGISTER_TYPE_F:
brw_reg = brw_imm_f(src[i].imm.f);
break;
case BRW_REGISTER_TYPE_D:
brw_reg = brw_imm_d(src[i].imm.i);
break;
case BRW_REGISTER_TYPE_UD:
brw_reg = brw_imm_ud(src[i].imm.u);
break;
default:
assert(!"not reached");
brw_reg = brw_null_reg();
break;
}
break;
i965/vs: Start adding support for uniforms There's no clever packing here, no pull constants, and no array support.
2011-05-04 12:50:16 -07:00
case UNIFORM:
brw_reg = stride(brw_vec4_grf(1 + (src[i].reg + src[i].reg_offset) / 2,
((src[i].reg + src[i].reg_offset) % 2) * 4),
0, 4, 1);
brw_reg = retype(brw_reg, src[i].type);
brw_reg.dw1.bits.swizzle = src[i].swizzle;
if (src[i].abs)
brw_reg = brw_abs(brw_reg);
if (src[i].negate)
brw_reg = negate(brw_reg);
i965/vs: Add support for pull constant loads for uniform arrays. v2: reworked the instruction emit and made use of gen6_resolve_implied_move, from Ken's review
2011-08-22 10:35:24 -07:00
/* This should have been moved to pull constants. */
assert(!src[i].reladdr);
i965/vs: Start adding support for uniforms There's no clever packing here, no pull constants, and no array support.
2011-05-04 12:50:16 -07:00
break;
i965: Start adding the VS visitor and codegen. The low-level IR is a mashup of brw_fs.cpp and ir_to_mesa.cpp. It's currently controlled by the INTEL_NEW_VS=1 environment variable, and only tested for the trivial "gl_Position = gl_Vertex;" shader so far.
2011-05-02 09:45:40 -07:00
case HW_REG:
brw_reg = src[i].fixed_hw_reg;
break;
case BAD_FILE:
/* Probably unused. */
brw_reg = brw_null_reg();
break;
case ATTR:
default:
assert(!"not reached");
brw_reg = brw_null_reg();
break;
}
return brw_reg;
}
i965/vs: Split final assembly code generation out of vec4_visitor. Compiling shaders requires several main steps: 1. Generating VS IR from either GLSL IR or Mesa IR 2. Optimizing the IR 3. Register allocation 4. Generating assembly code This patch splits out step 4 into a separate class named "vec4_generator." There are several reasons for doing so: 1. Future hardware has a different instruction encoding. Splitting this out will allow us to replace vec4_generator (which relies heavily on the brw_eu_emit.c code and struct brw_instruction) with a new code generator that writes the new format. 2. It reduces the size of the vec4_visitor monolith. (Arguably, a lot more should be split out, but that's left for "future work.") 3. Separate namespaces allow us to make helper functions for generating instructions in both classes: ADD() can exist in vec4_visitor and create IR, while ADD() in vec4_generator() can create brw_instructions. (Patches for this upcoming.) Reviewed-by: Eric Anholt <eric@anholt.net> Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
2012-11-26 22:53:10 -08:00
vec4_generator::vec4_generator(struct brw_context *brw,
i965/vs: Rename vec4_generator::prog to shader_prog. The next patch is going to change the type of vec4_generator::vp from struct gl_vertex_program * to struct gl_program *, and rename it. The sensible name to change it to is vec4_generator::prog. However, prog is already used. Since the existing vec4_generator::prog is of type struct gl_shader_program, it makes sense to rename it to shader_prog. Reviewed-by: Eric Anholt <eric@anholt.net> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2013-04-09 14:31:28 -07:00
struct gl_shader_program *shader_prog,
i965/vs: Generalize data structures pointed to by vec4_generator. This patch removes the following field from vec4_generator, since it is not used: - struct brw_vs_compile *c And changes the following field: - struct gl_vertex_program *vp => struct gl_program *prog With these changes, vec4_generator no longer refers to any VS-specific data structures. This will pave the way for re-using it for geometry shaders. Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> v2: Use the name "prog" rather than "p". Reviewed-by: Eric Anholt <eric@anholt.net> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2013-02-17 11:25:37 -08:00
struct gl_program *prog,
i965/vs: Split final assembly code generation out of vec4_visitor. Compiling shaders requires several main steps: 1. Generating VS IR from either GLSL IR or Mesa IR 2. Optimizing the IR 3. Register allocation 4. Generating assembly code This patch splits out step 4 into a separate class named "vec4_generator." There are several reasons for doing so: 1. Future hardware has a different instruction encoding. Splitting this out will allow us to replace vec4_generator (which relies heavily on the brw_eu_emit.c code and struct brw_instruction) with a new code generator that writes the new format. 2. It reduces the size of the vec4_visitor monolith. (Arguably, a lot more should be split out, but that's left for "future work.") 3. Separate namespaces allow us to make helper functions for generating instructions in both classes: ADD() can exist in vec4_visitor and create IR, while ADD() in vec4_generator() can create brw_instructions. (Patches for this upcoming.) Reviewed-by: Eric Anholt <eric@anholt.net> Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
2012-11-26 22:53:10 -08:00
void *mem_ctx)
i965/vs: Generalize data structures pointed to by vec4_generator. This patch removes the following field from vec4_generator, since it is not used: - struct brw_vs_compile *c And changes the following field: - struct gl_vertex_program *vp => struct gl_program *prog With these changes, vec4_generator no longer refers to any VS-specific data structures. This will pave the way for re-using it for geometry shaders. Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> v2: Use the name "prog" rather than "p". Reviewed-by: Eric Anholt <eric@anholt.net> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2013-02-17 11:25:37 -08:00
: brw(brw), shader_prog(shader_prog), prog(prog), mem_ctx(mem_ctx)
i965/vs: Split final assembly code generation out of vec4_visitor. Compiling shaders requires several main steps: 1. Generating VS IR from either GLSL IR or Mesa IR 2. Optimizing the IR 3. Register allocation 4. Generating assembly code This patch splits out step 4 into a separate class named "vec4_generator." There are several reasons for doing so: 1. Future hardware has a different instruction encoding. Splitting this out will allow us to replace vec4_generator (which relies heavily on the brw_eu_emit.c code and struct brw_instruction) with a new code generator that writes the new format. 2. It reduces the size of the vec4_visitor monolith. (Arguably, a lot more should be split out, but that's left for "future work.") 3. Separate namespaces allow us to make helper functions for generating instructions in both classes: ADD() can exist in vec4_visitor and create IR, while ADD() in vec4_generator() can create brw_instructions. (Patches for this upcoming.) Reviewed-by: Eric Anholt <eric@anholt.net> Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
2012-11-26 22:53:10 -08:00
{
intel = &brw->intel;
i965/vs: Move struct brw_compile (p) entirely inside vec4_generator. The brw_compile structure contains the brw_instruction store and the brw_eu_emit.c state tracking fields. These are only useful for the final assembly generation pass; the earlier compilation stages doesn't need them. This also means that the code generator for future hardware won't have access to the brw_compile structure, which is extremely desirable because it prevents accidental generation of Gen4-7 code. Reviewed-by: Eric Anholt <eric@anholt.net> Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
2012-11-27 00:16:05 -08:00
i965/vs: Rename vec4_generator::prog to shader_prog. The next patch is going to change the type of vec4_generator::vp from struct gl_vertex_program * to struct gl_program *, and rename it. The sensible name to change it to is vec4_generator::prog. However, prog is already used. Since the existing vec4_generator::prog is of type struct gl_shader_program, it makes sense to rename it to shader_prog. Reviewed-by: Eric Anholt <eric@anholt.net> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2013-04-09 14:31:28 -07:00
shader = shader_prog ? shader_prog->_LinkedShaders[MESA_SHADER_VERTEX] : NULL;
i965/vs: Fix uninitialized shader pointer used in debug output. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2012-11-29 16:49:36 -08:00
i965/vs: Move struct brw_compile (p) entirely inside vec4_generator. The brw_compile structure contains the brw_instruction store and the brw_eu_emit.c state tracking fields. These are only useful for the final assembly generation pass; the earlier compilation stages doesn't need them. This also means that the code generator for future hardware won't have access to the brw_compile structure, which is extremely desirable because it prevents accidental generation of Gen4-7 code. Reviewed-by: Eric Anholt <eric@anholt.net> Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
2012-11-27 00:16:05 -08:00
p = rzalloc(mem_ctx, struct brw_compile);
brw_init_compile(brw, p, mem_ctx);
i965/vs: Split final assembly code generation out of vec4_visitor. Compiling shaders requires several main steps: 1. Generating VS IR from either GLSL IR or Mesa IR 2. Optimizing the IR 3. Register allocation 4. Generating assembly code This patch splits out step 4 into a separate class named "vec4_generator." There are several reasons for doing so: 1. Future hardware has a different instruction encoding. Splitting this out will allow us to replace vec4_generator (which relies heavily on the brw_eu_emit.c code and struct brw_instruction) with a new code generator that writes the new format. 2. It reduces the size of the vec4_visitor monolith. (Arguably, a lot more should be split out, but that's left for "future work.") 3. Separate namespaces allow us to make helper functions for generating instructions in both classes: ADD() can exist in vec4_visitor and create IR, while ADD() in vec4_generator() can create brw_instructions. (Patches for this upcoming.) Reviewed-by: Eric Anholt <eric@anholt.net> Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
2012-11-26 22:53:10 -08:00
}
vec4_generator::~vec4_generator()
{
}
i965: Start adding the VS visitor and codegen. The low-level IR is a mashup of brw_fs.cpp and ir_to_mesa.cpp. It's currently controlled by the INTEL_NEW_VS=1 environment variable, and only tested for the trivial "gl_Position = gl_Vertex;" shader so far.
2011-05-02 09:45:40 -07:00
void
i965/vs: Split final assembly code generation out of vec4_visitor. Compiling shaders requires several main steps: 1. Generating VS IR from either GLSL IR or Mesa IR 2. Optimizing the IR 3. Register allocation 4. Generating assembly code This patch splits out step 4 into a separate class named "vec4_generator." There are several reasons for doing so: 1. Future hardware has a different instruction encoding. Splitting this out will allow us to replace vec4_generator (which relies heavily on the brw_eu_emit.c code and struct brw_instruction) with a new code generator that writes the new format. 2. It reduces the size of the vec4_visitor monolith. (Arguably, a lot more should be split out, but that's left for "future work.") 3. Separate namespaces allow us to make helper functions for generating instructions in both classes: ADD() can exist in vec4_visitor and create IR, while ADD() in vec4_generator() can create brw_instructions. (Patches for this upcoming.) Reviewed-by: Eric Anholt <eric@anholt.net> Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
2012-11-26 22:53:10 -08:00
vec4_generator::generate_math1_gen4(vec4_instruction *inst,
struct brw_reg dst,
struct brw_reg src)
i965: Start adding the VS visitor and codegen. The low-level IR is a mashup of brw_fs.cpp and ir_to_mesa.cpp. It's currently controlled by the INTEL_NEW_VS=1 environment variable, and only tested for the trivial "gl_Position = gl_Vertex;" shader so far.
2011-05-02 09:45:40 -07:00
{
brw_math(p,
dst,
brw_math_function(inst->opcode),
inst->base_mrf,
src,
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>
2011-08-30 15:59:26 -07:00
BRW_MATH_DATA_VECTOR,
i965: Start adding the VS visitor and codegen. The low-level IR is a mashup of brw_fs.cpp and ir_to_mesa.cpp. It's currently controlled by the INTEL_NEW_VS=1 environment variable, and only tested for the trivial "gl_Position = gl_Vertex;" shader so far.
2011-05-02 09:45:40 -07:00
BRW_MATH_PRECISION_FULL);
}
i965/vs: Add support for ir_binop_pow. Fixes vs-pow-float-float.
2011-08-09 12:30:41 -07:00
static void
check_gen6_math_src_arg(struct brw_reg src)
{
/* Source swizzles are ignored. */
assert(!src.abs);
assert(!src.negate);
i965/gen6: Fix assign instead of compare in assert This is from a Coverity defect report. src/mesa/drivers/dri/i965/brw_vec4_emit.cpp 268 static void 269 check_gen6_math_src_arg(struct brw_reg src) 270 { 271 /* Source swizzles are ignored. */ 272 assert(!src.abs); 273 assert(!src.negate); -> 274 assert(src.dw1.bits.swizzle = BRW_SWIZZLE_XYZW); 275 } Reported-by: Vinson Lee <vlee@vmware.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=40214 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
2011-09-30 21:48:18 +01:00
assert(src.dw1.bits.swizzle == BRW_SWIZZLE_XYZW);
i965/vs: Add support for ir_binop_pow. Fixes vs-pow-float-float.
2011-08-09 12:30:41 -07:00
}
i965: Start adding the VS visitor and codegen. The low-level IR is a mashup of brw_fs.cpp and ir_to_mesa.cpp. It's currently controlled by the INTEL_NEW_VS=1 environment variable, and only tested for the trivial "gl_Position = gl_Vertex;" shader so far.
2011-05-02 09:45:40 -07:00
void
i965/vs: Split final assembly code generation out of vec4_visitor. Compiling shaders requires several main steps: 1. Generating VS IR from either GLSL IR or Mesa IR 2. Optimizing the IR 3. Register allocation 4. Generating assembly code This patch splits out step 4 into a separate class named "vec4_generator." There are several reasons for doing so: 1. Future hardware has a different instruction encoding. Splitting this out will allow us to replace vec4_generator (which relies heavily on the brw_eu_emit.c code and struct brw_instruction) with a new code generator that writes the new format. 2. It reduces the size of the vec4_visitor monolith. (Arguably, a lot more should be split out, but that's left for "future work.") 3. Separate namespaces allow us to make helper functions for generating instructions in both classes: ADD() can exist in vec4_visitor and create IR, while ADD() in vec4_generator() can create brw_instructions. (Patches for this upcoming.) Reviewed-by: Eric Anholt <eric@anholt.net> Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
2012-11-26 22:53:10 -08:00
vec4_generator::generate_math1_gen6(vec4_instruction *inst,
struct brw_reg dst,
struct brw_reg src)
i965: Start adding the VS visitor and codegen. The low-level IR is a mashup of brw_fs.cpp and ir_to_mesa.cpp. It's currently controlled by the INTEL_NEW_VS=1 environment variable, and only tested for the trivial "gl_Position = gl_Vertex;" shader so far.
2011-05-02 09:45:40 -07:00
{
i965/vs: Respect the gen6 limitation that math opcodes can't be align16. Fixes vs-acos-vec3 and friends.
2011-08-09 11:00:28 -07:00
/* Can't do writemask because math can't be align16. */
assert(dst.dw1.bits.writemask == WRITEMASK_XYZW);
i965/vs: Add support for ir_binop_pow. Fixes vs-pow-float-float.
2011-08-09 12:30:41 -07:00
check_gen6_math_src_arg(src);
i965/vs: Respect the gen6 limitation that math opcodes can't be align16. Fixes vs-acos-vec3 and friends.
2011-08-09 11:00:28 -07:00
brw_set_access_mode(p, BRW_ALIGN_1);
i965: Start adding the VS visitor and codegen. The low-level IR is a mashup of brw_fs.cpp and ir_to_mesa.cpp. It's currently controlled by the INTEL_NEW_VS=1 environment variable, and only tested for the trivial "gl_Position = gl_Vertex;" shader so far.
2011-05-02 09:45:40 -07:00
brw_math(p,
dst,
brw_math_function(inst->opcode),
inst->base_mrf,
src,
BRW_MATH_DATA_SCALAR,
BRW_MATH_PRECISION_FULL);
i965/vs: Respect the gen6 limitation that math opcodes can't be align16. Fixes vs-acos-vec3 and friends.
2011-08-09 11:00:28 -07:00
brw_set_access_mode(p, BRW_ALIGN_16);
i965: Start adding the VS visitor and codegen. The low-level IR is a mashup of brw_fs.cpp and ir_to_mesa.cpp. It's currently controlled by the INTEL_NEW_VS=1 environment variable, and only tested for the trivial "gl_Position = gl_Vertex;" shader so far.
2011-05-02 09:45:40 -07:00
}
i965: Enable faster workaround-free math on Ivybridge. According to the documentation, Ivybridge's math instruction works in SIMD16 mode for the fragment shader, and no longer forbids align16 mode for the vertex shader. The documentation claims that SIMD16 mode isn't supported for INT DIV, but empirical evidence shows that it works fine. Presumably the note is trying to warn us that the variant that returns both quotient and remainder in (dst, dst + 1) doesn't work in SIMD16 mode since dst + 1 would be sechalf(dst), trashing half your results. Since we don't use that variant, we don't care and can just enable SIMD16 everywhere. The documentation also still claims that source modifiers and conditional modifiers aren't supported, but empirical evidence and study of the simulator both show that they work just fine. Goodbye workarounds. Math just works now. Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Paul Berry <stereotype441@gmail.com>
2011-10-18 12:24:47 -07:00
void
i965/vs: Split final assembly code generation out of vec4_visitor. Compiling shaders requires several main steps: 1. Generating VS IR from either GLSL IR or Mesa IR 2. Optimizing the IR 3. Register allocation 4. Generating assembly code This patch splits out step 4 into a separate class named "vec4_generator." There are several reasons for doing so: 1. Future hardware has a different instruction encoding. Splitting this out will allow us to replace vec4_generator (which relies heavily on the brw_eu_emit.c code and struct brw_instruction) with a new code generator that writes the new format. 2. It reduces the size of the vec4_visitor monolith. (Arguably, a lot more should be split out, but that's left for "future work.") 3. Separate namespaces allow us to make helper functions for generating instructions in both classes: ADD() can exist in vec4_visitor and create IR, while ADD() in vec4_generator() can create brw_instructions. (Patches for this upcoming.) Reviewed-by: Eric Anholt <eric@anholt.net> Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
2012-11-26 22:53:10 -08:00
vec4_generator::generate_math2_gen7(vec4_instruction *inst,
struct brw_reg dst,
struct brw_reg src0,
struct brw_reg src1)
i965: Enable faster workaround-free math on Ivybridge. According to the documentation, Ivybridge's math instruction works in SIMD16 mode for the fragment shader, and no longer forbids align16 mode for the vertex shader. The documentation claims that SIMD16 mode isn't supported for INT DIV, but empirical evidence shows that it works fine. Presumably the note is trying to warn us that the variant that returns both quotient and remainder in (dst, dst + 1) doesn't work in SIMD16 mode since dst + 1 would be sechalf(dst), trashing half your results. Since we don't use that variant, we don't care and can just enable SIMD16 everywhere. The documentation also still claims that source modifiers and conditional modifiers aren't supported, but empirical evidence and study of the simulator both show that they work just fine. Goodbye workarounds. Math just works now. Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Paul Berry <stereotype441@gmail.com>
2011-10-18 12:24:47 -07:00
{
brw_math2(p,
dst,
brw_math_function(inst->opcode),
src0, src1);
}
i965/vs: Add support for ir_binop_pow. Fixes vs-pow-float-float.
2011-08-09 12:30:41 -07:00
void
i965/vs: Split final assembly code generation out of vec4_visitor. Compiling shaders requires several main steps: 1. Generating VS IR from either GLSL IR or Mesa IR 2. Optimizing the IR 3. Register allocation 4. Generating assembly code This patch splits out step 4 into a separate class named "vec4_generator." There are several reasons for doing so: 1. Future hardware has a different instruction encoding. Splitting this out will allow us to replace vec4_generator (which relies heavily on the brw_eu_emit.c code and struct brw_instruction) with a new code generator that writes the new format. 2. It reduces the size of the vec4_visitor monolith. (Arguably, a lot more should be split out, but that's left for "future work.") 3. Separate namespaces allow us to make helper functions for generating instructions in both classes: ADD() can exist in vec4_visitor and create IR, while ADD() in vec4_generator() can create brw_instructions. (Patches for this upcoming.) Reviewed-by: Eric Anholt <eric@anholt.net> Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
2012-11-26 22:53:10 -08:00
vec4_generator::generate_math2_gen6(vec4_instruction *inst,
struct brw_reg dst,
struct brw_reg src0,
struct brw_reg src1)
i965/vs: Add support for ir_binop_pow. Fixes vs-pow-float-float.
2011-08-09 12:30:41 -07:00
{
/* Can't do writemask because math can't be align16. */
assert(dst.dw1.bits.writemask == WRITEMASK_XYZW);
/* Source swizzles are ignored. */
check_gen6_math_src_arg(src0);
check_gen6_math_src_arg(src1);
brw_set_access_mode(p, BRW_ALIGN_1);
brw_math2(p,
dst,
brw_math_function(inst->opcode),
src0, src1);
brw_set_access_mode(p, BRW_ALIGN_16);
}
void
i965/vs: Split final assembly code generation out of vec4_visitor. Compiling shaders requires several main steps: 1. Generating VS IR from either GLSL IR or Mesa IR 2. Optimizing the IR 3. Register allocation 4. Generating assembly code This patch splits out step 4 into a separate class named "vec4_generator." There are several reasons for doing so: 1. Future hardware has a different instruction encoding. Splitting this out will allow us to replace vec4_generator (which relies heavily on the brw_eu_emit.c code and struct brw_instruction) with a new code generator that writes the new format. 2. It reduces the size of the vec4_visitor monolith. (Arguably, a lot more should be split out, but that's left for "future work.") 3. Separate namespaces allow us to make helper functions for generating instructions in both classes: ADD() can exist in vec4_visitor and create IR, while ADD() in vec4_generator() can create brw_instructions. (Patches for this upcoming.) Reviewed-by: Eric Anholt <eric@anholt.net> Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
2012-11-26 22:53:10 -08:00
vec4_generator::generate_math2_gen4(vec4_instruction *inst,
struct brw_reg dst,
struct brw_reg src0,
struct brw_reg src1)
i965/vs: Add support for ir_binop_pow. Fixes vs-pow-float-float.
2011-08-09 12:30:41 -07:00
{
i965: Reverse the operands for INT DIV prior to Gen6. Apparently on Gen4 and 5, the denominator comes first. Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Tested-by: Ian Romanick <ian.d.romanick@intel.com> Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Reviewed-by: Eric Anholt <eric@anholt.net>
2011-09-28 17:37:56 -07:00
/* From the Ironlake PRM, Volume 4, Part 1, Section 6.1.13
* "Message Payload":
*
* "Operand0[7]. For the INT DIV functions, this operand is the
* denominator."
* ...
* "Operand1[7]. For the INT DIV functions, this operand is the
* numerator."
*/
bool is_int_div = inst->opcode != SHADER_OPCODE_POW;
struct brw_reg &op0 = is_int_div ? src1 : src0;
struct brw_reg &op1 = is_int_div ? src0 : src1;
i965/vs: Protect pow(x,y) MOV of y on gen4 from other instruction flags. I don't know if it was possible to trigger this bug -- we don't merge saturates into the math instruction because we're bad at coalescing currently, and there's nothing generating these with predicates. Still, let's avoid future bugs when we do smarter codegen. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2012-08-06 15:02:34 -07:00
brw_push_insn_state(p);
brw_set_saturate(p, false);
brw_set_predicate_control(p, BRW_PREDICATE_NONE);
i965: Reverse the operands for INT DIV prior to Gen6. Apparently on Gen4 and 5, the denominator comes first. Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Tested-by: Ian Romanick <ian.d.romanick@intel.com> Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Reviewed-by: Eric Anholt <eric@anholt.net>
2011-09-28 17:37:56 -07:00
brw_MOV(p, retype(brw_message_reg(inst->base_mrf + 1), op1.type), op1);
i965/vs: Protect pow(x,y) MOV of y on gen4 from other instruction flags. I don't know if it was possible to trigger this bug -- we don't merge saturates into the math instruction because we're bad at coalescing currently, and there's nothing generating these with predicates. Still, let's avoid future bugs when we do smarter codegen. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2012-08-06 15:02:34 -07:00
brw_pop_insn_state(p);
i965/vs: Add support for ir_binop_pow. Fixes vs-pow-float-float.
2011-08-09 12:30:41 -07:00
brw_math(p,
dst,
brw_math_function(inst->opcode),
inst->base_mrf,
i965: Reverse the operands for INT DIV prior to Gen6. Apparently on Gen4 and 5, the denominator comes first. Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Tested-by: Ian Romanick <ian.d.romanick@intel.com> Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Reviewed-by: Eric Anholt <eric@anholt.net>
2011-09-28 17:37:56 -07:00
op0,
i965/vs: Add support for ir_binop_pow. Fixes vs-pow-float-float.
2011-08-09 12:30:41 -07:00
BRW_MATH_DATA_VECTOR,
BRW_MATH_PRECISION_FULL);
}
i965/vs: Implement vec4_visitor::generate_tex(). This is the part that takes the vec4_instruction IR and turns it into actual Gen ISA. v2: Add Gen4 messages, don't retype m0 to UW. Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
2011-10-26 13:53:11 -07:00
void
i965/vs: Split final assembly code generation out of vec4_visitor. Compiling shaders requires several main steps: 1. Generating VS IR from either GLSL IR or Mesa IR 2. Optimizing the IR 3. Register allocation 4. Generating assembly code This patch splits out step 4 into a separate class named "vec4_generator." There are several reasons for doing so: 1. Future hardware has a different instruction encoding. Splitting this out will allow us to replace vec4_generator (which relies heavily on the brw_eu_emit.c code and struct brw_instruction) with a new code generator that writes the new format. 2. It reduces the size of the vec4_visitor monolith. (Arguably, a lot more should be split out, but that's left for "future work.") 3. Separate namespaces allow us to make helper functions for generating instructions in both classes: ADD() can exist in vec4_visitor and create IR, while ADD() in vec4_generator() can create brw_instructions. (Patches for this upcoming.) Reviewed-by: Eric Anholt <eric@anholt.net> Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
2012-11-26 22:53:10 -08:00
vec4_generator::generate_tex(vec4_instruction *inst,
struct brw_reg dst,
struct brw_reg src)
i965/vs: Implement vec4_visitor::generate_tex(). This is the part that takes the vec4_instruction IR and turns it into actual Gen ISA. v2: Add Gen4 messages, don't retype m0 to UW. Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
2011-10-26 13:53:11 -07:00
{
int msg_type = -1;
if (intel->gen >= 5) {
switch (inst->opcode) {
case SHADER_OPCODE_TEX:
case SHADER_OPCODE_TXL:
if (inst->shadow_compare) {
msg_type = GEN5_SAMPLER_MESSAGE_SAMPLE_LOD_COMPARE;
} else {
msg_type = GEN5_SAMPLER_MESSAGE_SAMPLE_LOD;
}
break;
case SHADER_OPCODE_TXD:
i965: Use Haswell's sample_d_c for textureGrad with shadow samplers. The new hardware actually just supports this now. Reviewed-by: Eric Anholt <eric@anholt.net>
2013-01-04 07:53:09 -08:00
if (inst->shadow_compare) {
/* Gen7.5+. Otherwise, lowered by brw_lower_texture_gradients(). */
assert(intel->is_haswell);
msg_type = HSW_SAMPLER_MESSAGE_SAMPLE_DERIV_COMPARE;
} else {
msg_type = GEN5_SAMPLER_MESSAGE_SAMPLE_DERIVS;
}
i965/vs: Implement vec4_visitor::generate_tex(). This is the part that takes the vec4_instruction IR and turns it into actual Gen ISA. v2: Add Gen4 messages, don't retype m0 to UW. Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
2011-10-26 13:53:11 -07:00
break;
case SHADER_OPCODE_TXF:
msg_type = GEN5_SAMPLER_MESSAGE_SAMPLE_LD;
break;
i965: add a new virtual opcode: SHADER_OPCODE_TXF_MS This is very similar to the TXF opcode, but lowers to `ld2dms` rather than `ld` on Gen7. V4: - add SHADER_OPCODE_TXF_MS to is_tex() functions, so regalloc thinks it actually writes the correct number of registers. Otherwise in nontrivial shaders some of the registers tend to get clobbered, producing bad results. Signed-off-by: Chris Forbes <chrisf@ijw.co.nz> Reviewed-by: Paul Berry <stereotype441@gmail.com>
2013-01-24 21:35:15 +13:00
case SHADER_OPCODE_TXF_MS:
if (intel->gen >= 7)
msg_type = GEN7_SAMPLER_MESSAGE_SAMPLE_LD2DMS;
else
msg_type = GEN5_SAMPLER_MESSAGE_SAMPLE_LD;
break;
i965/vs: Implement vec4_visitor::generate_tex(). This is the part that takes the vec4_instruction IR and turns it into actual Gen ISA. v2: Add Gen4 messages, don't retype m0 to UW. Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
2011-10-26 13:53:11 -07:00
case SHADER_OPCODE_TXS:
msg_type = GEN5_SAMPLER_MESSAGE_SAMPLE_RESINFO;
break;
default:
assert(!"should not get here: invalid VS texture opcode");
break;
}
} else {
switch (inst->opcode) {
case SHADER_OPCODE_TEX:
case SHADER_OPCODE_TXL:
if (inst->shadow_compare) {
msg_type = BRW_SAMPLER_MESSAGE_SIMD4X2_SAMPLE_LOD_COMPARE;
assert(inst->mlen == 3);
} else {
msg_type = BRW_SAMPLER_MESSAGE_SIMD4X2_SAMPLE_LOD;
assert(inst->mlen == 2);
}
break;
case SHADER_OPCODE_TXD:
/* There is no sample_d_c message; comparisons are done manually. */
msg_type = BRW_SAMPLER_MESSAGE_SIMD4X2_SAMPLE_GRADIENTS;
assert(inst->mlen == 4);
break;
case SHADER_OPCODE_TXF:
msg_type = BRW_SAMPLER_MESSAGE_SIMD4X2_LD;
assert(inst->mlen == 2);
break;
case SHADER_OPCODE_TXS:
msg_type = BRW_SAMPLER_MESSAGE_SIMD4X2_RESINFO;
assert(inst->mlen == 2);
break;
default:
assert(!"should not get here: invalid VS texture opcode");
break;
}
}
assert(msg_type != -1);
i965/vs: Add support for texel offsets. The visit() half computes the values to put in the header based on the IR and simply stuffs that in the vec4_instruction; the emit() half uses this to set up the message header. This works out well since emit() can use brw_reg directly and access individual DWords without kludgery. Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Eric Anholt <eric@anholt.net> Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
2011-11-12 02:21:44 -08:00
/* Load the message header if present. If there's a texture offset, we need
* to set it up explicitly and load the offset bitfield. Otherwise, we can
* use an implied move from g0 to the first message register.
*/
if (inst->texture_offset) {
/* Explicitly set up the message header by copying g0 to the MRF. */
i965: Disable write masking when setting up texturing m0. v2/Kayden: Also disable write masking in the vec4 backend. Fixes 78 oglconform glsl-bif-tex-* subcases. Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Paul Berry <stereotype441@gmail.com> [v1] Reviewed-by: Eric Anholt <eric@anholt.net> [v2]
2012-08-30 11:07:52 -07:00
brw_push_insn_state(p);
brw_set_mask_control(p, BRW_MASK_DISABLE);
i965/vs: Add support for texel offsets. The visit() half computes the values to put in the header based on the IR and simply stuffs that in the vec4_instruction; the emit() half uses this to set up the message header. This works out well since emit() can use brw_reg directly and access individual DWords without kludgery. Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Eric Anholt <eric@anholt.net> Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
2011-11-12 02:21:44 -08:00
brw_MOV(p, retype(brw_message_reg(inst->base_mrf), BRW_REGISTER_TYPE_UD),
retype(brw_vec8_grf(0, 0), BRW_REGISTER_TYPE_UD));
/* Then set the offset bits in DWord 2. */
brw_set_access_mode(p, BRW_ALIGN_1);
brw_MOV(p,
retype(brw_vec1_reg(BRW_MESSAGE_REGISTER_FILE, inst->base_mrf, 2),
BRW_REGISTER_TYPE_UD),
brw_imm_uw(inst->texture_offset));
i965: Disable write masking when setting up texturing m0. v2/Kayden: Also disable write masking in the vec4 backend. Fixes 78 oglconform glsl-bif-tex-* subcases. Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Paul Berry <stereotype441@gmail.com> [v1] Reviewed-by: Eric Anholt <eric@anholt.net> [v2]
2012-08-30 11:07:52 -07:00
brw_pop_insn_state(p);
i965/vs: Add support for texel offsets. The visit() half computes the values to put in the header based on the IR and simply stuffs that in the vec4_instruction; the emit() half uses this to set up the message header. This works out well since emit() can use brw_reg directly and access individual DWords without kludgery. Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Eric Anholt <eric@anholt.net> Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
2011-11-12 02:21:44 -08:00
} else if (inst->header_present) {
i965/vs: Implement vec4_visitor::generate_tex(). This is the part that takes the vec4_instruction IR and turns it into actual Gen ISA. v2: Add Gen4 messages, don't retype m0 to UW. Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
2011-10-26 13:53:11 -07:00
/* Set up an implied move from g0 to the MRF. */
src = brw_vec8_grf(0, 0);
}
uint32_t return_format;
switch (dst.type) {
case BRW_REGISTER_TYPE_D:
return_format = BRW_SAMPLER_RETURN_FORMAT_SINT32;
break;
case BRW_REGISTER_TYPE_UD:
return_format = BRW_SAMPLER_RETURN_FORMAT_UINT32;
break;
default:
return_format = BRW_SAMPLER_RETURN_FORMAT_FLOAT32;
break;
}
brw_SAMPLE(p,
dst,
inst->base_mrf,
src,
i965: Split the VS binding table to a separate table. This is a step toward making the samplers/binding tables reflect sampler uniform mappings instead of embedding those in the programs. No significant performance difference on the microbenchmark (n=10). Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2012-02-15 13:33:07 -08:00
SURF_INDEX_VS_TEXTURE(inst->sampler),
i965/vs: Implement vec4_visitor::generate_tex(). This is the part that takes the vec4_instruction IR and turns it into actual Gen ISA. v2: Add Gen4 messages, don't retype m0 to UW. Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
2011-10-26 13:53:11 -07:00
inst->sampler,
msg_type,
1, /* response length */
inst->mlen,
inst->header_present,
BRW_SAMPLER_SIMD_MODE_SIMD4X2,
return_format);
}
i965: Start adding the VS visitor and codegen. The low-level IR is a mashup of brw_fs.cpp and ir_to_mesa.cpp. It's currently controlled by the INTEL_NEW_VS=1 environment variable, and only tested for the trivial "gl_Position = gl_Vertex;" shader so far.
2011-05-02 09:45:40 -07:00
void
i965/vs: Split final assembly code generation out of vec4_visitor. Compiling shaders requires several main steps: 1. Generating VS IR from either GLSL IR or Mesa IR 2. Optimizing the IR 3. Register allocation 4. Generating assembly code This patch splits out step 4 into a separate class named "vec4_generator." There are several reasons for doing so: 1. Future hardware has a different instruction encoding. Splitting this out will allow us to replace vec4_generator (which relies heavily on the brw_eu_emit.c code and struct brw_instruction) with a new code generator that writes the new format. 2. It reduces the size of the vec4_visitor monolith. (Arguably, a lot more should be split out, but that's left for "future work.") 3. Separate namespaces allow us to make helper functions for generating instructions in both classes: ADD() can exist in vec4_visitor and create IR, while ADD() in vec4_generator() can create brw_instructions. (Patches for this upcoming.) Reviewed-by: Eric Anholt <eric@anholt.net> Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
2012-11-26 22:53:10 -08:00
vec4_generator::generate_urb_write(vec4_instruction *inst)
i965: Start adding the VS visitor and codegen. The low-level IR is a mashup of brw_fs.cpp and ir_to_mesa.cpp. It's currently controlled by the INTEL_NEW_VS=1 environment variable, and only tested for the trivial "gl_Position = gl_Vertex;" shader so far.
2011-05-02 09:45:40 -07:00
{
brw_urb_WRITE(p,
brw_null_reg(), /* dest */
inst->base_mrf, /* starting mrf reg nr */
brw_vec8_grf(0, 0), /* src */
false, /* allocate */
true, /* used */
inst->mlen,
0, /* response len */
inst->eot, /* eot */
inst->eot, /* writes complete */
inst->offset, /* urb destination offset */
BRW_URB_SWIZZLE_INTERLEAVE);
}
i965/vs: Add support for scratch read/write codegen.
2011-08-07 13:36:11 -07:00
void
i965/vs: Split final assembly code generation out of vec4_visitor. Compiling shaders requires several main steps: 1. Generating VS IR from either GLSL IR or Mesa IR 2. Optimizing the IR 3. Register allocation 4. Generating assembly code This patch splits out step 4 into a separate class named "vec4_generator." There are several reasons for doing so: 1. Future hardware has a different instruction encoding. Splitting this out will allow us to replace vec4_generator (which relies heavily on the brw_eu_emit.c code and struct brw_instruction) with a new code generator that writes the new format. 2. It reduces the size of the vec4_visitor monolith. (Arguably, a lot more should be split out, but that's left for "future work.") 3. Separate namespaces allow us to make helper functions for generating instructions in both classes: ADD() can exist in vec4_visitor and create IR, while ADD() in vec4_generator() can create brw_instructions. (Patches for this upcoming.) Reviewed-by: Eric Anholt <eric@anholt.net> Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
2012-11-26 22:53:10 -08:00
vec4_generator::generate_oword_dual_block_offsets(struct brw_reg m1,
struct brw_reg index)
i965/vs: Add support for scratch read/write codegen.
2011-08-07 13:36:11 -07:00
{
int second_vertex_offset;
if (intel->gen >= 6)
second_vertex_offset = 1;
else
second_vertex_offset = 16;
m1 = retype(m1, BRW_REGISTER_TYPE_D);
/* Set up M1 (message payload). Only the block offsets in M1.0 and
* M1.4 are used, and the rest are ignored.
*/
struct brw_reg m1_0 = suboffset(vec1(m1), 0);
struct brw_reg m1_4 = suboffset(vec1(m1), 4);
struct brw_reg index_0 = suboffset(vec1(index), 0);
struct brw_reg index_4 = suboffset(vec1(index), 4);
brw_push_insn_state(p);
brw_set_mask_control(p, BRW_MASK_DISABLE);
brw_set_access_mode(p, BRW_ALIGN_1);
brw_MOV(p, m1_0, index_0);
if (index.file == BRW_IMMEDIATE_VALUE) {
i965/vs: Fix constant-indexed array read/write addresses on pre-gen6. The second vertex was getting a garbage index. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2011-08-30 16:40:06 -07:00
index_4.dw1.ud += second_vertex_offset;
i965/vs: Add support for scratch read/write codegen.
2011-08-07 13:36:11 -07:00
brw_MOV(p, m1_4, index_4);
} else {
brw_ADD(p, m1_4, index_4, brw_imm_d(second_vertex_offset));
}
brw_pop_insn_state(p);
}
void
i965/vs: Split final assembly code generation out of vec4_visitor. Compiling shaders requires several main steps: 1. Generating VS IR from either GLSL IR or Mesa IR 2. Optimizing the IR 3. Register allocation 4. Generating assembly code This patch splits out step 4 into a separate class named "vec4_generator." There are several reasons for doing so: 1. Future hardware has a different instruction encoding. Splitting this out will allow us to replace vec4_generator (which relies heavily on the brw_eu_emit.c code and struct brw_instruction) with a new code generator that writes the new format. 2. It reduces the size of the vec4_visitor monolith. (Arguably, a lot more should be split out, but that's left for "future work.") 3. Separate namespaces allow us to make helper functions for generating instructions in both classes: ADD() can exist in vec4_visitor and create IR, while ADD() in vec4_generator() can create brw_instructions. (Patches for this upcoming.) Reviewed-by: Eric Anholt <eric@anholt.net> Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
2012-11-26 22:53:10 -08:00
vec4_generator::generate_scratch_read(vec4_instruction *inst,
struct brw_reg dst,
struct brw_reg index)
i965/vs: Add support for scratch read/write codegen.
2011-08-07 13:36:11 -07:00
{
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>
2011-08-30 16:47:43 -07:00
struct brw_reg header = brw_vec8_grf(0, 0);
gen6_resolve_implied_move(p, &header, inst->base_mrf);
i965/vs: Add support for scratch read/write codegen.
2011-08-07 13:36:11 -07:00
generate_oword_dual_block_offsets(brw_message_reg(inst->base_mrf + 1),
index);
uint32_t msg_type;
if (intel->gen >= 6)
msg_type = GEN6_DATAPORT_READ_MESSAGE_OWORD_DUAL_BLOCK_READ;
else if (intel->gen == 5 || intel->is_g4x)
msg_type = G45_DATAPORT_READ_MESSAGE_OWORD_DUAL_BLOCK_READ;
else
msg_type = BRW_DATAPORT_READ_MESSAGE_OWORD_DUAL_BLOCK_READ;
/* Each of the 8 channel enables is considered for whether each
* dword is written.
*/
struct brw_instruction *send = brw_next_insn(p, BRW_OPCODE_SEND);
brw_set_dest(p, send, dst);
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>
2011-08-30 16:47:43 -07:00
brw_set_src0(p, send, header);
if (intel->gen < 6)
send->header.destreg__conditionalmod = inst->base_mrf;
i965/vs: Add support for scratch read/write codegen.
2011-08-07 13:36:11 -07:00
brw_set_dp_read_message(p, send,
255, /* binding table index: stateless access */
BRW_DATAPORT_OWORD_DUAL_BLOCK_1OWORD,
msg_type,
BRW_DATAPORT_READ_TARGET_RENDER_CACHE,
2, /* mlen */
i965: Add a header_present flag for setting up dp read messages. As of gen7, we can skip the header on some messages, and this can make optimization on those messages much nicer when you've got GRFs instead of MRFs as the source.
2012-11-09 11:17:48 -08:00
true, /* header_present */
i965/vs: Add support for scratch read/write codegen.
2011-08-07 13:36:11 -07:00
1 /* rlen */);
}
void
i965/vs: Split final assembly code generation out of vec4_visitor. Compiling shaders requires several main steps: 1. Generating VS IR from either GLSL IR or Mesa IR 2. Optimizing the IR 3. Register allocation 4. Generating assembly code This patch splits out step 4 into a separate class named "vec4_generator." There are several reasons for doing so: 1. Future hardware has a different instruction encoding. Splitting this out will allow us to replace vec4_generator (which relies heavily on the brw_eu_emit.c code and struct brw_instruction) with a new code generator that writes the new format. 2. It reduces the size of the vec4_visitor monolith. (Arguably, a lot more should be split out, but that's left for "future work.") 3. Separate namespaces allow us to make helper functions for generating instructions in both classes: ADD() can exist in vec4_visitor and create IR, while ADD() in vec4_generator() can create brw_instructions. (Patches for this upcoming.) Reviewed-by: Eric Anholt <eric@anholt.net> Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
2012-11-26 22:53:10 -08:00
vec4_generator::generate_scratch_write(vec4_instruction *inst,
struct brw_reg dst,
struct brw_reg src,
struct brw_reg index)
i965/vs: Add support for scratch read/write codegen.
2011-08-07 13:36:11 -07:00
{
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>
2011-08-30 16:47:43 -07:00
struct brw_reg header = brw_vec8_grf(0, 0);
i965/vs: Use write commits on scratch writes in pre-gen6. This is required to ensure ordering between reads and writes within a thread. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2011-08-30 17:56:33 -07:00
bool write_commit;
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>
2011-08-30 16:47:43 -07:00
i965/vs: Add support for scratch read/write codegen.
2011-08-07 13:36:11 -07:00
/* If the instruction is predicated, we'll predicate the send, not
* the header setup.
*/
brw_set_predicate_control(p, false);
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>
2011-08-30 16:47:43 -07:00
gen6_resolve_implied_move(p, &header, inst->base_mrf);
i965/vs: Add support for scratch read/write codegen.
2011-08-07 13:36:11 -07:00
generate_oword_dual_block_offsets(brw_message_reg(inst->base_mrf + 1),
index);
brw_MOV(p,
retype(brw_message_reg(inst->base_mrf + 2), BRW_REGISTER_TYPE_D),
retype(src, BRW_REGISTER_TYPE_D));
uint32_t msg_type;
i965: Use Ivybridge's "Legacy Data Port" for reads/writes. Using the constant cache for reads isn't going to work for scratch reads (variably-indexed arrays or register spills), as these aren't constant at all. Also, in the new VS backend, use the proper message number for OWord Dual Block Write messages. It's now 10, instead of 9. +205 piglits. NOTE: This is a candidate for the 7.11 branch. Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Eric Anholt <eric@anholt.net>
2011-10-07 21:09:53 -07:00
if (intel->gen >= 7)
msg_type = GEN7_DATAPORT_WRITE_MESSAGE_OWORD_DUAL_BLOCK_WRITE;
else if (intel->gen == 6)
i965/vs: Add support for scratch read/write codegen.
2011-08-07 13:36:11 -07:00
msg_type = GEN6_DATAPORT_WRITE_MESSAGE_OWORD_DUAL_BLOCK_WRITE;
else
msg_type = BRW_DATAPORT_WRITE_MESSAGE_OWORD_DUAL_BLOCK_WRITE;
brw_set_predicate_control(p, inst->predicate);
i965/vs: Use write commits on scratch writes in pre-gen6. This is required to ensure ordering between reads and writes within a thread. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2011-08-30 17:56:33 -07:00
/* Pre-gen6, we have to specify write commits to ensure ordering
* between reads and writes within a thread. Afterwards, that's
* guaranteed and write commits only matter for inter-thread
* synchronization.
*/
if (intel->gen >= 6) {
write_commit = false;
} else {
/* The visitor set up our destination register to be g0. This
* means that when the next read comes along, we will end up
* reading from g0 and causing a block on the write commit. For
* write-after-read, we are relying on the value of the previous
* read being used (and thus blocking on completion) before our
* write is executed. This means we have to be careful in
* instruction scheduling to not violate this assumption.
*/
write_commit = true;
}
i965/vs: Add support for scratch read/write codegen.
2011-08-07 13:36:11 -07:00
/* Each of the 8 channel enables is considered for whether each
* dword is written.
*/
struct brw_instruction *send = brw_next_insn(p, BRW_OPCODE_SEND);
brw_set_dest(p, send, dst);
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>
2011-08-30 16:47:43 -07:00
brw_set_src0(p, send, header);
if (intel->gen < 6)
send->header.destreg__conditionalmod = inst->base_mrf;
i965/vs: Add support for scratch read/write codegen.
2011-08-07 13:36:11 -07:00
brw_set_dp_write_message(p, send,
255, /* binding table index: stateless access */
BRW_DATAPORT_OWORD_DUAL_BLOCK_1OWORD,
msg_type,
3, /* mlen */
true, /* header present */
i965: Rename pixel_scoreboard_clear to last_render_target for clarity. Finding this bit in the documentation proved challenging. It wasn't in the SEND instruction's message descriptor section, nor the data port message descriptor section. It turns out to be part of the Render Target Write message's control bits, and in the documentation is named "Last Render Target Select". Shaders that use Multiple Render Targets should set this bit on the last RT write, but not on any prior ones. The GPU does update the Pixel Scoreboard appropriately, but doesn't document this bit as directly causing a scoreboard clear. Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Eric Anholt <eric@anholt.net>
2011-10-07 22:26:40 -07:00
false, /* not a render target write */
i965/vs: Use write commits on scratch writes in pre-gen6. This is required to ensure ordering between reads and writes within a thread. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2011-08-30 17:56:33 -07:00
write_commit, /* rlen */
i965/vs: Add support for scratch read/write codegen.
2011-08-07 13:36:11 -07:00
false, /* eot */
i965/vs: Use write commits on scratch writes in pre-gen6. This is required to ensure ordering between reads and writes within a thread. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2011-08-30 17:56:33 -07:00
write_commit);
i965/vs: Add support for scratch read/write codegen.
2011-08-07 13:36:11 -07:00
}
i965/vs: Add support for pull constant loads for uniform arrays. v2: reworked the instruction emit and made use of gen6_resolve_implied_move, from Ken's review
2011-08-22 10:35:24 -07:00
void
i965/vs: Split final assembly code generation out of vec4_visitor. Compiling shaders requires several main steps: 1. Generating VS IR from either GLSL IR or Mesa IR 2. Optimizing the IR 3. Register allocation 4. Generating assembly code This patch splits out step 4 into a separate class named "vec4_generator." There are several reasons for doing so: 1. Future hardware has a different instruction encoding. Splitting this out will allow us to replace vec4_generator (which relies heavily on the brw_eu_emit.c code and struct brw_instruction) with a new code generator that writes the new format. 2. It reduces the size of the vec4_visitor monolith. (Arguably, a lot more should be split out, but that's left for "future work.") 3. Separate namespaces allow us to make helper functions for generating instructions in both classes: ADD() can exist in vec4_visitor and create IR, while ADD() in vec4_generator() can create brw_instructions. (Patches for this upcoming.) Reviewed-by: Eric Anholt <eric@anholt.net> Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
2012-11-26 22:53:10 -08:00
vec4_generator::generate_pull_constant_load(vec4_instruction *inst,
struct brw_reg dst,
struct brw_reg index,
struct brw_reg offset)
i965/vs: Add support for pull constant loads for uniform arrays. v2: reworked the instruction emit and made use of gen6_resolve_implied_move, from Ken's review
2011-08-22 10:35:24 -07:00
{
i965/vs: Use GRFs for pull constant offsets on gen7. This allows the computation of the offset to get written directly into the message source. shader-db results: total instructions in shared programs: 3308390 -> 3283025 (-0.77%) instructions in affected programs: 442998 -> 417633 (-5.73%) No difference in GLB2.7 low res (n=9). Reviewed-by: Matt Turner <mattst88@gmail.com>
2013-04-04 14:10:18 -07:00
assert(intel->gen <= 7);
i965/vs: Add a surface index to VS_OPCODE_PULL_CONSTANT instructions. Similar to the previous commit for the fragment shader, now we have a buffer index and an offset. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2012-06-25 14:36:28 -07:00
assert(index.file == BRW_IMMEDIATE_VALUE &&
index.type == BRW_REGISTER_TYPE_UD);
uint32_t surf_index = index.dw1.ud;
i965/vs: Add support for pull constant loads for uniform arrays. v2: reworked the instruction emit and made use of gen6_resolve_implied_move, from Ken's review
2011-08-22 10:35:24 -07:00
struct brw_reg header = brw_vec8_grf(0, 0);
gen6_resolve_implied_move(p, &header, inst->base_mrf);
brw_MOV(p, retype(brw_message_reg(inst->base_mrf + 1), BRW_REGISTER_TYPE_D),
i965/vs: Add a surface index to VS_OPCODE_PULL_CONSTANT instructions. Similar to the previous commit for the fragment shader, now we have a buffer index and an offset. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2012-06-25 14:36:28 -07:00
offset);
i965/vs: Add support for pull constant loads for uniform arrays. v2: reworked the instruction emit and made use of gen6_resolve_implied_move, from Ken's review
2011-08-22 10:35:24 -07:00
uint32_t msg_type;
if (intel->gen >= 6)
msg_type = GEN6_DATAPORT_READ_MESSAGE_OWORD_DUAL_BLOCK_READ;
else if (intel->gen == 5 || intel->is_g4x)
msg_type = G45_DATAPORT_READ_MESSAGE_OWORD_DUAL_BLOCK_READ;
else
msg_type = BRW_DATAPORT_READ_MESSAGE_OWORD_DUAL_BLOCK_READ;
/* Each of the 8 channel enables is considered for whether each
* dword is written.
*/
struct brw_instruction *send = brw_next_insn(p, BRW_OPCODE_SEND);
brw_set_dest(p, send, dst);
brw_set_src0(p, send, header);
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>
2011-08-30 16:47:43 -07:00
if (intel->gen < 6)
send->header.destreg__conditionalmod = inst->base_mrf;
i965/vs: Add support for pull constant loads for uniform arrays. v2: reworked the instruction emit and made use of gen6_resolve_implied_move, from Ken's review
2011-08-22 10:35:24 -07:00
brw_set_dp_read_message(p, send,
i965/vs: Add a surface index to VS_OPCODE_PULL_CONSTANT instructions. Similar to the previous commit for the fragment shader, now we have a buffer index and an offset. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2012-06-25 14:36:28 -07:00
surf_index,
i965/vs: Add support for pull constant loads for uniform arrays. v2: reworked the instruction emit and made use of gen6_resolve_implied_move, from Ken's review
2011-08-22 10:35:24 -07:00
BRW_DATAPORT_OWORD_DUAL_BLOCK_1OWORD,
msg_type,
BRW_DATAPORT_READ_TARGET_DATA_CACHE,
2, /* mlen */
i965: Add a header_present flag for setting up dp read messages. As of gen7, we can skip the header on some messages, and this can make optimization on those messages much nicer when you've got GRFs instead of MRFs as the source.
2012-11-09 11:17:48 -08:00
true, /* header_present */
i965/vs: Add support for pull constant loads for uniform arrays. v2: reworked the instruction emit and made use of gen6_resolve_implied_move, from Ken's review
2011-08-22 10:35:24 -07:00
1 /* rlen */);
}
i965/vs: Use GRFs for pull constant offsets on gen7. This allows the computation of the offset to get written directly into the message source. shader-db results: total instructions in shared programs: 3308390 -> 3283025 (-0.77%) instructions in affected programs: 442998 -> 417633 (-5.73%) No difference in GLB2.7 low res (n=9). Reviewed-by: Matt Turner <mattst88@gmail.com>
2013-04-04 14:10:18 -07:00
void
vec4_generator::generate_pull_constant_load_gen7(vec4_instruction *inst,
struct brw_reg dst,
struct brw_reg surf_index,
struct brw_reg offset)
{
assert(surf_index.file == BRW_IMMEDIATE_VALUE &&
surf_index.type == BRW_REGISTER_TYPE_UD);
brw_instruction *insn = brw_next_insn(p, BRW_OPCODE_SEND);
brw_set_dest(p, insn, dst);
brw_set_src0(p, insn, offset);
brw_set_sampler_message(p, insn,
surf_index.dw1.ud,
0, /* LD message ignores sampler unit */
GEN5_SAMPLER_MESSAGE_SAMPLE_LD,
1, /* rlen */
1, /* mlen */
false, /* no header */
BRW_SAMPLER_SIMD_MODE_SIMD4X2,
0);
}
i965: Start adding the VS visitor and codegen. The low-level IR is a mashup of brw_fs.cpp and ir_to_mesa.cpp. It's currently controlled by the INTEL_NEW_VS=1 environment variable, and only tested for the trivial "gl_Position = gl_Vertex;" shader so far.
2011-05-02 09:45:40 -07:00
void
i965/vs: rename vec4_generator::generate_vs_instruction. Since this function is going to get used for geometry shaders too, it deserves a more generic name: generate_vec4_instruction. Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Eric Anholt <eric@anholt.net> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2013-02-17 11:34:05 -08:00
vec4_generator::generate_vec4_instruction(vec4_instruction *instruction,
struct brw_reg dst,
struct brw_reg *src)
i965: Start adding the VS visitor and codegen. The low-level IR is a mashup of brw_fs.cpp and ir_to_mesa.cpp. It's currently controlled by the INTEL_NEW_VS=1 environment variable, and only tested for the trivial "gl_Position = gl_Vertex;" shader so far.
2011-05-02 09:45:40 -07:00
{
vec4_instruction *inst = (vec4_instruction *)instruction;
switch (inst->opcode) {
case SHADER_OPCODE_RCP:
case SHADER_OPCODE_RSQ:
case SHADER_OPCODE_SQRT:
case SHADER_OPCODE_EXP2:
case SHADER_OPCODE_LOG2:
case SHADER_OPCODE_SIN:
case SHADER_OPCODE_COS:
i965: Enable faster workaround-free math on Ivybridge. According to the documentation, Ivybridge's math instruction works in SIMD16 mode for the fragment shader, and no longer forbids align16 mode for the vertex shader. The documentation claims that SIMD16 mode isn't supported for INT DIV, but empirical evidence shows that it works fine. Presumably the note is trying to warn us that the variant that returns both quotient and remainder in (dst, dst + 1) doesn't work in SIMD16 mode since dst + 1 would be sechalf(dst), trashing half your results. Since we don't use that variant, we don't care and can just enable SIMD16 everywhere. The documentation also still claims that source modifiers and conditional modifiers aren't supported, but empirical evidence and study of the simulator both show that they work just fine. Goodbye workarounds. Math just works now. Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Paul Berry <stereotype441@gmail.com>
2011-10-18 12:24:47 -07:00
if (intel->gen == 6) {
i965: Start adding the VS visitor and codegen. The low-level IR is a mashup of brw_fs.cpp and ir_to_mesa.cpp. It's currently controlled by the INTEL_NEW_VS=1 environment variable, and only tested for the trivial "gl_Position = gl_Vertex;" shader so far.
2011-05-02 09:45:40 -07:00
generate_math1_gen6(inst, dst, src[0]);
} else {
i965: Enable faster workaround-free math on Ivybridge. According to the documentation, Ivybridge's math instruction works in SIMD16 mode for the fragment shader, and no longer forbids align16 mode for the vertex shader. The documentation claims that SIMD16 mode isn't supported for INT DIV, but empirical evidence shows that it works fine. Presumably the note is trying to warn us that the variant that returns both quotient and remainder in (dst, dst + 1) doesn't work in SIMD16 mode since dst + 1 would be sechalf(dst), trashing half your results. Since we don't use that variant, we don't care and can just enable SIMD16 everywhere. The documentation also still claims that source modifiers and conditional modifiers aren't supported, but empirical evidence and study of the simulator both show that they work just fine. Goodbye workarounds. Math just works now. Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Paul Berry <stereotype441@gmail.com>
2011-10-18 12:24:47 -07:00
/* Also works for Gen7. */
i965: Start adding the VS visitor and codegen. The low-level IR is a mashup of brw_fs.cpp and ir_to_mesa.cpp. It's currently controlled by the INTEL_NEW_VS=1 environment variable, and only tested for the trivial "gl_Position = gl_Vertex;" shader so far.
2011-05-02 09:45:40 -07:00
generate_math1_gen4(inst, dst, src[0]);
}
break;
case SHADER_OPCODE_POW:
i965/vs: Implement integer quotient and remainder math operations. Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Tested-by: Ian Romanick <ian.d.romanick@intel.com> Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Reviewed-by: Eric Anholt <eric@anholt.net>
2011-09-28 17:37:55 -07:00
case SHADER_OPCODE_INT_QUOTIENT:
case SHADER_OPCODE_INT_REMAINDER:
i965: Enable faster workaround-free math on Ivybridge. According to the documentation, Ivybridge's math instruction works in SIMD16 mode for the fragment shader, and no longer forbids align16 mode for the vertex shader. The documentation claims that SIMD16 mode isn't supported for INT DIV, but empirical evidence shows that it works fine. Presumably the note is trying to warn us that the variant that returns both quotient and remainder in (dst, dst + 1) doesn't work in SIMD16 mode since dst + 1 would be sechalf(dst), trashing half your results. Since we don't use that variant, we don't care and can just enable SIMD16 everywhere. The documentation also still claims that source modifiers and conditional modifiers aren't supported, but empirical evidence and study of the simulator both show that they work just fine. Goodbye workarounds. Math just works now. Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Paul Berry <stereotype441@gmail.com>
2011-10-18 12:24:47 -07:00
if (intel->gen >= 7) {
generate_math2_gen7(inst, dst, src[0], src[1]);
} else if (intel->gen == 6) {
i965/vs: Add support for ir_binop_pow. Fixes vs-pow-float-float.
2011-08-09 12:30:41 -07:00
generate_math2_gen6(inst, dst, src[0], src[1]);
} else {
generate_math2_gen4(inst, dst, src[0], src[1]);
}
i965: Start adding the VS visitor and codegen. The low-level IR is a mashup of brw_fs.cpp and ir_to_mesa.cpp. It's currently controlled by the INTEL_NEW_VS=1 environment variable, and only tested for the trivial "gl_Position = gl_Vertex;" shader so far.
2011-05-02 09:45:40 -07:00
break;
i965/vs: Implement vec4_visitor::generate_tex(). This is the part that takes the vec4_instruction IR and turns it into actual Gen ISA. v2: Add Gen4 messages, don't retype m0 to UW. Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
2011-10-26 13:53:11 -07:00
case SHADER_OPCODE_TEX:
case SHADER_OPCODE_TXD:
case SHADER_OPCODE_TXF:
i965: add a new virtual opcode: SHADER_OPCODE_TXF_MS This is very similar to the TXF opcode, but lowers to `ld2dms` rather than `ld` on Gen7. V4: - add SHADER_OPCODE_TXF_MS to is_tex() functions, so regalloc thinks it actually writes the correct number of registers. Otherwise in nontrivial shaders some of the registers tend to get clobbered, producing bad results. Signed-off-by: Chris Forbes <chrisf@ijw.co.nz> Reviewed-by: Paul Berry <stereotype441@gmail.com>
2013-01-24 21:35:15 +13:00
case SHADER_OPCODE_TXF_MS:
i965/vs: Implement vec4_visitor::generate_tex(). This is the part that takes the vec4_instruction IR and turns it into actual Gen ISA. v2: Add Gen4 messages, don't retype m0 to UW. Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
2011-10-26 13:53:11 -07:00
case SHADER_OPCODE_TXL:
case SHADER_OPCODE_TXS:
generate_tex(inst, dst, src[0]);
break;
i965: Start adding the VS visitor and codegen. The low-level IR is a mashup of brw_fs.cpp and ir_to_mesa.cpp. It's currently controlled by the INTEL_NEW_VS=1 environment variable, and only tested for the trivial "gl_Position = gl_Vertex;" shader so far.
2011-05-02 09:45:40 -07:00
case VS_OPCODE_URB_WRITE:
generate_urb_write(inst);
break;
i965/vs: Add support for scratch read/write codegen.
2011-08-07 13:36:11 -07:00
case VS_OPCODE_SCRATCH_READ:
generate_scratch_read(inst, dst, src[0]);
break;
case VS_OPCODE_SCRATCH_WRITE:
generate_scratch_write(inst, dst, src[0], src[1]);
break;
i965/vs: Add support for pull constant loads for uniform arrays. v2: reworked the instruction emit and made use of gen6_resolve_implied_move, from Ken's review
2011-08-22 10:35:24 -07:00
case VS_OPCODE_PULL_CONSTANT_LOAD:
i965/vs: Add a surface index to VS_OPCODE_PULL_CONSTANT instructions. Similar to the previous commit for the fragment shader, now we have a buffer index and an offset. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2012-06-25 14:36:28 -07:00
generate_pull_constant_load(inst, dst, src[0], src[1]);
i965/vs: Add support for pull constant loads for uniform arrays. v2: reworked the instruction emit and made use of gen6_resolve_implied_move, from Ken's review
2011-08-22 10:35:24 -07:00
break;
i965/vs: Use GRFs for pull constant offsets on gen7. This allows the computation of the offset to get written directly into the message source. shader-db results: total instructions in shared programs: 3308390 -> 3283025 (-0.77%) instructions in affected programs: 442998 -> 417633 (-5.73%) No difference in GLB2.7 low res (n=9). Reviewed-by: Matt Turner <mattst88@gmail.com>
2013-04-04 14:10:18 -07:00
case VS_OPCODE_PULL_CONSTANT_LOAD_GEN7:
generate_pull_constant_load_gen7(inst, dst, src[0], src[1]);
break;
i965: Add a debug flag for counting cycles spent in each compiled shader. This can be used for two purposes: Using hand-coded shaders to determine per-instruction timings, or figuring out which shader to optimize in a whole application. Note that this doesn't cover the instructions that set up the message to the URB/FB write -- we'd need to convert the MRF usage in these instructions to GRFs so that our offsets/times don't overwrite our shader outputs. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> (v1) v2: Check the timestamp reset flag in the VS, which is apparently getting set fairly regularly in the range we watch, resulting in negative numbers getting added to our 32-bit counter, and thus large values added to our uint64_t. v3: Rebase on reladdr changes, removing a new safety check that proved impossible to satisfy. Add a comment to the AOP defs from Ken's review, and put them in a slightly more sensible spot. v4: Check timestamp reset in the FS as well.
2012-11-27 14:10:52 -08:00
case SHADER_OPCODE_SHADER_TIME_ADD:
i965/vs: Use a send from a 2-register VGRF for shader time writes. This will let us emit it later, after we're setting up MRFs for the URB write. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2012-12-17 17:11:21 -08:00
brw_shader_time_add(p, src[0], SURF_INDEX_VS_SHADER_TIME);
i965: Add a debug flag for counting cycles spent in each compiled shader. This can be used for two purposes: Using hand-coded shaders to determine per-instruction timings, or figuring out which shader to optimize in a whole application. Note that this doesn't cover the instructions that set up the message to the URB/FB write -- we'd need to convert the MRF usage in these instructions to GRFs so that our offsets/times don't overwrite our shader outputs. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> (v1) v2: Check the timestamp reset flag in the VS, which is apparently getting set fairly regularly in the range we watch, resulting in negative numbers getting added to our 32-bit counter, and thus large values added to our uint64_t. v3: Rebase on reladdr changes, removing a new safety check that proved impossible to satisfy. Add a comment to the AOP defs from Ken's review, and put them in a slightly more sensible spot. v4: Check timestamp reset in the FS as well.
2012-11-27 14:10:52 -08:00
break;
i965: Start adding the VS visitor and codegen. The low-level IR is a mashup of brw_fs.cpp and ir_to_mesa.cpp. It's currently controlled by the INTEL_NEW_VS=1 environment variable, and only tested for the trivial "gl_Position = gl_Vertex;" shader so far.
2011-05-02 09:45:40 -07:00
default:
i965: Remove duplicate brw_opcodes table in favor of opcode_descs. brw_optimize.c's brw_opcodes table was a copy of brw_disasm.c's opcode_descs table, but with an additional field: is_arith. Now that I've deleted that, the two are identical. Keep the one in brw_disasm.c. Reviewed-by: Eric Anholt <eric@anholt.net>
2012-11-14 14:24:31 -08:00
if (inst->opcode < (int) ARRAY_SIZE(opcode_descs)) {
i965/vs: Abort on unsupported opcodes rather than failing. Final code generation should never fail. This is a bug, and there should be no user-triggerable cases where this could occur. Also, we're not going to have a fail() method after the split. Reviewed-by: Eric Anholt <eric@anholt.net> Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
2012-11-26 21:56:06 -08:00
_mesa_problem(ctx, "Unsupported opcode in `%s' in VS\n",
opcode_descs[inst->opcode].name);
i965: Start adding the VS visitor and codegen. The low-level IR is a mashup of brw_fs.cpp and ir_to_mesa.cpp. It's currently controlled by the INTEL_NEW_VS=1 environment variable, and only tested for the trivial "gl_Position = gl_Vertex;" shader so far.
2011-05-02 09:45:40 -07:00
} else {
i965/vs: Abort on unsupported opcodes rather than failing. Final code generation should never fail. This is a bug, and there should be no user-triggerable cases where this could occur. Also, we're not going to have a fail() method after the split. Reviewed-by: Eric Anholt <eric@anholt.net> Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
2012-11-26 21:56:06 -08:00
_mesa_problem(ctx, "Unsupported opcode %d in VS", inst->opcode);
i965: Start adding the VS visitor and codegen. The low-level IR is a mashup of brw_fs.cpp and ir_to_mesa.cpp. It's currently controlled by the INTEL_NEW_VS=1 environment variable, and only tested for the trivial "gl_Position = gl_Vertex;" shader so far.
2011-05-02 09:45:40 -07:00
}
i965/vs: Abort on unsupported opcodes rather than failing. Final code generation should never fail. This is a bug, and there should be no user-triggerable cases where this could occur. Also, we're not going to have a fail() method after the split. Reviewed-by: Eric Anholt <eric@anholt.net> Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
2012-11-26 21:56:06 -08:00
abort();
i965: Start adding the VS visitor and codegen. The low-level IR is a mashup of brw_fs.cpp and ir_to_mesa.cpp. It's currently controlled by the INTEL_NEW_VS=1 environment variable, and only tested for the trivial "gl_Position = gl_Vertex;" shader so far.
2011-05-02 09:45:40 -07:00
}
}
void
i965/vs: Split final assembly code generation out of vec4_visitor. Compiling shaders requires several main steps: 1. Generating VS IR from either GLSL IR or Mesa IR 2. Optimizing the IR 3. Register allocation 4. Generating assembly code This patch splits out step 4 into a separate class named "vec4_generator." There are several reasons for doing so: 1. Future hardware has a different instruction encoding. Splitting this out will allow us to replace vec4_generator (which relies heavily on the brw_eu_emit.c code and struct brw_instruction) with a new code generator that writes the new format. 2. It reduces the size of the vec4_visitor monolith. (Arguably, a lot more should be split out, but that's left for "future work.") 3. Separate namespaces allow us to make helper functions for generating instructions in both classes: ADD() can exist in vec4_visitor and create IR, while ADD() in vec4_generator() can create brw_instructions. (Patches for this upcoming.) Reviewed-by: Eric Anholt <eric@anholt.net> Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
2012-11-26 22:53:10 -08:00
vec4_generator::generate_code(exec_list *instructions)
i965: Start adding the VS visitor and codegen. The low-level IR is a mashup of brw_fs.cpp and ir_to_mesa.cpp. It's currently controlled by the INTEL_NEW_VS=1 environment variable, and only tested for the trivial "gl_Position = gl_Vertex;" shader so far.
2011-05-02 09:45:40 -07:00
{
i965: Move program dump to a helper function in brw_eu.c. It's going to get more complicated when we do instruction compaction. This also introduces putting the program offset in the output. v2: Use next_insn_offset in brw_get_program(), too. Reviewed-by: Paul Berry <stereotype441@gmail.com>
2012-02-03 11:50:42 +01:00
int last_native_insn_offset = 0;
i965: Start adding the VS visitor and codegen. The low-level IR is a mashup of brw_fs.cpp and ir_to_mesa.cpp. It's currently controlled by the INTEL_NEW_VS=1 environment variable, and only tested for the trivial "gl_Position = gl_Vertex;" shader so far.
2011-05-02 09:45:40 -07:00
const char *last_annotation_string = NULL;
i965/vs: Replace brw_vs_emit.c with dumping code into the vec4_visitor. Rather than having two separate backends, just create a small layer that translates the subset of Mesa IR used for ARB_vertex_program and fixed function programs to the Vec4 IR. This allows us to use the same optimization passes, code generator, register allocator as for GLSL. v2: Incorporate Eric's review comments. - Fix use of uninitialized src_swiz[] values in the SWIZZLE_ZERO/ONE case: just initialize it to 0 (.x) since the value doesn't matter (those channels get writemasked out anyway). - Properly reswizzle source register's swizzles, rather than overwriting the swizzle. - Port the old brw_vs_emit code for computing .x of the EXP2 opcode. - Update comments, removing mention of NV_vertex_program, etc. - Delete remaining #warning lines and debug comments. Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Eric Anholt <eric@anholt.net>
2012-10-08 10:21:30 -07:00
const void *last_annotation_ir = NULL;
i965: Start adding the VS visitor and codegen. The low-level IR is a mashup of brw_fs.cpp and ir_to_mesa.cpp. It's currently controlled by the INTEL_NEW_VS=1 environment variable, and only tested for the trivial "gl_Position = gl_Vertex;" shader so far.
2011-05-02 09:45:40 -07:00
if (unlikely(INTEL_DEBUG & DEBUG_VS)) {
i965/vs: Replace brw_vs_emit.c with dumping code into the vec4_visitor. Rather than having two separate backends, just create a small layer that translates the subset of Mesa IR used for ARB_vertex_program and fixed function programs to the Vec4 IR. This allows us to use the same optimization passes, code generator, register allocator as for GLSL. v2: Incorporate Eric's review comments. - Fix use of uninitialized src_swiz[] values in the SWIZZLE_ZERO/ONE case: just initialize it to 0 (.x) since the value doesn't matter (those channels get writemasked out anyway). - Properly reswizzle source register's swizzles, rather than overwriting the swizzle. - Port the old brw_vs_emit code for computing .x of the EXP2 opcode. - Update comments, removing mention of NV_vertex_program, etc. - Delete remaining #warning lines and debug comments. Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Eric Anholt <eric@anholt.net>
2012-10-08 10:21:30 -07:00
if (shader) {
i965/vs: Rename vec4_generator::prog to shader_prog. The next patch is going to change the type of vec4_generator::vp from struct gl_vertex_program * to struct gl_program *, and rename it. The sensible name to change it to is vec4_generator::prog. However, prog is already used. Since the existing vec4_generator::prog is of type struct gl_shader_program, it makes sense to rename it to shader_prog. Reviewed-by: Eric Anholt <eric@anholt.net> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2013-04-09 14:31:28 -07:00
printf("Native code for vertex shader %d:\n", shader_prog->Name);
i965/vs: Replace brw_vs_emit.c with dumping code into the vec4_visitor. Rather than having two separate backends, just create a small layer that translates the subset of Mesa IR used for ARB_vertex_program and fixed function programs to the Vec4 IR. This allows us to use the same optimization passes, code generator, register allocator as for GLSL. v2: Incorporate Eric's review comments. - Fix use of uninitialized src_swiz[] values in the SWIZZLE_ZERO/ONE case: just initialize it to 0 (.x) since the value doesn't matter (those channels get writemasked out anyway). - Properly reswizzle source register's swizzles, rather than overwriting the swizzle. - Port the old brw_vs_emit code for computing .x of the EXP2 opcode. - Update comments, removing mention of NV_vertex_program, etc. - Delete remaining #warning lines and debug comments. Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Eric Anholt <eric@anholt.net>
2012-10-08 10:21:30 -07:00
} else {
i965/vs: Generalize data structures pointed to by vec4_generator. This patch removes the following field from vec4_generator, since it is not used: - struct brw_vs_compile *c And changes the following field: - struct gl_vertex_program *vp => struct gl_program *prog With these changes, vec4_generator no longer refers to any VS-specific data structures. This will pave the way for re-using it for geometry shaders. Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> v2: Use the name "prog" rather than "p". Reviewed-by: Eric Anholt <eric@anholt.net> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2013-02-17 11:25:37 -08:00
printf("Native code for vertex program %d:\n", prog->Id);
i965/vs: Replace brw_vs_emit.c with dumping code into the vec4_visitor. Rather than having two separate backends, just create a small layer that translates the subset of Mesa IR used for ARB_vertex_program and fixed function programs to the Vec4 IR. This allows us to use the same optimization passes, code generator, register allocator as for GLSL. v2: Incorporate Eric's review comments. - Fix use of uninitialized src_swiz[] values in the SWIZZLE_ZERO/ONE case: just initialize it to 0 (.x) since the value doesn't matter (those channels get writemasked out anyway). - Properly reswizzle source register's swizzles, rather than overwriting the swizzle. - Port the old brw_vs_emit code for computing .x of the EXP2 opcode. - Update comments, removing mention of NV_vertex_program, etc. - Delete remaining #warning lines and debug comments. Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Eric Anholt <eric@anholt.net>
2012-10-08 10:21:30 -07:00
}
i965: Start adding the VS visitor and codegen. The low-level IR is a mashup of brw_fs.cpp and ir_to_mesa.cpp. It's currently controlled by the INTEL_NEW_VS=1 environment variable, and only tested for the trivial "gl_Position = gl_Vertex;" shader so far.
2011-05-02 09:45:40 -07:00
}
i965/vs: Split final assembly code generation out of vec4_visitor. Compiling shaders requires several main steps: 1. Generating VS IR from either GLSL IR or Mesa IR 2. Optimizing the IR 3. Register allocation 4. Generating assembly code This patch splits out step 4 into a separate class named "vec4_generator." There are several reasons for doing so: 1. Future hardware has a different instruction encoding. Splitting this out will allow us to replace vec4_generator (which relies heavily on the brw_eu_emit.c code and struct brw_instruction) with a new code generator that writes the new format. 2. It reduces the size of the vec4_visitor monolith. (Arguably, a lot more should be split out, but that's left for "future work.") 3. Separate namespaces allow us to make helper functions for generating instructions in both classes: ADD() can exist in vec4_visitor and create IR, while ADD() in vec4_generator() can create brw_instructions. (Patches for this upcoming.) Reviewed-by: Eric Anholt <eric@anholt.net> Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
2012-11-26 22:53:10 -08:00
foreach_list(node, instructions) {
i965: Start adding the VS visitor and codegen. The low-level IR is a mashup of brw_fs.cpp and ir_to_mesa.cpp. It's currently controlled by the INTEL_NEW_VS=1 environment variable, and only tested for the trivial "gl_Position = gl_Vertex;" shader so far.
2011-05-02 09:45:40 -07:00
vec4_instruction *inst = (vec4_instruction *)node;
struct brw_reg src[3], dst;
if (unlikely(INTEL_DEBUG & DEBUG_VS)) {
if (last_annotation_ir != inst->ir) {
last_annotation_ir = inst->ir;
if (last_annotation_ir) {
printf(" ");
i965/vs: Replace brw_vs_emit.c with dumping code into the vec4_visitor. Rather than having two separate backends, just create a small layer that translates the subset of Mesa IR used for ARB_vertex_program and fixed function programs to the Vec4 IR. This allows us to use the same optimization passes, code generator, register allocator as for GLSL. v2: Incorporate Eric's review comments. - Fix use of uninitialized src_swiz[] values in the SWIZZLE_ZERO/ONE case: just initialize it to 0 (.x) since the value doesn't matter (those channels get writemasked out anyway). - Properly reswizzle source register's swizzles, rather than overwriting the swizzle. - Port the old brw_vs_emit code for computing .x of the EXP2 opcode. - Update comments, removing mention of NV_vertex_program, etc. - Delete remaining #warning lines and debug comments. Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Eric Anholt <eric@anholt.net>
2012-10-08 10:21:30 -07:00
if (shader) {
((ir_instruction *) last_annotation_ir)->print();
} else {
const prog_instruction *vpi;
vpi = (const prog_instruction *) inst->ir;
i965/vs: Generalize data structures pointed to by vec4_generator. This patch removes the following field from vec4_generator, since it is not used: - struct brw_vs_compile *c And changes the following field: - struct gl_vertex_program *vp => struct gl_program *prog With these changes, vec4_generator no longer refers to any VS-specific data structures. This will pave the way for re-using it for geometry shaders. Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> v2: Use the name "prog" rather than "p". Reviewed-by: Eric Anholt <eric@anholt.net> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2013-02-17 11:25:37 -08:00
printf("%d: ", (int)(vpi - prog->Instructions));
i965/vs: Replace brw_vs_emit.c with dumping code into the vec4_visitor. Rather than having two separate backends, just create a small layer that translates the subset of Mesa IR used for ARB_vertex_program and fixed function programs to the Vec4 IR. This allows us to use the same optimization passes, code generator, register allocator as for GLSL. v2: Incorporate Eric's review comments. - Fix use of uninitialized src_swiz[] values in the SWIZZLE_ZERO/ONE case: just initialize it to 0 (.x) since the value doesn't matter (those channels get writemasked out anyway). - Properly reswizzle source register's swizzles, rather than overwriting the swizzle. - Port the old brw_vs_emit code for computing .x of the EXP2 opcode. - Update comments, removing mention of NV_vertex_program, etc. - Delete remaining #warning lines and debug comments. Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Eric Anholt <eric@anholt.net>
2012-10-08 10:21:30 -07:00
_mesa_fprint_instruction_opt(stdout, vpi, 0,
PROG_PRINT_DEBUG, NULL);
}
i965: Start adding the VS visitor and codegen. The low-level IR is a mashup of brw_fs.cpp and ir_to_mesa.cpp. It's currently controlled by the INTEL_NEW_VS=1 environment variable, and only tested for the trivial "gl_Position = gl_Vertex;" shader so far.
2011-05-02 09:45:40 -07:00
printf("\n");
}
}
if (last_annotation_string != inst->annotation) {
last_annotation_string = inst->annotation;
if (last_annotation_string)
printf(" %s\n", last_annotation_string);
}
}
for (unsigned int i = 0; i < 3; i++) {
src[i] = inst->get_src(i);
}
dst = inst->get_dst();
brw_set_conditionalmod(p, inst->conditional_mod);
brw_set_predicate_control(p, inst->predicate);
brw_set_predicate_inverse(p, inst->predicate_inverse);
brw_set_saturate(p, inst->saturate);
i965: Add a flag for instructions with normal writemasking disabled. For getting values from the new timestamp register, the channels we load have nothing to do with the pixels dispatched.
2012-11-28 14:16:03 -08:00
brw_set_mask_control(p, inst->force_writemask_all);
i965: Start adding the VS visitor and codegen. The low-level IR is a mashup of brw_fs.cpp and ir_to_mesa.cpp. It's currently controlled by the INTEL_NEW_VS=1 environment variable, and only tested for the trivial "gl_Position = gl_Vertex;" shader so far.
2011-05-02 09:45:40 -07:00
i965/vs: Add a pass to set dependency control fields on instructions. This is a more aggressive version of the old brw_optimize() path. Reduces cycles spent in the vertex shader on minecraft by 18.6% +/- 10.0% (n=15). Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2012-11-30 18:29:34 -08:00
unsigned pre_emit_nr_insn = p->nr_insn;
i965: Start adding the VS visitor and codegen. The low-level IR is a mashup of brw_fs.cpp and ir_to_mesa.cpp. It's currently controlled by the INTEL_NEW_VS=1 environment variable, and only tested for the trivial "gl_Position = gl_Vertex;" shader so far.
2011-05-02 09:45:40 -07:00
switch (inst->opcode) {
case BRW_OPCODE_MOV:
brw_MOV(p, dst, src[0]);
break;
case BRW_OPCODE_ADD:
brw_ADD(p, dst, src[0], src[1]);
break;
case BRW_OPCODE_MUL:
brw_MUL(p, dst, src[0], src[1]);
break;
i965/vs: Fix multiplies to actually do 32-bit multiplies. Fixes vs-op-mult-int-int and friends.
2011-08-15 21:02:10 -07:00
case BRW_OPCODE_MACH:
brw_set_acc_write_control(p, 1);
brw_MACH(p, dst, src[0], src[1]);
brw_set_acc_write_control(p, 0);
break;
i965: Start adding the VS visitor and codegen. The low-level IR is a mashup of brw_fs.cpp and ir_to_mesa.cpp. It's currently controlled by the INTEL_NEW_VS=1 environment variable, and only tested for the trivial "gl_Position = gl_Vertex;" shader so far.
2011-05-02 09:45:40 -07:00
case BRW_OPCODE_FRC:
brw_FRC(p, dst, src[0]);
break;
case BRW_OPCODE_RNDD:
brw_RNDD(p, dst, src[0]);
break;
case BRW_OPCODE_RNDE:
brw_RNDE(p, dst, src[0]);
break;
case BRW_OPCODE_RNDZ:
brw_RNDZ(p, dst, src[0]);
break;
case BRW_OPCODE_AND:
brw_AND(p, dst, src[0], src[1]);
break;
case BRW_OPCODE_OR:
brw_OR(p, dst, src[0], src[1]);
break;
case BRW_OPCODE_XOR:
brw_XOR(p, dst, src[0], src[1]);
break;
case BRW_OPCODE_NOT:
brw_NOT(p, dst, src[0]);
break;
case BRW_OPCODE_ASR:
brw_ASR(p, dst, src[0], src[1]);
break;
case BRW_OPCODE_SHR:
brw_SHR(p, dst, src[0], src[1]);
break;
case BRW_OPCODE_SHL:
brw_SHL(p, dst, src[0], src[1]);
break;
case BRW_OPCODE_CMP:
brw_CMP(p, dst, inst->conditional_mod, src[0], src[1]);
break;
case BRW_OPCODE_SEL:
brw_SEL(p, dst, src[0], src[1]);
break;
i965/vs: Add support for emitting DPH opcodes. Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Eric Anholt <eric@anholt.net>
2012-10-08 10:26:13 -07:00
case BRW_OPCODE_DPH:
brw_DPH(p, dst, src[0], src[1]);
break;
i965/vs: Add support for dot product opcodes. Fixes glsl-vs-dot-vec2.
2011-08-05 19:40:46 -07:00
case BRW_OPCODE_DP4:
brw_DP4(p, dst, src[0], src[1]);
break;
case BRW_OPCODE_DP3:
brw_DP3(p, dst, src[0], src[1]);
break;
case BRW_OPCODE_DP2:
brw_DP2(p, dst, src[0], src[1]);
break;
i965/vs/gen7: Emit code for GLSL ES 3.00 pack/unpack operations (v3) FIXME: This patch emits VS code that violates documented hardware restrictions and then relies on undocumented behavior that results from that violation. This patch passes all tests, but should be fixed ASAP to conform to the hardware documentation. v2: Explain undocumented hardware behavior. Improve comments. v3: Use ALU1 helper methods F32TO16() and F16TO32(). [for anholt] Reviewed-by: Eric Anholt <eric@anholt.net> Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> (v1) Signed-off-by: Chad Versace <chad.versace@linux.intel.com>
2013-01-09 11:44:31 -08:00
case BRW_OPCODE_F32TO16:
brw_F32TO16(p, dst, src[0]);
break;
case BRW_OPCODE_F16TO32:
brw_F16TO32(p, dst, src[0]);
break;
i965: Start adding the VS visitor and codegen. The low-level IR is a mashup of brw_fs.cpp and ir_to_mesa.cpp. It's currently controlled by the INTEL_NEW_VS=1 environment variable, and only tested for the trivial "gl_Position = gl_Vertex;" shader so far.
2011-05-02 09:45:40 -07:00
case BRW_OPCODE_IF:
if (inst->src[0].file != BAD_FILE) {
/* The instruction has an embedded compare (only allowed on gen6) */
assert(intel->gen == 6);
gen6_IF(p, inst->conditional_mod, src[0], src[1]);
} else {
i965/vs: Add support for if(any_nequal()) and if(all_equal()) on gen6. Fixes vs-temp-array-mat2-col-rd.shader_test.
2011-08-05 20:03:31 -07:00
struct brw_instruction *brw_inst = brw_IF(p, BRW_EXECUTE_8);
brw_inst->header.predicate_control = inst->predicate;
i965: Start adding the VS visitor and codegen. The low-level IR is a mashup of brw_fs.cpp and ir_to_mesa.cpp. It's currently controlled by the INTEL_NEW_VS=1 environment variable, and only tested for the trivial "gl_Position = gl_Vertex;" shader so far.
2011-05-02 09:45:40 -07:00
}
break;
case BRW_OPCODE_ELSE:
brw_ELSE(p);
break;
case BRW_OPCODE_ENDIF:
brw_ENDIF(p);
break;
case BRW_OPCODE_DO:
i965: Don't make consumers of brw_WHILE do pre-gen6 BREAK/CONT patching. The EU code itself can just do this work, since all the consumers were duplicating it. Reviewed-by: Yuanhan Liu <yuanhan.liu@linux.intel.com>
2011-12-06 12:30:03 -08:00
brw_DO(p, BRW_EXECUTE_8);
i965: Start adding the VS visitor and codegen. The low-level IR is a mashup of brw_fs.cpp and ir_to_mesa.cpp. It's currently controlled by the INTEL_NEW_VS=1 environment variable, and only tested for the trivial "gl_Position = gl_Vertex;" shader so far.
2011-05-02 09:45:40 -07:00
break;
case BRW_OPCODE_BREAK:
i965: Don't make consumers of brw_CONT/brw_WHILE track if depth in loop. The codegen backends all had this same tracking, so just do it at the EU level. Reviewed-by: Yuanhan Liu <yuanhan.liu@linux.intel.com>
2011-12-06 12:44:41 -08:00
brw_BREAK(p);
i965: Start adding the VS visitor and codegen. The low-level IR is a mashup of brw_fs.cpp and ir_to_mesa.cpp. It's currently controlled by the INTEL_NEW_VS=1 environment variable, and only tested for the trivial "gl_Position = gl_Vertex;" shader so far.
2011-05-02 09:45:40 -07:00
brw_set_predicate_control(p, BRW_PREDICATE_NONE);
break;
case BRW_OPCODE_CONTINUE:
/* FINISHME: We need to write the loop instruction support still. */
if (intel->gen >= 6)
i965: Drop unused do_insn argument from gen6_CONT(). The branch distances get patched up later at the WHILE instruction. Reviewed-by: Yuanhan Liu <yuanhan.liu@linux.intel.com>
2011-12-06 12:09:58 -08:00
gen6_CONT(p);
i965: Start adding the VS visitor and codegen. The low-level IR is a mashup of brw_fs.cpp and ir_to_mesa.cpp. It's currently controlled by the INTEL_NEW_VS=1 environment variable, and only tested for the trivial "gl_Position = gl_Vertex;" shader so far.
2011-05-02 09:45:40 -07:00
else
i965: Don't make consumers of brw_CONT/brw_WHILE track if depth in loop. The codegen backends all had this same tracking, so just do it at the EU level. Reviewed-by: Yuanhan Liu <yuanhan.liu@linux.intel.com>
2011-12-06 12:44:41 -08:00
brw_CONT(p);
i965: Start adding the VS visitor and codegen. The low-level IR is a mashup of brw_fs.cpp and ir_to_mesa.cpp. It's currently controlled by the INTEL_NEW_VS=1 environment variable, and only tested for the trivial "gl_Position = gl_Vertex;" shader so far.
2011-05-02 09:45:40 -07:00
brw_set_predicate_control(p, BRW_PREDICATE_NONE);
break;
i965: Don't make consumers of brw_WHILE do pre-gen6 BREAK/CONT patching. The EU code itself can just do this work, since all the consumers were duplicating it. Reviewed-by: Yuanhan Liu <yuanhan.liu@linux.intel.com>
2011-12-06 12:30:03 -08:00
case BRW_OPCODE_WHILE:
brw_WHILE(p);
i965: Start adding the VS visitor and codegen. The low-level IR is a mashup of brw_fs.cpp and ir_to_mesa.cpp. It's currently controlled by the INTEL_NEW_VS=1 environment variable, and only tested for the trivial "gl_Position = gl_Vertex;" shader so far.
2011-05-02 09:45:40 -07:00
break;
default:
i965/vs: rename vec4_generator::generate_vs_instruction. Since this function is going to get used for geometry shaders too, it deserves a more generic name: generate_vec4_instruction. Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Eric Anholt <eric@anholt.net> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2013-02-17 11:34:05 -08:00
generate_vec4_instruction(inst, dst, src);
i965: Start adding the VS visitor and codegen. The low-level IR is a mashup of brw_fs.cpp and ir_to_mesa.cpp. It's currently controlled by the INTEL_NEW_VS=1 environment variable, and only tested for the trivial "gl_Position = gl_Vertex;" shader so far.
2011-05-02 09:45:40 -07:00
break;
}
i965/vs: Add a pass to set dependency control fields on instructions. This is a more aggressive version of the old brw_optimize() path. Reduces cycles spent in the vertex shader on minecraft by 18.6% +/- 10.0% (n=15). Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2012-11-30 18:29:34 -08:00
if (inst->no_dd_clear || inst->no_dd_check) {
assert(p->nr_insn == pre_emit_nr_insn + 1 ||
!"no_dd_check or no_dd_clear set for IR emitting more "
"than 1 instruction");
struct brw_instruction *last = &p->store[pre_emit_nr_insn];
if (inst->no_dd_clear)
last->header.dependency_control |= BRW_DEPENDENCY_NOTCLEARED;
if (inst->no_dd_check)
last->header.dependency_control |= BRW_DEPENDENCY_NOTCHECKED;
}
i965: Start adding the VS visitor and codegen. The low-level IR is a mashup of brw_fs.cpp and ir_to_mesa.cpp. It's currently controlled by the INTEL_NEW_VS=1 environment variable, and only tested for the trivial "gl_Position = gl_Vertex;" shader so far.
2011-05-02 09:45:40 -07:00
if (unlikely(INTEL_DEBUG & DEBUG_VS)) {
i965: Move program dump to a helper function in brw_eu.c. It's going to get more complicated when we do instruction compaction. This also introduces putting the program offset in the output. v2: Use next_insn_offset in brw_get_program(), too. Reviewed-by: Paul Berry <stereotype441@gmail.com>
2012-02-03 11:50:42 +01:00
brw_dump_compile(p, stdout,
last_native_insn_offset, p->next_insn_offset);
i965: Start adding the VS visitor and codegen. The low-level IR is a mashup of brw_fs.cpp and ir_to_mesa.cpp. It's currently controlled by the INTEL_NEW_VS=1 environment variable, and only tested for the trivial "gl_Position = gl_Vertex;" shader so far.
2011-05-02 09:45:40 -07:00
}
i965: Move program dump to a helper function in brw_eu.c. It's going to get more complicated when we do instruction compaction. This also introduces putting the program offset in the output. v2: Use next_insn_offset in brw_get_program(), too. Reviewed-by: Paul Berry <stereotype441@gmail.com>
2012-02-03 11:50:42 +01:00
last_native_insn_offset = p->next_insn_offset;
i965: Start adding the VS visitor and codegen. The low-level IR is a mashup of brw_fs.cpp and ir_to_mesa.cpp. It's currently controlled by the INTEL_NEW_VS=1 environment variable, and only tested for the trivial "gl_Position = gl_Vertex;" shader so far.
2011-05-02 09:45:40 -07:00
}
if (unlikely(INTEL_DEBUG & DEBUG_VS)) {
printf("\n");
}
brw_set_uip_jip(p);
/* OK, while the INTEL_DEBUG=vs above is very nice for debugging VS
* emit issues, it doesn't get the jump distances into the output,
* which is often something we want to debug. So this is here in
* case you're doing that.
*/
i965: Move program dump to a helper function in brw_eu.c. It's going to get more complicated when we do instruction compaction. This also introduces putting the program offset in the output. v2: Use next_insn_offset in brw_get_program(), too. Reviewed-by: Paul Berry <stereotype441@gmail.com>
2012-02-03 11:50:42 +01:00
if (0 && unlikely(INTEL_DEBUG & DEBUG_VS)) {
brw_dump_compile(p, stdout, 0, p->next_insn_offset);
i965: Start adding the VS visitor and codegen. The low-level IR is a mashup of brw_fs.cpp and ir_to_mesa.cpp. It's currently controlled by the INTEL_NEW_VS=1 environment variable, and only tested for the trivial "gl_Position = gl_Vertex;" shader so far.
2011-05-02 09:45:40 -07:00
}
}
i965/vs: Split final assembly code generation out of vec4_visitor. Compiling shaders requires several main steps: 1. Generating VS IR from either GLSL IR or Mesa IR 2. Optimizing the IR 3. Register allocation 4. Generating assembly code This patch splits out step 4 into a separate class named "vec4_generator." There are several reasons for doing so: 1. Future hardware has a different instruction encoding. Splitting this out will allow us to replace vec4_generator (which relies heavily on the brw_eu_emit.c code and struct brw_instruction) with a new code generator that writes the new format. 2. It reduces the size of the vec4_visitor monolith. (Arguably, a lot more should be split out, but that's left for "future work.") 3. Separate namespaces allow us to make helper functions for generating instructions in both classes: ADD() can exist in vec4_visitor and create IR, while ADD() in vec4_generator() can create brw_instructions. (Patches for this upcoming.) Reviewed-by: Eric Anholt <eric@anholt.net> Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
2012-11-26 22:53:10 -08:00
const unsigned *
vec4_generator::generate_assembly(exec_list *instructions,
unsigned *assembly_size)
{
brw_set_access_mode(p, BRW_ALIGN_16);
generate_code(instructions);
return brw_get_program(p, assembly_size);
}
i965: Start adding the VS visitor and codegen. The low-level IR is a mashup of brw_fs.cpp and ir_to_mesa.cpp. It's currently controlled by the INTEL_NEW_VS=1 environment variable, and only tested for the trivial "gl_Position = gl_Vertex;" shader so far.
2011-05-02 09:45:40 -07:00
} /* namespace brw */
Reference in a new issue Copy permalink