OpenHarmony/third_party_mesa3d
2
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
e23e4f67bed51a8dfd182eae6c7e8e23a7d2cb0e
third_party_mesa3d/src/mesa/drivers/dri/i965/brw_vec4.h

721 lines
23 KiB
C
Raw Normal View History

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
/*
* Copyright © 2011 Intel Corporation
*
* 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.
*/
#ifndef BRW_VEC4_H
#define BRW_VEC4_H
#include <stdint.h>
#include "brw_shader.h"
#include "main/compiler.h"
#include "program/hash_table.h"
i965/vec4: Move vec4 data structures and functions to brw_vec4.{cpp,h}. This patch moves the following things into brw_vec4.{cpp,h}: - struct brw_vec4_compile - struct brw_vec4_prog_key - brw_vec4_prog_data_compare() - brw_vec4_prog_data_free() This will allow us to avoid having to include brw_vs.h in geometry-shader-specific files. Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Matt Turner <mattst88@gmail.com>
2013-08-14 17:20:04 -07:00
#include "brw_program.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
i965: Make brw_{shader,vec4}.h safe to include from C. The patch that follows will move the definition of struct brw_vec4_prog_key from brw_vs.h to brw_vec4.h, making it necessary for brw_vs.h to include brw_vec4.h (because brw_vs.h defines struct brw_vs_prog_key, which contains brw_vec4_prog_key as a member). Since brw_vs.h is included from C source files, that means that brw_vec4.h will need to be safe to include from C. Same for brw_shader.h, since it is included by brw_vec4.h. Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Matt Turner <mattst88@gmail.com>
2013-08-21 07:53:42 -07:00
#ifdef __cplusplus
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
extern "C" {
i965: Make brw_{shader,vec4}.h safe to include from C. The patch that follows will move the definition of struct brw_vec4_prog_key from brw_vs.h to brw_vec4.h, making it necessary for brw_vs.h to include brw_vec4.h (because brw_vs.h defines struct brw_vs_prog_key, which contains brw_vec4_prog_key as a member). Since brw_vs.h is included from C source files, that means that brw_vec4.h will need to be safe to include from C. Same for brw_shader.h, since it is included by brw_vec4.h. Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Matt Turner <mattst88@gmail.com>
2013-08-21 07:53:42 -07:00
#endif
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
#include "brw_context.h"
#include "brw_eu.h"
i965: Make brw_{shader,vec4}.h safe to include from C. The patch that follows will move the definition of struct brw_vec4_prog_key from brw_vs.h to brw_vec4.h, making it necessary for brw_vs.h to include brw_vec4.h (because brw_vs.h defines struct brw_vs_prog_key, which contains brw_vec4_prog_key as a member). Since brw_vs.h is included from C source files, that means that brw_vec4.h will need to be safe to include from C. Same for brw_shader.h, since it is included by brw_vec4.h. Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Matt Turner <mattst88@gmail.com>
2013-08-21 07:53:42 -07:00
#ifdef __cplusplus
}; /* extern "C" */
i965: Create a new vec4 backend for Broadwell. This replaces the old vec4_generator backend. v2: Port to use the C-based instruction representation. Also, remove Geometry Shader offset hacks - the visitor will handle those instead of this code. v3: Texturing fixes (including adding textureGather support). v4: Pass brw_context to gen8_instruction functions as required. v5: Add SHADER_OPCODE_TXF_MCS support; port DUAL_INSTANCED gs fixes (caught by Eric). Simplify ADDC/SUBB handling; add comments to gen8_set_dp_message calls (suggested by Matt). Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Eric Anholt <eric@anholt.net> Reviewed-by: Matt Turner <mattst88@gmail.com>
2012-12-06 22:37:34 -08:00
#include "gen8_generator.h"
i965: Make brw_{shader,vec4}.h safe to include from C. The patch that follows will move the definition of struct brw_vec4_prog_key from brw_vs.h to brw_vec4.h, making it necessary for brw_vs.h to include brw_vec4.h (because brw_vs.h defines struct brw_vs_prog_key, which contains brw_vec4_prog_key as a member). Since brw_vs.h is included from C source files, that means that brw_vec4.h will need to be safe to include from C. Same for brw_shader.h, since it is included by brw_vec4.h. Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Matt Turner <mattst88@gmail.com>
2013-08-21 07:53:42 -07:00
#endif
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: Fix Android build by removing relative includes Replace each occurence of #include "../glsl/*.h" with #include "glsl/*.h" Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Signed-off-by: Chad Versace <chad@chad-versace.us>
2011-08-26 13:58:41 -07:00
#include "glsl/ir.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
i965/vec4: Move vec4 data structures and functions to brw_vec4.{cpp,h}. This patch moves the following things into brw_vec4.{cpp,h}: - struct brw_vec4_compile - struct brw_vec4_prog_key - brw_vec4_prog_data_compare() - brw_vec4_prog_data_free() This will allow us to avoid having to include brw_vs.h in geometry-shader-specific files. Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Matt Turner <mattst88@gmail.com>
2013-08-14 17:20:04 -07:00
struct brw_vec4_compile {
GLuint last_scratch; /**< measured in 32-byte (register size) units */
};
struct brw_vec4_prog_key {
GLuint program_string_id;
/**
* True if at least one clip flag is enabled, regardless of whether the
* shader uses clip planes or gl_ClipDistance.
*/
GLuint userclip_active:1;
/**
* How many user clipping planes are being uploaded to the vertex shader as
* push constants.
*/
GLuint nr_userclip_plane_consts:4;
GLuint clamp_vertex_color:1;
struct brw_sampler_prog_key_data tex;
};
i965: Stop including brw_vs.h from brw_vec4.h. This is backwards from what we are going to want in the long term, which is: - brw_vec4.h declares general-purpose vec4 infrastructure needed by both VS and GS - brw_vs.h includes brw_vec4.h and adds VS-specific parts. - brw_gs.h includes brw_vec4.h and adds GS-specific parts. Note that at the moment brw_vec.h contains a fair amount of VS-specific declarations--I plan to address that in a later patch. Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Matt Turner <mattst88@gmail.com>
2013-03-20 11:54:33 -07:00
i965: Make brw_{shader,vec4}.h safe to include from C. The patch that follows will move the definition of struct brw_vec4_prog_key from brw_vs.h to brw_vec4.h, making it necessary for brw_vs.h to include brw_vec4.h (because brw_vs.h defines struct brw_vs_prog_key, which contains brw_vec4_prog_key as a member). Since brw_vs.h is included from C source files, that means that brw_vec4.h will need to be safe to include from C. Same for brw_shader.h, since it is included by brw_vec4.h. Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Matt Turner <mattst88@gmail.com>
2013-08-21 07:53:42 -07:00
#ifdef __cplusplus
i965/vec4: Move vec4 data structures and functions to brw_vec4.{cpp,h}. This patch moves the following things into brw_vec4.{cpp,h}: - struct brw_vec4_compile - struct brw_vec4_prog_key - brw_vec4_prog_data_compare() - brw_vec4_prog_data_free() This will allow us to avoid having to include brw_vs.h in geometry-shader-specific files. Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Matt Turner <mattst88@gmail.com>
2013-08-14 17:20:04 -07:00
extern "C" {
#endif
i965/vec4: Extract function to set up vec4 prog key for precompiling. This will allow us to re-use it for precompiling geometry shaders. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Reviewed-by: Matt Turner <mattst88@gmail.com>
2013-10-23 10:17:30 -07:00
void
brw_vec4_setup_prog_key_for_precompile(struct gl_context *ctx,
struct brw_vec4_prog_key *key,
GLuint id, struct gl_program *prog);
i965/vec4: Move vec4 data structures and functions to brw_vec4.{cpp,h}. This patch moves the following things into brw_vec4.{cpp,h}: - struct brw_vec4_compile - struct brw_vec4_prog_key - brw_vec4_prog_data_compare() - brw_vec4_prog_data_free() This will allow us to avoid having to include brw_vs.h in geometry-shader-specific files. Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Matt Turner <mattst88@gmail.com>
2013-08-14 17:20:04 -07:00
bool brw_vec4_prog_data_compare(const struct brw_vec4_prog_data *a,
const struct brw_vec4_prog_data *b);
void brw_vec4_prog_data_free(const struct brw_vec4_prog_data *prog_data);
#ifdef __cplusplus
} /* extern "C" */
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 {
class dst_reg;
i965/vs: Move class functions to brw_vec4.cpp. This has less impact than for the FS (4k savings), because it was partially done already, but makes things more consistent. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2012-07-04 13:25:27 -07:00
unsigned
swizzle_for_size(int 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
class reg
{
public:
i965: Remove the "ARF" register file. The registers in the architecture register file don't share much in common, so there's no point in grouping them together. Use the HW_REG class instead. The vec4 backend already does this. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2013-09-27 17:37:51 -07:00
/** Register file: GRF, MRF, IMM. */
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
enum register_file file;
/** virtual register number. 0 = fixed hw reg */
int reg;
/** Offset within the virtual register. */
int reg_offset;
/** Register type. BRW_REGISTER_TYPE_* */
int type;
struct brw_reg fixed_hw_reg;
/** Value for file == BRW_IMMMEDIATE_FILE */
union {
int32_t i;
uint32_t u;
float f;
} imm;
};
class src_reg : public reg
{
public:
i965, mesa: Use the new DECLARE_R[Z]ALLOC_CXX_OPERATORS macros. These classes declared a placement new operator, but didn't declare a delete operator. Switching to the macro gives them a delete operator, which probably is a good idea anyway. This also eliminates a lot of boilerplate. v2: Properly use RZALLOC in Mesa IR/TGSI translators. Caught by Eric and Chad. Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Eric Anholt <eric@anholt.net> Reviewed-by: Chad Versace <chad.versace@linux.intel.com> Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
2013-09-18 14:11:32 -07:00
DECLARE_RALLOC_CXX_OPERATORS(src_reg)
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: Move class functions to brw_vec4.cpp. This has less impact than for the FS (4k savings), because it was partially done already, but makes things more consistent. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2012-07-04 13:25:27 -07:00
void init();
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: Move class functions to brw_vec4.cpp. This has less impact than for the FS (4k savings), because it was partially done already, but makes things more consistent. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2012-07-04 13:25:27 -07:00
src_reg(register_file file, int reg, const glsl_type *type);
src_reg();
src_reg(float f);
src_reg(uint32_t u);
src_reg(int32_t i);
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 constant propagation to a few opcodes. This differs from the FS in that we track constants in each destination channel, and we we have to look at all the swizzled source channels. Also, the instruction stream walk is done in an O(n) manner instead of O(n^2). Across shader-db, this reduces 8.0% of the instructions from 60.0% of the vertex shaders, leaving us now behind the old backend by 11.1% overall.
2011-08-30 13:25:15 -07:00
bool equals(src_reg *r);
i965/vs: Add support for simple algebraic optimizations. We generate silly code for array access, and it's easier to generally support the cleanup than to specifically avoid the bad code in each place we might generate it. Removes 4.6% of instructions from 41.6% of shaders in shader-db, particularly savage2/hon and unigine. v2: Fixes by Ken: Make is_zero/one member functions, and fix a progress flag. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2011-09-02 15:18:29 -07:00
bool is_zero() const;
bool is_one() const;
i965/vs: Add constant propagation to a few opcodes. This differs from the FS in that we track constants in each destination channel, and we we have to look at all the swizzled source channels. Also, the instruction stream walk is done in an O(n) manner instead of O(n^2). Across shader-db, this reduces 8.0% of the instructions from 60.0% of the vertex shaders, leaving us now behind the old backend by 11.1% overall.
2011-08-30 13:25:15 -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
src_reg(class vec4_visitor *v, const struct glsl_type *type);
explicit src_reg(dst_reg reg);
GLuint swizzle; /**< SWIZZLE_XYZW swizzles from Mesa. */
bool negate;
bool abs;
i965/vs: Track the variable index of array accesses. This isn't used currently, as we lower all array accesses.
2011-08-07 10:59:39 -07:00
src_reg *reladdr;
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
};
class dst_reg : public reg
{
public:
i965, mesa: Use the new DECLARE_R[Z]ALLOC_CXX_OPERATORS macros. These classes declared a placement new operator, but didn't declare a delete operator. Switching to the macro gives them a delete operator, which probably is a good idea anyway. This also eliminates a lot of boilerplate. v2: Properly use RZALLOC in Mesa IR/TGSI translators. Caught by Eric and Chad. Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Eric Anholt <eric@anholt.net> Reviewed-by: Chad Versace <chad.versace@linux.intel.com> Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
2013-09-18 14:11:32 -07:00
DECLARE_RALLOC_CXX_OPERATORS(dst_reg)
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: Move class functions to brw_vec4.cpp. This has less impact than for the FS (4k savings), because it was partially done already, but makes things more consistent. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2012-07-04 13:25:27 -07:00
void init();
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: Move class functions to brw_vec4.cpp. This has less impact than for the FS (4k savings), because it was partially done already, but makes things more consistent. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2012-07-04 13:25:27 -07:00
dst_reg();
dst_reg(register_file file, int reg);
dst_reg(register_file file, int reg, const glsl_type *type, int writemask);
dst_reg(struct brw_reg reg);
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
dst_reg(class vec4_visitor *v, const struct glsl_type *type);
explicit dst_reg(src_reg reg);
int writemask; /**< Bitfield of WRITEMASK_[XYZW] */
i965/vs: Track the variable index of array accesses. This isn't used currently, as we lower all array accesses.
2011-08-07 10:59:39 -07:00
src_reg *reladdr;
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/vec4: Make with_writemask() non-static. This will allow it to be shared between brw_vec4_visitor.cpp and brw_vec4_vs_visitor.cpp (which will be created in the next patch). Acked-by: Kenneth Graunke <kenneth@whitecape.org>
2013-08-31 20:51:48 -07:00
dst_reg
with_writemask(dst_reg const &r, int mask);
i965: Make the FS and VS share a few visitor/instruction fields. This will let us reuse brw_fs_cfg.cpp from brw_vec4_*. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2012-10-03 13:01:23 -07:00
class vec4_instruction : public backend_instruction {
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
public:
i965: Initialize all member variables of vec4_instruction on construction. The vec4_instruction object relies on the memory allocator zeroing out its contents before it's initialized, which is quite an unusual practice in the C++ world because it ties objects to some specific allocation scheme, and gives unpredictable results when an object is created with a different allocator -- Stack allocation, array allocation, or aggregation inside a different object are some of the useful possibilities that come to my mind. Initialize all fields from the constructor and stop using the zeroing allocator. Reviewed-by: Paul Berry <stereotype441@gmail.com> Reviewed-by: Chad Versace <chad.versace@linux.intel.com> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2013-09-11 16:20:18 -07:00
DECLARE_RALLOC_CXX_OPERATORS(vec4_instruction)
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: Restructure emit() functions around a vec4_instruction constructor. We sometimes want to put an instruction somewhere besides the end of the instruction stream, and we also want per-opcode instruction generation to enable compile-time checking of operands.
2011-08-26 16:37:37 -07:00
vec4_instruction(vec4_visitor *v, enum opcode opcode,
dst_reg dst = dst_reg(),
src_reg src0 = src_reg(),
src_reg src1 = src_reg(),
src_reg src2 = src_reg());
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
struct brw_reg get_dst(void);
i965/vec4: Allow for dispatch_grf_start_reg to vary. Both 3DSTATE_VS and 3DSTATE_GS have a dispatch_grf_start_reg control, which determines the register where the hardware delivers data sourced from the URB (push constants followed by per-vertex input data). For vertex shaders, we always set dispatch_grf_start_reg to 1, since R1 is always the first register available for push constants in vertex shaders. For geometry shaders, we'll need the flexibility to set dispatch_grf_start_reg to different values depending on the behvaiour of the geometry shader; if it accesses gl_PrimitiveIDIn, we'll need to set it to 2 to allow the primitive ID to be delivered to the thread in R1. This patch eliminates the assumption that dispatch_grf_start_reg is always 1. In vec4_visitor, we record the regnum that was passed to vec4_visitor::setup_uniforms() in prog_data for later use. In vec4_generator, we consult this value when converting an abstract UNIFORM register to a concrete hardware register. And in the code that emits 3DSTATE_VS, we set dispatch_grf_start_reg based on the value recorded in prog_data. This will allow us to set dispatch_grf_start_reg to the appropriate value when compiling geometry shaders. Vertex shaders will continue to always use a dispatch_grf_start_reg of 1. v2: Make dispatch_grf_start_reg "unsigned" rather than "GLuint". Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Matt Turner <mattst88@gmail.com>
2013-07-13 07:09:54 -07:00
struct brw_reg get_src(const struct brw_vec4_prog_data *prog_data, int i);
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
dst_reg dst;
src_reg src[3];
bool 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
bool force_writemask_all;
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
bool no_dd_clear, no_dd_check;
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
int conditional_mod; /**< BRW_CONDITIONAL_* */
int sampler;
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
uint32_t texture_offset; /**< Texture Offset bitfield */
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
int target; /**< MRT target. */
bool shadow_compare;
i965: Allow C++ type safety in the use of enum brw_urb_write_flags. (From a suggestion by Francisco Jerez) If an enum represents a bitfield of flags, e.g.: enum E { A = 1, B = 2, C = 4, D = 8, }; then C++ normally prohibits statements like this: enum E x = A | B; because A and B are implicitly converted to ints before OR-ing them, and an int can't be stored in an enum without a type cast. C, on the other hand, allows an int to be implicitly converted to an enum without casting. In the past we've dealt with this situation by storing flag bitfields as ints. This avoids ugly casting at the expense of some type safety that C++ would normally have offered (e.g. we get no warning if we accidentally use the wrong enum type). However, we can get the best of both worlds if we override the | operator. The ugly casting is confined to the operator overload, and we still get the benefit of C++ making sure we don't use the wrong enum type. v2: Remove unnecessary comment and unnecessary use of "enum" keyword. Use static_cast. Reviewed-by: Chad Versace <chad.versace@linux.intel.com> Reviewed-by: Francisco Jerez <currojerez@riseup.net>
2013-08-23 13:19:19 -07:00
enum brw_urb_write_flags urb_write_flags;
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
bool header_present;
int mlen; /**< SEND message length */
int base_mrf; /**< First MRF in the SEND message, if mlen is nonzero. */
uint32_t offset; /* spill/unspill offset */
/** @{
* Annotation for the generated IR. One of the two can be set.
*/
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 *ir;
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 *annotation;
i965/vs: Add support for copy propagation of the UNIFORM and ATTR files. Removes 2.0% of the instructions from 35.7% of vertex shaders in shader-db.
2011-09-01 16:21:14 -07:00
i965/vs: Prepare split_virtual_grfs() for the presence of SENDs from GRFs. v2: Fix silly bool handling, and don't add new tabs. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2012-12-17 16:48:20 -08:00
bool is_send_from_grf();
i965/vs: Extend opt_compute_to_mrf to handle limited "reswizzling" The way our visitor works, scalar expression/swizzle results that get stored in channels other than .x will have an intermediate MOV from their result in the .x channel to the real .y (or whatever) channel, and similarly for vec2/vec3 results. By knowing how to adjust DP4-type instructions for optimizing out a swizzled MOV, we can reduce instructions in common matrix multiplication cases. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2012-11-30 22:29:26 -08:00
bool can_reswizzle_dst(int dst_writemask, int swizzle, int swizzle_mask);
void reswizzle_dst(int dst_writemask, int swizzle);
i965/vs: add vec4_instruction::depends_on_flags We're about to have an instruction that depends on the flags but isn't predicated. This lays the groundwork. Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>
2013-08-16 06:54:30 +12:00
bool depends_on_flags()
{
i965: add new VS_OPCODE_UNPACK_FLAGS_SIMD4X2 Splits the bottom 8 bits of f0.0 for further wrangling in a SIMD4x2 program. The 4 bits corresponding to the channels in each program flow are copied to the LSBs of dst.x visible to each flow. This is useful for working with clipping flags in the VS. V3: - Fixup immediate types - Teach scheduler about the hidden dep on flags Signed-off-by: Chris Forbes <chrisf@ijw.co.nz> V2: Reviewed-by: Paul Berry <stereotype441@gmail.com>
2013-08-08 06:31:33 +12:00
return predicate || opcode == VS_OPCODE_UNPACK_FLAGS_SIMD4X2;
i965/vs: add vec4_instruction::depends_on_flags We're about to have an instruction that depends on the flags but isn't predicated. This lays the groundwork. Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>
2013-08-16 06:54:30 +12: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
/**
* The vertex shader front-end.
*
* Translates either GLSL IR or Mesa IR (for ARB_vertex_program and
* fixed-function) into VS IR.
*/
i965: Make the FS and VS share a few visitor/instruction fields. This will let us reuse brw_fs_cfg.cpp from brw_vec4_*. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2012-10-03 13:01:23 -07:00
class vec4_visitor : public backend_visitor
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
{
public:
i965/vs: Pass the brw_context pointer into vec4_visitor and do_vs_prog. We used to steal it out of the brw_compile struct...but vec4_visitor isn't going to have one of those in the future. Reviewed-by: Eric Anholt <eric@anholt.net> Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
2012-11-26 22:14:27 -08:00
vec4_visitor(struct brw_context *brw,
i965/vs: move VS-specific data members to vs_vec4_visitor. This patch moves the following data structures from vec4_visitor to vec4_vs_visitor, since they contain VS-specific data: - struct brw_vs_compile *c (renamed to vs_compile) - struct brw_vs_prog_data *prog_data (renamed to vs_prog_data) - src_reg *vp_temp_regs - src_reg vp_addr_reg Since brw_vs_compile and brw_vs_prog_data also contain vec4-generic data, the following pointers are added to the base class, to allow it to access the vec4-generic portions of these data structures: - struct brw_vec4_compile *c - struct brw_vec4_prog_key *key - struct brw_vec4_prog_data *prog_data Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Eric Anholt <eric@anholt.net> v2: Use shorter names in the base class and longer names in the derived class. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2013-02-17 09:09:45 -08:00
struct brw_vec4_compile *c,
struct gl_program *prog,
const struct brw_vec4_prog_key *key,
struct brw_vec4_prog_data *prog_data,
i965: Rename backend_visitor::prog to shader_prog. The next patch is going to change the type of vec4_visitor::vp from struct gl_vertex_program * to struct gl_program *, and rename it. The sensible name to change it to is vec4_visitor::prog. However, prog is already used in backend_visitor (which vec4_visitor derives from). Since backend_visitor::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-08 17:17:44 -07:00
struct gl_shader_program *shader_prog,
i965/vs: Rework memory contexts for shader compilation data. During compilation, we allocate a bunch of things: the IR needs to last at least until code generation...and then the program store needs to last until after we upload the program. For simplicity's sake, just keep it all around until we upload the program. After that, it can all be freed. This will also save a lot of headaches during the upcoming refactoring. Reviewed-by: Eric Anholt <eric@anholt.net> Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
2012-11-26 23:52:20 -08:00
struct brw_shader *shader,
i965/vs: Don't hardcode DEBUG_VS in generic vec4 code. Since the vec4_visitor and vec4_generator classes are going to be re-used for geometry shaders, we can't enable their debug functionality based on (INTEL_DEBUG & DEBUG_VS) anymore. Instead, add a debug_flag boolean to these two classes, so that when they're instantiated the caller can specify whether debug dumps are needed. Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Eric Anholt <eric@anholt.net> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2013-03-22 21:55:03 -07:00
void *mem_ctx,
i965/vec4: Add the ability to suppress register spilling. In future patches, this will allow us to first try compiling a geometry shader in DUAL_OBJECT mode (which is more efficient but uses more registers) and then if spilling is required, fall back on DUAL_INSTANCED mode. Reviewed-by: Eric Anholt <eric@anholt.net>
2013-10-16 12:13:20 -07:00
bool debug_flag,
bool no_spills);
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_visitor();
dst_reg dst_null_f()
{
return dst_reg(brw_null_reg());
}
dst_reg dst_null_d()
{
return dst_reg(retype(brw_null_reg(), BRW_REGISTER_TYPE_D));
}
i965: Add UD null register helpers. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2013-09-19 13:02:23 -07:00
dst_reg dst_null_ud()
{
return dst_reg(retype(brw_null_reg(), BRW_REGISTER_TYPE_UD));
}
i965/vs: move VS-specific data members to vs_vec4_visitor. This patch moves the following data structures from vec4_visitor to vec4_vs_visitor, since they contain VS-specific data: - struct brw_vs_compile *c (renamed to vs_compile) - struct brw_vs_prog_data *prog_data (renamed to vs_prog_data) - src_reg *vp_temp_regs - src_reg vp_addr_reg Since brw_vs_compile and brw_vs_prog_data also contain vec4-generic data, the following pointers are added to the base class, to allow it to access the vec4-generic portions of these data structures: - struct brw_vec4_compile *c - struct brw_vec4_prog_key *key - struct brw_vec4_prog_data *prog_data Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Eric Anholt <eric@anholt.net> v2: Use shorter names in the base class and longer names in the derived class. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2013-02-17 09:09:45 -08:00
struct brw_vec4_compile *c;
const struct brw_vec4_prog_key *key;
struct brw_vec4_prog_data *prog_data;
i965: Add asserts to check that we don't realloc ParameterValues. Things are even more restrictive than they used to be, so I've made mistakes in this area. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2012-11-21 13:11:32 -08:00
unsigned int sanity_param_count;
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
char *fail_msg;
bool failed;
/**
* GLSL IR currently being processed, which is associated with our
* driver IR instructions for debugging purposes.
*/
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 *base_ir;
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 *current_annotation;
int *virtual_grf_sizes;
int virtual_grf_count;
int virtual_grf_array_size;
int first_non_payload_grf;
i965/vs: Avoid allocating registers in to the gen7 MRF hack region. This is the corresponding fix to the previous one for the FS, but I don't have a particular test for it. NOTE: This is a candidate for the 8.0 branch.
2012-01-27 12:59:24 -08:00
unsigned int max_grf;
i965/vs: Make virtual grf live intervals actually cover their used range. This is the same change as the previous commit to the FS. A very few VSes are regressed by 1 or 2 instructions, which look recoverable with a bit more dead code elimination. Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
2013-04-30 15:15:21 -07:00
int *virtual_grf_start;
int *virtual_grf_end;
i965 new VS: don't share clip plane constants in pre-GEN6 In pre-GEN6, when using clip planes, both the vertex shader and the clipper need access to the client-supplied clip planes, since the vertex shader needs them to set the clip flags, and the clipper needs them to determine where to insert new vertices. With the old VS backend, we used a clever optimization to avoid placing duplicate copies of these planes in the CURBE: we used the same block of memory for both the clipper and vertex shader constants, with the clip planes at the front of it, and then we instructed the clipper to read just the initial part of this block containing the clip planes. This optimization was tricky, of dubious value, and not completely working in the new VS backend, so I've removed it. Now, when using the new VS backend, separate parts of the CURBE are used for the clipper and the vertex shader. Note that this doesn't affect the number of push constants available to the vertex shader, it simply causes the CURBE to occupy a few more bytes of URB memory. The old VS backend is unaffected. GEN6+, which does clipping entirely in hardware, is also unaffected. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2011-09-23 21:33:50 -07:00
dst_reg userplane[MAX_CLIP_PLANES];
i965/vs: Keep track of indices into a per-register array for virtual GRFs. Tracking virtual GRFs has tension between using a packed array per virtual GRF (which is good for register allocation), and sparse arrays where there's an element per actual register (so the first and second column of a mat2 can be distinguished inside of an optimization pass). The FS mostly avoided the need for this second sparse array by doing virtual GRF splitting, but that meant that instances where virtual GRF splitting didn't work, instructions using those registers got much less optimized.
2011-09-01 08:34:18 -07:00
/**
* This is the size to be used for an array with an element per
* reg_offset
*/
int virtual_grf_reg_count;
/** Per-virtual-grf indices into an array of size virtual_grf_reg_count */
int *virtual_grf_reg_map;
i965/vs: Copy the live intervals calculation over from the FS. This is a rather pessimistic calculation, since it doesn't distinguish individual channels of a vec4, or elements of an array, but should be a minimum start for register allocation.
2011-08-16 15:09:48 -07:00
bool live_intervals_valid;
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
dst_reg *variable_storage(ir_variable *var);
void reladdr_to_temp(ir_instruction *ir, src_reg *reg, int *num_reladdr);
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
bool need_all_constants_in_pull_buffer;
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
/**
* \name Visit methods
*
* As typical for the visitor pattern, there must be one \c visit method for
* each concrete subclass of \c ir_instruction. Virtual base classes within
* the hierarchy should not have \c visit methods.
*/
/*@{*/
virtual void visit(ir_variable *);
virtual void visit(ir_loop *);
virtual void visit(ir_loop_jump *);
virtual void visit(ir_function_signature *);
virtual void visit(ir_function *);
virtual void visit(ir_expression *);
virtual void visit(ir_swizzle *);
virtual void visit(ir_dereference_variable *);
virtual void visit(ir_dereference_array *);
virtual void visit(ir_dereference_record *);
virtual void visit(ir_assignment *);
virtual void visit(ir_constant *);
virtual void visit(ir_call *);
virtual void visit(ir_return *);
virtual void visit(ir_discard *);
virtual void visit(ir_texture *);
virtual void visit(ir_if *);
glsl: add ir_emit_vertex and ir_end_primitive instruction types These correspond to the EmitVertex and EndPrimitive functions in GLSL. v2 (Paul Berry <stereotype441@gmail.com>): Add stub implementations of new pure visitor functions to i965's vec4_visitor and fs_visitor classes. v3 (Paul Berry <stereotype441@gmail.com>): Rename classes to be more consistent with the names used in the GL spec. Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2013-02-15 09:26:35 -06:00
virtual void visit(ir_emit_vertex *);
virtual void visit(ir_end_primitive *);
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
/*@}*/
src_reg result;
/* Regs for vertex results. Generated at ir_variable visiting time
* for the ir->location's used.
*/
i965: Rename BRW_VARYING_SLOT_MAX -> BRW_VARYING_SLOT_COUNT. The new name clarifies that it represents *one more* than the maximum possible brw_varying_slot value. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2013-03-23 15:53:33 -07:00
dst_reg output_reg[BRW_VARYING_SLOT_COUNT];
const char *output_reg_annotation[BRW_VARYING_SLOT_COUNT];
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
int uniform_size[MAX_UNIFORMS];
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
int uniform_vector_size[MAX_UNIFORMS];
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
int uniforms;
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: 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
src_reg shader_start_time;
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
struct hash_table *variable_ht;
bool run(void);
void fail(const char *msg, ...);
int virtual_grf_alloc(int size);
i965 new VS: don't share clip plane constants in pre-GEN6 In pre-GEN6, when using clip planes, both the vertex shader and the clipper need access to the client-supplied clip planes, since the vertex shader needs them to set the clip flags, and the clipper needs them to determine where to insert new vertices. With the old VS backend, we used a clever optimization to avoid placing duplicate copies of these planes in the CURBE: we used the same block of memory for both the clipper and vertex shader constants, with the clip planes at the front of it, and then we instructed the clipper to read just the initial part of this block containing the clip planes. This optimization was tricky, of dubious value, and not completely working in the new VS backend, so I've removed it. Now, when using the new VS backend, separate parts of the CURBE are used for the clipper and the vertex shader. Note that this doesn't affect the number of push constants available to the vertex shader, it simply causes the CURBE to occupy a few more bytes of URB memory. The old VS backend is unaffected. GEN6+, which does clipping entirely in hardware, is also unaffected. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2011-09-23 21:33:50 -07:00
void setup_uniform_clipplane_values();
i965/vs: Reference the core GL uniform storage for non-builtin uniforms. Like in the FS, there's no reason to use an external copy if the ParameterValues[] relayout of it isn't the layout we need. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2012-11-20 19:18:45 -08:00
void setup_uniform_values(ir_variable *ir);
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
void setup_builtin_uniform_values(ir_variable *ir);
int setup_uniforms(int payload_reg);
i965/vs: Try again when we've successfully spilled a reg. Before, we'd spill one reg, then continue on without actually register allocating, then assertion fail when we tried to use a vgrf number as a register number. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2012-10-03 10:03:22 -07:00
bool reg_allocate_trivial();
bool reg_allocate();
i965/vs: Implement register spilling. To validate this code, I ran piglit -t vs quick.tests with the "go spill everything" debugging code enabled. There was only one regression: glsl-vs-unroll-explosion simply ran out of registers. This should be fine in the real world, since no one actually spills every single register. NOTE: This is a candidate for the 9.0 branch. Even if it proves to have bugs, it's likely better than simply failing to compile. Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Eric Anholt <eric@anholt.net>
2012-10-01 15:28:56 -07:00
void evaluate_spill_costs(float *spill_costs, bool *no_spill);
int choose_spill_reg(struct ra_graph *g);
void spill_reg(int spill_reg);
i965/vs: Move virtual GRFs with array accesses to them to scratch space.
2011-08-07 12:15:26 -07:00
void move_grf_array_access_to_scratch();
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 move_uniform_array_access_to_pull_constants();
i965/vs: Add support for overflowing the number of available push constants. Fixes glsl-vs-uniform-array-4. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=33742 Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Acked-by: Kenneth Graunke <kenneth@whitecape.org>
2011-09-06 22:32:33 -07:00
void move_push_constants_to_pull_constants();
i965/vs: Track uniforms as separate vectors once we've done array access. This will make it easier to figure out which elements are totally unused and not upload them. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2011-08-23 10:22:50 -07:00
void split_uniform_registers();
i965/vs: Pack live uniform vectors together in the push constant upload. At some point we need to also move uniform accesses out to pull constants when there are just too many in use, but we lack tests for that at the moment. Fixes glsl-vs-large-uniform-array. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2011-08-23 12:13:14 -07:00
void pack_uniform_registers();
i965/vs: Copy the live intervals calculation over from the FS. This is a rather pessimistic calculation, since it doesn't distinguish individual channels of a vec4, or elements of an array, but should be a minimum start for register allocation.
2011-08-16 15:09:48 -07:00
void calculate_live_intervals();
i965/vec4: Add invalidate_live_intervals method. Reviewed-by: Paul Berry <stereotype441@gmail.com> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2013-11-11 10:33:46 -08:00
void invalidate_live_intervals();
i965/vs: Add support for splitting virtual GRFs. This should improve our ability to register allocate without spilling. Unfortuantely, due to the live variable analysis being ignorant of loops, we still have register allocation failures on some programs. v2: Add more context to the comment explaining the function. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> (v1)
2012-10-03 10:04:22 -07:00
void split_virtual_grfs();
i965/vs: Add simple dead code elimination. This is copied right from the fragment shader. It is needed for real register allocation to work correctly.
2011-08-17 10:50:17 -07:00
bool dead_code_eliminate();
i965/vs: Copy the live intervals calculation over from the FS. This is a rather pessimistic calculation, since it doesn't distinguish individual channels of a vec4, or elements of an array, but should be a minimum start for register allocation.
2011-08-16 15:09:48 -07:00
bool virtual_grf_interferes(int a, int b);
i965/vs: Add constant propagation to a few opcodes. This differs from the FS in that we track constants in each destination channel, and we we have to look at all the swizzled source channels. Also, the instruction stream walk is done in an O(n) manner instead of O(n^2). Across shader-db, this reduces 8.0% of the instructions from 60.0% of the vertex shaders, leaving us now behind the old backend by 11.1% overall.
2011-08-30 13:25:15 -07:00
bool opt_copy_propagation();
i965/vs: Add support for simple algebraic optimizations. We generate silly code for array access, and it's easier to generally support the cleanup than to specifically avoid the bad code in each place we might generate it. Removes 4.6% of instructions from 41.6% of shaders in shader-db, particularly savage2/hon and unigine. v2: Fixes by Ken: Make is_zero/one member functions, and fix a progress flag. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2011-09-02 15:18:29 -07:00
bool opt_algebraic();
i965: Generalize VS compute-to-MRF for compute-to-another-GRF, too. No statistically significant performance difference on glbenchmark 2.7 (n=60). It reduces cycles spent in the vertex shader by 3.3% +/- 0.8% (n=5), but that's only about .3% of all cycles spent according to the fixed shader_time. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2012-08-01 19:35:18 -07:00
bool opt_register_coalesce();
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
void opt_set_dependency_control();
i965/vs: Add instruction scheduling. While this is ignorant of dependency control, it's still good for a 0.39% +/- 0.08% performance improvement on GLBenchmark 2.7 (n=548) v2: Rewrite as a subclass of the base class for the FS instruction scheduler, inheriting the same latency information. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Matt Turner <mattst88@gmail.com>
2012-11-30 16:13:34 -08:00
void opt_schedule_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/vs: Teach copy propagation about sends from GRFs. This incidentally also teaches it a bit about gen6 math -- we now allow unswizzled, unmodified GRF temps as the sources for math. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2012-12-17 17:03:02 -08:00
bool can_do_source_mods(vec4_instruction *inst);
i965/vs: Restructure emit() functions around a vec4_instruction constructor. We sometimes want to put an instruction somewhere besides the end of the instruction stream, and we also want per-opcode instruction generation to enable compile-time checking of operands.
2011-08-26 16:37:37 -07:00
vec4_instruction *emit(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
vec4_instruction *emit(enum opcode opcode);
i965/vec4: Add the ability to emit opcodes with just a dst register. This is needed for GS_OPCODE_PREPARE_CHANNEL_MASKS. Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2013-04-21 08:51:33 -07:00
vec4_instruction *emit(enum opcode opcode, dst_reg dst);
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 *emit(enum opcode opcode, dst_reg dst, src_reg src0);
vec4_instruction *emit(enum opcode opcode, dst_reg dst,
src_reg src0, src_reg src1);
vec4_instruction *emit(enum opcode opcode, dst_reg dst,
src_reg src0, src_reg src1, src_reg src2);
i965/vs: Avoid the emit(), remove(), insert_before() for array instructions. v2: Add generator instructions for the scratch opcodes. Add emit_before() for handling ->ir and ->annotation inheritance. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2011-08-27 11:13:33 -07:00
vec4_instruction *emit_before(vec4_instruction *inst,
vec4_instruction *new_inst);
i965/vs: Create instruction generators outside of the emit() functions. v2: Fixed gen6 IF(). Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2011-08-26 16:43:06 -07:00
vec4_instruction *MOV(dst_reg dst, src_reg src0);
vec4_instruction *NOT(dst_reg dst, src_reg src0);
vec4_instruction *RNDD(dst_reg dst, src_reg src0);
vec4_instruction *RNDE(dst_reg dst, src_reg src0);
vec4_instruction *RNDZ(dst_reg dst, src_reg src0);
vec4_instruction *FRC(dst_reg dst, src_reg src0);
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
vec4_instruction *F32TO16(dst_reg dst, src_reg src0);
vec4_instruction *F16TO32(dst_reg dst, src_reg src0);
i965/vs: Create instruction generators outside of the emit() functions. v2: Fixed gen6 IF(). Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2011-08-26 16:43:06 -07:00
vec4_instruction *ADD(dst_reg dst, src_reg src0, src_reg src1);
vec4_instruction *MUL(dst_reg dst, src_reg src0, src_reg src1);
vec4_instruction *MACH(dst_reg dst, src_reg src0, src_reg src1);
vec4_instruction *MAC(dst_reg dst, src_reg src0, src_reg src1);
vec4_instruction *AND(dst_reg dst, src_reg src0, src_reg src1);
vec4_instruction *OR(dst_reg dst, src_reg src0, src_reg src1);
vec4_instruction *XOR(dst_reg dst, src_reg src0, src_reg src1);
vec4_instruction *DP3(dst_reg dst, src_reg src0, src_reg src1);
vec4_instruction *DP4(dst_reg dst, src_reg src0, src_reg src1);
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
vec4_instruction *DPH(dst_reg dst, src_reg src0, src_reg src1);
i965/vs: add support for emitting SHL, SHR, ASR Signed-off-by: Chris Forbes <chrisf@ijw.co.nz> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2012-11-22 16:23:23 +13:00
vec4_instruction *SHL(dst_reg dst, src_reg src0, src_reg src1);
vec4_instruction *SHR(dst_reg dst, src_reg src0, src_reg src1);
vec4_instruction *ASR(dst_reg dst, src_reg src0, src_reg src1);
i965/vs: Create instruction generators outside of the emit() functions. v2: Fixed gen6 IF(). Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2011-08-26 16:43:06 -07:00
vec4_instruction *CMP(dst_reg dst, src_reg src0, src_reg src1,
uint32_t condition);
vec4_instruction *IF(src_reg src0, src_reg src1, uint32_t condition);
vec4_instruction *IF(uint32_t predicate);
i965/vs: Avoid the emit(), remove(), insert_before() for array instructions. v2: Add generator instructions for the scratch opcodes. Add emit_before() for handling ->ir and ->annotation inheritance. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2011-08-27 11:13:33 -07:00
vec4_instruction *PULL_CONSTANT_LOAD(dst_reg dst, src_reg index);
vec4_instruction *SCRATCH_READ(dst_reg dst, src_reg index);
vec4_instruction *SCRATCH_WRITE(dst_reg dst, src_reg src, src_reg index);
i965/vs: Add support for LRP instruction. Only 13 affected programs in shader-db, but they were all helped. total instructions in shared programs: 368877 -> 368851 (-0.01%) instructions in affected programs: 1576 -> 1550 (-1.65%) Reviewed-by: Chris Forbes <chrisf@ijw.co.nz> Reviewed-by: Eric Anholt <eric@anholt.net>
2013-04-25 11:03:38 -07:00
vec4_instruction *LRP(dst_reg dst, src_reg a, src_reg y, src_reg x);
i965/vs: Add support for bit instructions. v2: Rebase on LRP addition. Use fix_3src_operand() when emitting BFE and BFI2. Add BFE and BFI2 to is_3src_inst check in brw_vec4_copy_propagation.cpp. Subtract result of FBH from 31 (unless an error) to convert MSB counts to LSB counts Reviewed-by: Chris Forbes <chrisf@ijw.co.nz>
2013-04-17 18:57:58 -07:00
vec4_instruction *BFREV(dst_reg dst, src_reg value);
vec4_instruction *BFE(dst_reg dst, src_reg bits, src_reg offset, src_reg value);
vec4_instruction *BFI1(dst_reg dst, src_reg bits, src_reg offset);
vec4_instruction *BFI2(dst_reg dst, src_reg bfi1_dst, src_reg insert, src_reg base);
vec4_instruction *FBH(dst_reg dst, src_reg value);
vec4_instruction *FBL(dst_reg dst, src_reg value);
vec4_instruction *CBIT(dst_reg dst, src_reg value);
i965/vs: Add support for translating ir_triop_fma into MAD. Reviewed-by: Paul Berry <stereotype441@gmail.com> Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
2013-08-02 10:28:16 -07:00
vec4_instruction *MAD(dst_reg dst, src_reg c, src_reg b, src_reg a);
i965: Generate code for ir_binop_carry and ir_binop_borrow. Using the ADDC and SUBB instructions on Gen7. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2013-09-19 13:01:08 -07:00
vec4_instruction *ADDC(dst_reg dst, src_reg src0, src_reg src1);
vec4_instruction *SUBB(dst_reg dst, src_reg src0, src_reg src1);
i965/vs: Create instruction generators outside of the emit() functions. v2: Fixed gen6 IF(). Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2011-08-26 16:43:06 -07:00
i965/vs: Add a function for how many MRFs get written as part of a SEND. This will be used for compute-to-mrf, which needs to know when MRFs get overwritten.
2011-09-06 12:26:42 -07:00
int implied_mrf_writes(vec4_instruction *inst);
i965/vs: Avoid generating a MOV for most ir_assignment handling. Removes an average of 11.5% of instructions in 54% of vertex shaders in shader-db.
2011-08-11 08:09:10 -07:00
bool try_rewrite_rhs_to_dst(ir_assignment *ir,
dst_reg dst,
src_reg src,
vec4_instruction *pre_rhs_inst,
vec4_instruction *last_rhs_inst);
i965: Remove pointless intel_context parameter from try_copy_propagate. It's already part of the visitor class. Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Acked-by: Chris Forbes <chrisf@ijw.co.nz> Acked-by: Paul Berry <stereotype441@gmail.com> Acked-by: Anuj Phogat <anuj.phogat@gmail.com>
2013-07-03 00:49:28 -07:00
bool try_copy_propagation(vec4_instruction *inst, int arg,
i965/vs: Teach copy propagation about sends from GRFs. This incidentally also teaches it a bit about gen6 math -- we now allow unswizzled, unmodified GRF temps as the sources for math. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2012-12-17 17:03:02 -08:00
src_reg *values[4]);
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
/** Walks an exec_list of ir_instruction and sends it through this visitor. */
void visit_instructions(const exec_list *list);
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
void emit_vp_sop(uint32_t condmod, dst_reg dst,
src_reg src0, src_reg src1, src_reg one);
i965/vs: Add support for vector comparison ops resulting in bool cond codes. Fixes a giant pile of VS tests on gen4. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2011-08-30 16:23:44 -07:00
void emit_bool_to_cond_code(ir_rvalue *ir, uint32_t *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
void emit_bool_comparison(unsigned int op, dst_reg dst, src_reg src0, src_reg src1);
void emit_if_gen6(ir_if *ir);
i965/vs: Refactor min/max handling to share code. v2: Properly use "conditionalmod" pre-Gen6, rather than the incorrectly copy-and-pasted "BRW_CONDITIONAL_G". Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Eric Anholt <eric@anholt.net>
2012-10-08 10:45:08 -07:00
void emit_minmax(uint32_t condmod, dst_reg dst, src_reg src0, src_reg src1);
i965/vs: Handle assignment of structures/arrays/matrices better. This gets the right types on the instructions, as well as emitting minimal swizzles/writemasks.
2011-08-05 20:46:03 -07:00
void emit_block_move(dst_reg *dst, src_reg *src,
i965/vs: Add support for vector comparison ops resulting in bool cond codes. Fixes a giant pile of VS tests on gen4. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2011-08-30 16:23:44 -07:00
const struct glsl_type *type, uint32_t 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
i965/vs: Avoid generating extra moves when setting up large ir_constants. We were also screwing up the types in the process, and just not emitting moves was easier.
2011-08-05 21:22:36 -07:00
void emit_constant_values(dst_reg *dst, ir_constant *value);
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
/**
* Emit the correct dot-product instruction for the type of arguments
*/
void emit_dp(dst_reg dst, src_reg src0, src_reg src1, unsigned elements);
void emit_scalar(ir_instruction *ir, enum prog_opcode op,
dst_reg dst, src_reg src0);
void emit_scalar(ir_instruction *ir, enum prog_opcode op,
dst_reg dst, src_reg src0, src_reg src1);
void emit_scs(ir_instruction *ir, enum prog_opcode op,
dst_reg dst, const src_reg &src);
i965/vs: Add a function to fix-up uniform arguments for 3-src insts. Three-source instructions have a vertical stride overloaded to 4, which prevents directly using vec4 uniforms as arguments. Instead we need to insert a MOV instruction to do the replication for the three-source instruction. With this in place, we can use three-source instructions in the vertex shader. While some thought needs to go into deciding whether its better to use a three-source instruction rather than a sequence of equivalent instructions (when one or more sources are uniforms or immediates), this will allow us to skip a lot of ugly lowering code and use the BFE and BFI2 instructions directly. Reviewed-by: Chris Forbes <chrisf@ijw.co.nz> Reviewed-by: Eric Anholt <eric@anholt.net>
2013-04-25 11:02:02 -07:00
src_reg fix_3src_operand(src_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
void emit_math1_gen6(enum opcode opcode, dst_reg dst, src_reg src);
void emit_math1_gen4(enum opcode opcode, dst_reg dst, src_reg src);
void emit_math(enum opcode opcode, dst_reg dst, src_reg src);
void emit_math2_gen6(enum opcode opcode, dst_reg dst, src_reg src0, src_reg src1);
void emit_math2_gen4(enum opcode opcode, dst_reg dst, src_reg src0, src_reg src1);
void emit_math(enum opcode opcode, dst_reg dst, src_reg src0, src_reg src1);
i965/vs: Fix gen6+ math operand quirks in one place This causes immediate values to get moved to a temp on gen7, which is needed for an upcoming change but hadn't happened in the visitor until then. v2: Drop gen > 7 checks (doesn't exist), and style-fix comments (changes by anholt). Reviewed-by: Eric Anholt <eric@anholt.net> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2012-12-09 22:03:49 +13:00
src_reg fix_math_operand(src_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/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
void emit_pack_half_2x16(dst_reg dst, src_reg src0);
void emit_unpack_half_2x16(dst_reg dst, src_reg src0);
i965/vs: Add support for ir_tg4 Pretty much the same as the FS case. Channel select goes in the header, V2: Less mangling. V3: Avoid sampling at all, for degenerate swizzles. Signed-off-by: Chris Forbes <chrisf@ijw.co.nz> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2013-03-31 21:39:37 +13:00
uint32_t gather_channel(ir_texture *ir, int sampler);
i965/vs: Sample from MCS surface when required Signed-off-by: Chris Forbes <chrisf@ijw.co.nz> Reviewed-by: Paul Berry <stereotype441@gmail.com>
2013-11-30 13:49:50 +13:00
src_reg emit_mcs_fetch(ir_texture *ir, src_reg coordinate, int sampler);
i965/vs: Implement EXT_texture_swizzle support for VS texturing. Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
2011-12-07 03:20:53 -08:00
void swizzle_result(ir_texture *ir, src_reg orig_val, int sampler);
i965: new VS: move NDC computation (GEN4-5) to a separate function. Reviewed-by: Eric Anholt <eric@anholt.net>
2011-08-23 10:26:15 -07:00
void emit_ndc_computation();
i965: new VS: Move PSIZ/flags computation to a separate function. Reviewed-by: Eric Anholt <eric@anholt.net>
2011-08-23 10:29:48 -07:00
void emit_psiz_and_flags(struct brw_reg reg);
i965/vs: Do legacy clip lowering earlier We need to produce clip flags for the vertex header on Gen4/5, so clip plane lowering has to be done before we try to emit the flags/psiz attribute. Signed-off-by: Chris Forbes <chrisf@ijw.co.nz> Reviewed-by: Paul Berry <stereotype441@gmail.com>
2013-07-08 04:21:08 +12:00
void emit_clip_distances(dst_reg reg, int offset);
i965: Clarify nomenclature: vert_result -> varying This patch removes the terminology "vert_result" from the i965 driver, replacing it with "varying". The old terminology, "vert_result", was confusing because (a) it referred to the enum gl_vert_result, which no longer exists (it was replaced with gl_varying_slot), and (b) it implied a vertex output, but with the advent of geometry shaders, it could be either a vertex or a geometry output, depending what shaders are in use. The generic term "varying" is less confusing. No functional change. Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Reviewed-by: Eric Anholt <eric@anholt.net> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> v2: Whitespace fixes.
2013-03-22 09:39:11 -07:00
void emit_generic_urb_slot(dst_reg reg, int varying);
void emit_urb_slot(int mrf, int varying);
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: 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
void emit_shader_time_begin();
void emit_shader_time_end();
void emit_shader_time_write(enum shader_time_shader_type type,
i965: Adjust the split between shader_time_end() and shader_time_write(). I'm about to emit other kinds of writes besides time deltas, and it turns out with the frequency of resets, we couldn't really use the old time delta write() function more than once in a shader.
2012-12-10 09:21:34 -08:00
src_reg value);
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
i965/gen7: Handle atomic instructions from the VEC4 back-end. This can deal with all the 15 32-bit untyped atomic operations the hardware supports, but only INC and PREDEC are going to be exposed through the API for now. v2: Represent atomics as GLSL intrinsics. Add support for variably indexed atomic counter arrays. v3: Add comment on why we don't need to assign uniform storage for atomic counters. Reviewed-by: Paul Berry <stereotype441@gmail.com>
2013-09-25 16:31:35 -07:00
void emit_untyped_atomic(unsigned atomic_op, unsigned surf_index,
dst_reg dst, src_reg offset, src_reg src0,
src_reg src1);
void emit_untyped_surface_read(unsigned surf_index, dst_reg dst,
src_reg offset);
i965/vs: Move virtual GRFs with array accesses to them to scratch space.
2011-08-07 12:15:26 -07:00
src_reg get_scratch_offset(vec4_instruction *inst,
src_reg *reladdr, int 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
src_reg get_pull_constant_offset(vec4_instruction *inst,
src_reg *reladdr, int reg_offset);
i965/vs: Move virtual GRFs with array accesses to them to scratch space.
2011-08-07 12:15:26 -07:00
void emit_scratch_read(vec4_instruction *inst,
dst_reg dst,
src_reg orig_src,
int base_offset);
void emit_scratch_write(vec4_instruction *inst,
int base_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
void emit_pull_constant_load(vec4_instruction *inst,
dst_reg dst,
src_reg orig_src,
int base_offset);
i965/vs: Move virtual GRFs with array accesses to them to scratch space.
2011-08-07 12:15:26 -07:00
intel: Convert from GLboolean to 'bool' from stdbool.h. I initially produced the patch using this bash command: for file in {intel,i915,i965}/*.{c,cpp,h}; do [ ! -h $file ] && sed -i 's/GLboolean/bool/g' $file && sed -i 's/GL_TRUE/true/g' $file && sed -i 's/GL_FALSE/false/g' $file; done Then I manually added #include <stdbool.h> to fix compilation errors, and converted a few functions back to GLboolean that were used in core Mesa's function pointer table to avoid "incompatible pointer" warnings. Finally, I cleaned up some whitespace issues introduced by the change. Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Acked-by: Chad Versace <chad@chad-versace.us> Acked-by: Paul Berry <stereotype441@gmail.com>
2011-10-07 12:26:50 -07:00
bool try_emit_sat(ir_expression *ir);
i965/vs: Use the MAD instruction when possible. This is different from how we do it in the FS - we are using MAD even when some of the args are constants, because with the relatively unrestrained ability to schedule a MOV to prepare a temporary with that data, we can get lower latency for the sequence of instructions. No significant performance difference on GLB2.7 trex (n=33/34), though it doesn't have that many MADs. I noticed MAD opportunities while reading the code for the DOTA2 bug. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Matt Turner <mattst88@gmail.com>
2013-06-06 10:14:41 -07:00
bool try_emit_mad(ir_expression *ir, int mul_arg);
i965/vs: Fix comparisons with uint negation. The condmod instruction ends up generating garbage condition codes, because apparently the comparison happens on the accumulator value (33 bits for UD), not the truncated value that would be written. Fixes vs-op-neg-* Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
2011-10-03 15:31:52 -07:00
void resolve_ud_negate(src_reg *reg);
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: 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
src_reg get_timestamp();
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
bool process_move_condition(ir_rvalue *ir);
i965: Make dump_instructions be a virtual method of the visitor. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Matt Turner <mattst88@gmail.com>
2013-04-29 14:21:14 -07:00
void dump_instruction(backend_instruction *inst);
i965/vs: Make some vec4_visitor functions virtual. This patch makes the following vec4_visitor functions virtual, since they will need to be implemented differently for vertex and geometry shaders. Some of the functions are renamed to reflect their generic purpose, rather than their VS-specific behaviour: - setup_attributes - emit_attribute_fixups (renamed to emit_prolog) - emit_vertex_program_code (renamed to emit_program_code) - emit_urb_writes (renamed to emit_thread_end) 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 08:05:52 -08:00
i965/gen7: Handle atomic instructions from the VEC4 back-end. This can deal with all the 15 32-bit untyped atomic operations the hardware supports, but only INC and PREDEC are going to be exposed through the API for now. v2: Represent atomics as GLSL intrinsics. Add support for variably indexed atomic counter arrays. v3: Add comment on why we don't need to assign uniform storage for atomic counters. Reviewed-by: Paul Berry <stereotype441@gmail.com>
2013-09-25 16:31:35 -07:00
void visit_atomic_counter_intrinsic(ir_call *ir);
i965/vs: Make some vec4_visitor functions virtual. This patch makes the following vec4_visitor functions virtual, since they will need to be implemented differently for vertex and geometry shaders. Some of the functions are renamed to reflect their generic purpose, rather than their VS-specific behaviour: - setup_attributes - emit_attribute_fixups (renamed to emit_prolog) - emit_vertex_program_code (renamed to emit_program_code) - emit_urb_writes (renamed to emit_thread_end) 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 08:05:52 -08:00
protected:
i965/vs: Generalize vertex emission code in preparation for GS. This patch introduces a new function, vec4_visitor::emit_vertex(), which contains the code for emitting vertices that will need to be common between the vertex and geometry shaders. Geometry shaders will need to use a different message header, and a different opcode, for their URB writes, so we introduce virtual functions emit_urb_write_header() and emit_urb_write_opcode() to take care of the GS-specific behaviours. Also, since vertex emission happens at the end of the VS, but in the middle of the GS, we need to be sure to only call emit_shader_time_end() during VS vertex emission. We accomplish this by moving the call to emit_shader_time_end() into the VS implementation of emit_urb_write_opcode(). Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2013-03-22 06:59:52 -07:00
void emit_vertex();
i965/vec4: Add the ability for attributes to be interleaved. When geometry shaders are operated in "single" or "dual instanced" mode, a single set of geometry shader inputs is interleaved into the thread payload (with each payload register containing a pair of inputs) in order to save register space. This patch modifies vec4_visitor::lower_attributes_to_hw_regs so that it can handle the interleaved format. Reviewed-by: Eric Anholt <eric@anholt.net>
2013-10-16 11:40:41 -07:00
void lower_attributes_to_hw_regs(const int *attribute_map,
bool interleaved);
i965/vs: Expose the payload registers to the register allocator. For now, nothing else can get allocated over them. That may change at some point in the future. This also means that base_reg_count can be computed without knowing the number of registers used for the payload, which is required if we want to allocate the register set once at context creation time. See commit 551e1cd44f6857f7e29ea4c8f892da5a97844377, which implemented virtually identical code in the FS backend. Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Paul Berry <stereotype441@gmail.com>
2013-08-21 21:55:40 -07:00
void setup_payload_interference(struct ra_graph *g, int first_payload_node,
int reg_node_count);
i965/vs: Add virtual function make_reg_for_system_value(). The system values handled by vec4_visitor::visit(ir_variable *) are VS-specific (vertex ID and instance ID). This patch moves the handling of those values into a new virtual function, make_reg_for_system_value(), so that this VS-specific code won't be inherited by geomtry shaders. 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 08:05:52 -08:00
virtual dst_reg *make_reg_for_system_value(ir_variable *ir) = 0;
i965/vec4: Virtualize setup_payload instead of setup_attributes. When I initially generalized the vec4_visitor class in preparation for geometry shaders, I assumed that the setup_attributes() function would need to be different between vertex and geometry shaders, but its caller, setup_payload(), could be shared. So I made setup_attributes() a virtual function. It turns out this isn't true; setup_payload() needs to be different too, since the geometry shader payload sometimes includes an extra register (primitive ID) that has to come before uniforms. So setup_payload() needs to be the virtual function instead of setup_attributes(). Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Matt Turner <mattst88@gmail.com>
2013-07-13 09:03:18 -07:00
virtual void setup_payload() = 0;
i965/vs: Make some vec4_visitor functions virtual. This patch makes the following vec4_visitor functions virtual, since they will need to be implemented differently for vertex and geometry shaders. Some of the functions are renamed to reflect their generic purpose, rather than their VS-specific behaviour: - setup_attributes - emit_attribute_fixups (renamed to emit_prolog) - emit_vertex_program_code (renamed to emit_program_code) - emit_urb_writes (renamed to emit_thread_end) 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 08:05:52 -08:00
virtual void emit_prolog() = 0;
virtual void emit_program_code() = 0;
virtual void emit_thread_end() = 0;
i965/vs: Generalize vertex emission code in preparation for GS. This patch introduces a new function, vec4_visitor::emit_vertex(), which contains the code for emitting vertices that will need to be common between the vertex and geometry shaders. Geometry shaders will need to use a different message header, and a different opcode, for their URB writes, so we introduce virtual functions emit_urb_write_header() and emit_urb_write_opcode() to take care of the GS-specific behaviours. Also, since vertex emission happens at the end of the VS, but in the middle of the GS, we need to be sure to only call emit_shader_time_end() during VS vertex emission. We accomplish this by moving the call to emit_shader_time_end() into the VS implementation of emit_urb_write_opcode(). Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2013-03-22 06:59:52 -07:00
virtual void emit_urb_write_header(int mrf) = 0;
virtual vec4_instruction *emit_urb_write_opcode(bool complete) = 0;
i965/vs: Generalize computation of array strides in preparation for GS. Geometry shader inputs are arrays, but they use an unusual array layout: instead of all array elements for a given geometry shader input being stored consecutively, all geometry shader inputs are interleaved into one giant array. As a result, the array stride we use to access geometry shader inputs must be equal to the size of the input VUE, rather than the size of the array element. This patch introduces a new virtual function, vec4_visitor::compute_array_stride(), which will allow geometry shader compilation to specialize the computation of array stride to account for the unusual layout of geometry shader input arrays. It also renames the local variable that the ir_dereference_array visitor uses to store the stride, to avoid confusion. Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2013-03-22 11:26:34 -07:00
virtual int compute_array_stride(ir_dereference_array *ir);
i965/vs: Don't hardcode DEBUG_VS in generic vec4 code. Since the vec4_visitor and vec4_generator classes are going to be re-used for geometry shaders, we can't enable their debug functionality based on (INTEL_DEBUG & DEBUG_VS) anymore. Instead, add a debug_flag boolean to these two classes, so that when they're instantiated the caller can specify whether debug dumps are needed. Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Eric Anholt <eric@anholt.net> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2013-03-22 21:55:03 -07:00
const bool debug_flag;
i965/vec4: Add the ability to suppress register spilling. In future patches, this will allow us to first try compiling a geometry shader in DUAL_OBJECT mode (which is more efficient but uses more registers) and then if spilling is required, fall back on DUAL_INSTANCED mode. Reviewed-by: Eric Anholt <eric@anholt.net>
2013-10-16 12:13:20 -07:00
private:
/**
* If true, then register allocation should fail instead of spilling.
*/
const bool no_spills;
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
};
i965/vs: Make vec4_vs_visitor class derived from vec4_visitor. This patch just creates the derived class; later patches will migrate VS-specific functions and data structures from the base class into the derived class. 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-15 20:12:13 -08: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
/**
* The vertex shader code generator.
*
* Translates VS IR to actual i965 assembly code.
*/
class vec4_generator
{
public:
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: Plumb brw_vec4_prog_data into vec4_generator(). This will be useful for the next commit. Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Paul Berry <stereotype441@gmail.com>
2013-08-14 20:42:29 -07:00
struct brw_vec4_prog_data *prog_data,
i965/vs: Don't hardcode DEBUG_VS in generic vec4 code. Since the vec4_visitor and vec4_generator classes are going to be re-used for geometry shaders, we can't enable their debug functionality based on (INTEL_DEBUG & DEBUG_VS) anymore. Instead, add a debug_flag boolean to these two classes, so that when they're instantiated the caller can specify whether debug dumps are needed. Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Eric Anholt <eric@anholt.net> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2013-03-22 21:55:03 -07:00
void *mem_ctx,
bool debug_flag);
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();
const unsigned *generate_assembly(exec_list *insts, unsigned *asm_size);
private:
void generate_code(exec_list *instructions);
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
void generate_vec4_instruction(vec4_instruction *inst,
struct brw_reg dst,
struct brw_reg *src);
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 generate_math1_gen4(vec4_instruction *inst,
struct brw_reg dst,
struct brw_reg src);
void generate_math1_gen6(vec4_instruction *inst,
struct brw_reg dst,
struct brw_reg src);
i965/vs: Add support for ir_binop_pow. Fixes vs-pow-float-float.
2011-08-09 12:30:41 -07:00
void generate_math2_gen4(vec4_instruction *inst,
struct brw_reg dst,
struct brw_reg src0,
struct brw_reg src1);
void generate_math2_gen6(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
void generate_math2_gen7(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/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 generate_tex(vec4_instruction *inst,
struct brw_reg dst,
struct brw_reg src);
i965/gs: Add GS_OPCODE_URB_WRITE. Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Matt Turner <mattst88@gmail.com>
2013-03-21 09:11:12 -07:00
void generate_vs_urb_write(vec4_instruction *inst);
void generate_gs_urb_write(vec4_instruction *inst);
i965/gs: Add GS_OPCODE_THREAD_END. Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Matt Turner <mattst88@gmail.com>
2013-03-23 07:42:32 -07:00
void generate_gs_thread_end(vec4_instruction *inst);
i965/gs: Add GS_OPCODE_SET_WRITE_OFFSET. v2: Added a comment to vec4_generator::generate_gs_set_write_offset(). Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Matt Turner <mattst88@gmail.com>
2013-03-23 07:59:13 -07:00
void generate_gs_set_write_offset(struct brw_reg dst,
struct brw_reg src0,
struct brw_reg src1);
i965/gs: Add GS_OPCODE_SET_VERTEX_COUNT. Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Matt Turner <mattst88@gmail.com>
2013-03-23 08:18:43 -07:00
void generate_gs_set_vertex_count(struct brw_reg dst,
struct brw_reg src);
i965/gs: Add GS_OPCODE_SET_DWORD_2_IMMED. Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Matt Turner <mattst88@gmail.com>
2013-02-19 07:31:16 -08:00
void generate_gs_set_dword_2_immed(struct brw_reg dst, struct brw_reg src);
i965/gs: Add opcodes needed for EndPrimitive(). Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2013-04-21 08:51:33 -07:00
void generate_gs_prepare_channel_masks(struct brw_reg dst);
void generate_gs_set_channel_masks(struct brw_reg dst, struct brw_reg src);
i965/vs: Add support for scratch read/write codegen.
2011-08-07 13:36:11 -07:00
void generate_oword_dual_block_offsets(struct brw_reg m1,
struct brw_reg index);
void generate_scratch_write(vec4_instruction *inst,
struct brw_reg dst,
struct brw_reg src,
struct brw_reg index);
void generate_scratch_read(vec4_instruction *inst,
struct brw_reg dst,
struct brw_reg 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
void generate_pull_constant_load(vec4_instruction *inst,
struct brw_reg dst,
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
struct brw_reg index,
struct brw_reg offset);
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 generate_pull_constant_load_gen7(vec4_instruction *inst,
struct brw_reg dst,
struct brw_reg surf_index,
struct brw_reg offset);
i965: add new VS_OPCODE_UNPACK_FLAGS_SIMD4X2 Splits the bottom 8 bits of f0.0 for further wrangling in a SIMD4x2 program. The 4 bits corresponding to the channels in each program flow are copied to the LSBs of dst.x visible to each flow. This is useful for working with clipping flags in the VS. V3: - Fixup immediate types - Teach scheduler about the hidden dep on flags Signed-off-by: Chris Forbes <chrisf@ijw.co.nz> V2: Reviewed-by: Paul Berry <stereotype441@gmail.com>
2013-08-08 06:31:33 +12:00
void generate_unpack_flags(vec4_instruction *inst,
struct brw_reg dst);
i965/vs: Add a little bit of IR-level debug ability. This is super basic, but it let me visualize a problem I had with opt_compute_to_mrf(). Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2012-10-03 16:11:26 -07:00
i965/gen7: Implement code generation for untyped atomic instructions. Reviewed-by: Paul Berry <stereotype441@gmail.com>
2013-09-11 14:01:50 -07:00
void generate_untyped_atomic(vec4_instruction *inst,
struct brw_reg dst,
struct brw_reg atomic_op,
struct brw_reg surf_index);
i965/gen7: Implement code generation for untyped surface read instructions.
2013-09-11 14:03:13 -07:00
void generate_untyped_surface_read(vec4_instruction *inst,
struct brw_reg dst,
struct brw_reg surf_index);
i965/vs: Rework binding table size calculation. Unlike the FS, the VS backend already computed the binding table size. However, it did so poorly: after compilation, it looked to see if any pull constants/textures/UBOs were in use, and set num_surfaces to the maximum surface index for that category. If the VS only used a single texture or UBO, this overcounted by quite a bit. The shader time surface was also noted at state upload time (during drawing), not at compile time, which is inefficient. I believe it also had an off by one error. This patch computes it accurately, while also simplifying the code. It also renames num_surfaces to binding_table_size, since num_surfaces wasn't actually the number of surfaces used. For example, a VS that used one UBO and no other surfaces would have set num_surfaces to SURF_INDEX_VS_UBO(1) == 18, rather than 1. A bit of a misnomer there. Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Paul Berry <stereotype441@gmail.com>
2013-08-14 20:25:40 -07:00
void mark_surface_used(unsigned surf_index);
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
struct brw_context *brw;
struct brw_compile *p;
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: 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
struct gl_shader *shader;
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
const 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
i965/vs: Plumb brw_vec4_prog_data into vec4_generator(). This will be useful for the next commit. Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Paul Berry <stereotype441@gmail.com>
2013-08-14 20:42:29 -07:00
struct brw_vec4_prog_data *prog_data;
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: Don't hardcode DEBUG_VS in generic vec4 code. Since the vec4_visitor and vec4_generator classes are going to be re-used for geometry shaders, we can't enable their debug functionality based on (INTEL_DEBUG & DEBUG_VS) anymore. Instead, add a debug_flag boolean to these two classes, so that when they're instantiated the caller can specify whether debug dumps are needed. Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Eric Anholt <eric@anholt.net> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2013-03-22 21:55:03 -07:00
const bool debug_flag;
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: Create a new vec4 backend for Broadwell. This replaces the old vec4_generator backend. v2: Port to use the C-based instruction representation. Also, remove Geometry Shader offset hacks - the visitor will handle those instead of this code. v3: Texturing fixes (including adding textureGather support). v4: Pass brw_context to gen8_instruction functions as required. v5: Add SHADER_OPCODE_TXF_MCS support; port DUAL_INSTANCED gs fixes (caught by Eric). Simplify ADDC/SUBB handling; add comments to gen8_set_dp_message calls (suggested by Matt). Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Eric Anholt <eric@anholt.net> Reviewed-by: Matt Turner <mattst88@gmail.com>
2012-12-06 22:37:34 -08:00
/**
* The vertex shader code generator.
*
* Translates VS IR to actual i965 assembly code.
*/
class gen8_vec4_generator : public gen8_generator
{
public:
gen8_vec4_generator(struct brw_context *brw,
struct gl_shader_program *shader_prog,
struct gl_program *prog,
struct brw_vec4_prog_data *prog_data,
void *mem_ctx,
bool debug_flag);
~gen8_vec4_generator();
const unsigned *generate_assembly(exec_list *insts, unsigned *asm_size);
private:
void generate_code(exec_list *instructions);
void generate_vec4_instruction(vec4_instruction *inst,
struct brw_reg dst,
struct brw_reg *src);
void generate_tex(vec4_instruction *inst,
struct brw_reg dst);
void generate_urb_write(vec4_instruction *ir, bool copy_g0);
void generate_gs_thread_end(vec4_instruction *ir);
void generate_gs_set_write_offset(struct brw_reg dst,
struct brw_reg src0,
struct brw_reg src1);
void generate_gs_set_vertex_count(struct brw_reg dst,
struct brw_reg src);
void generate_gs_set_dword_2_immed(struct brw_reg dst, struct brw_reg src);
void generate_gs_prepare_channel_masks(struct brw_reg dst);
void generate_gs_set_channel_masks(struct brw_reg dst, struct brw_reg src);
void generate_oword_dual_block_offsets(struct brw_reg m1,
struct brw_reg index);
void generate_scratch_write(vec4_instruction *inst,
struct brw_reg dst,
struct brw_reg src,
struct brw_reg index);
void generate_scratch_read(vec4_instruction *inst,
struct brw_reg dst,
struct brw_reg index);
void generate_pull_constant_load(vec4_instruction *inst,
struct brw_reg dst,
struct brw_reg index,
struct brw_reg offset);
void mark_surface_used(unsigned surf_index);
struct brw_vec4_prog_data *prog_data;
const bool debug_flag;
};
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 */
i965: Make brw_{shader,vec4}.h safe to include from C. The patch that follows will move the definition of struct brw_vec4_prog_key from brw_vs.h to brw_vec4.h, making it necessary for brw_vs.h to include brw_vec4.h (because brw_vs.h defines struct brw_vs_prog_key, which contains brw_vec4_prog_key as a member). Since brw_vs.h is included from C source files, that means that brw_vec4.h will need to be safe to include from C. Same for brw_shader.h, since it is included by brw_vec4.h. Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Matt Turner <mattst88@gmail.com>
2013-08-21 07:53:42 -07:00
#endif /* __cplusplus */
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
#endif /* BRW_VEC4_H */
Reference in New Issue Copy Permalink