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

728 lines
24 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: Rename intel_asm_printer -> intel_asm_annotation. The #ifndef include guards already said the right thing :) Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
2014-06-29 18:09:35 -07:00
#include "intel_asm_annotation.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" */
#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
#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
i965: Make a common backend_reg class. Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
2014-06-29 15:27:07 -07:00
class src_reg : public backend_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
{
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/vec4: Add constructor of src_reg from a fixed hardware reg. Reviewed-by: Paul Berry <stereotype441@gmail.com>
2013-11-22 20:22:03 -08:00
src_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
i965: Make src_reg::equals() take a constant reference, not a pointer. This is more typical C++ style. Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
2013-03-06 08:51:44 -08:00
bool equals(const src_reg &r) 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);
i965: Provide means to create registers of a given size. Implemented by Ilia Mirkin <imirkin@alum.mit.edu>. Acked-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
2014-07-16 10:00:34 +02:00
src_reg(class vec4_visitor *v, const struct glsl_type *type, 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
explicit src_reg(dst_reg reg);
i965/vec4: Fix confusion between SWIZZLE and BRW_SWIZZLE macros. Most of the VEC4 back-end agrees on src_reg::swizzle being one of the BRW_SWIZZLE macros defined in brw_reg.h, except in two places where we use Mesa's SWIZZLE macros. There is even a doxygen comment saying that Mesa's macros are the right ones. They are incompatible swizzle representations (3 bits vs. 2 bits per component), and the code using Mesa's works by pure luck. Fix it. Reviewed-by: Matt Turner <mattst88@gmail.com> Reviewed-by: Paul Berry <stereotype441@gmail.com>
2013-11-27 22:21:45 -08:00
GLuint swizzle; /**< BRW_SWIZZLE_XYZW macros from brw_reg.h. */
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: Make sure that backend_reg::type and brw_reg::type are consistent for fixed regs. And define non-mutating helper functions to retype fixed and normal regs with a common interface. At some point we may want to get rid of ::fixed_hw_reg completely and have fixed regs use the normal register data members (e.g. backend_reg::reg to select a fixed GRF number, src_reg::swizzle to store the swizzle, etc.), I have the feeling that this is not the last headache we're going to get because of the multiple ways to represent the same thing and the different register interface depending on the file a register is stored in... Reviewed-by: Paul Berry <stereotype441@gmail.com>
2014-02-19 15:21:07 +01:00
static inline src_reg
i965: Use enum brw_reg_type for register types. Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
2014-06-29 16:02:59 -07:00
retype(src_reg reg, enum brw_reg_type type)
i965: Make sure that backend_reg::type and brw_reg::type are consistent for fixed regs. And define non-mutating helper functions to retype fixed and normal regs with a common interface. At some point we may want to get rid of ::fixed_hw_reg completely and have fixed regs use the normal register data members (e.g. backend_reg::reg to select a fixed GRF number, src_reg::swizzle to store the swizzle, etc.), I have the feeling that this is not the last headache we're going to get because of the multiple ways to represent the same thing and the different register interface depending on the file a register is stored in... Reviewed-by: Paul Berry <stereotype441@gmail.com>
2014-02-19 15:21:07 +01:00
{
reg.fixed_hw_reg.type = reg.type = type;
return reg;
}
i965: Add non-mutating helper functions to modify the register offset. Yes, we could avoid having four copies of essentially the same code by using templates here. Reviewed-by: Paul Berry <stereotype441@gmail.com>
2014-02-19 15:19:10 +01:00
static inline src_reg
offset(src_reg reg, unsigned delta)
{
assert(delta == 0 || (reg.file != HW_REG && reg.file != IMM));
reg.reg_offset += delta;
return reg;
}
i965/vec4: Add non-mutating helper functions to modify src_reg::swizzle and ::negate. Reviewed-by: Paul Berry <stereotype441@gmail.com>
2014-02-19 15:20:27 +01:00
/**
* Reswizzle a given source register.
* \sa brw_swizzle().
*/
static inline src_reg
swizzle(src_reg reg, unsigned swizzle)
{
assert(reg.file != HW_REG);
reg.swizzle = BRW_SWIZZLE4(
BRW_GET_SWZ(reg.swizzle, BRW_GET_SWZ(swizzle, 0)),
BRW_GET_SWZ(reg.swizzle, BRW_GET_SWZ(swizzle, 1)),
BRW_GET_SWZ(reg.swizzle, BRW_GET_SWZ(swizzle, 2)),
BRW_GET_SWZ(reg.swizzle, BRW_GET_SWZ(swizzle, 3)));
return reg;
}
static inline src_reg
negate(src_reg reg)
{
assert(reg.file != HW_REG && reg.file != IMM);
reg.negate = !reg.negate;
return reg;
}
i965: Make a common backend_reg class. Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
2014-06-29 15:27:07 -07:00
class dst_reg : public backend_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
{
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: Make sure that backend_reg::type and brw_reg::type are consistent for fixed regs. And define non-mutating helper functions to retype fixed and normal regs with a common interface. At some point we may want to get rid of ::fixed_hw_reg completely and have fixed regs use the normal register data members (e.g. backend_reg::reg to select a fixed GRF number, src_reg::swizzle to store the swizzle, etc.), I have the feeling that this is not the last headache we're going to get because of the multiple ways to represent the same thing and the different register interface depending on the file a register is stored in... Reviewed-by: Paul Berry <stereotype441@gmail.com>
2014-02-19 15:21:07 +01:00
static inline dst_reg
i965: Use enum brw_reg_type for register types. Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
2014-06-29 16:02:59 -07:00
retype(dst_reg reg, enum brw_reg_type type)
i965: Make sure that backend_reg::type and brw_reg::type are consistent for fixed regs. And define non-mutating helper functions to retype fixed and normal regs with a common interface. At some point we may want to get rid of ::fixed_hw_reg completely and have fixed regs use the normal register data members (e.g. backend_reg::reg to select a fixed GRF number, src_reg::swizzle to store the swizzle, etc.), I have the feeling that this is not the last headache we're going to get because of the multiple ways to represent the same thing and the different register interface depending on the file a register is stored in... Reviewed-by: Paul Berry <stereotype441@gmail.com>
2014-02-19 15:21:07 +01:00
{
reg.fixed_hw_reg.type = reg.type = type;
return reg;
}
i965: Add non-mutating helper functions to modify the register offset. Yes, we could avoid having four copies of essentially the same code by using templates here. Reviewed-by: Paul Berry <stereotype441@gmail.com>
2014-02-19 15:19:10 +01:00
static inline dst_reg
offset(dst_reg reg, unsigned delta)
{
assert(delta == 0 || (reg.file != HW_REG && reg.file != IMM));
reg.reg_offset += delta;
return reg;
}
i965/vec4: Trivial improvements to the with_writemask() function. Add assertion that the register is not in the HW_REG or IMM file, calculate the conjunction of the old and new mask instead of replacing the old [consistent with the behavior of brw_writemask(), causes no functional changes right now], make it static inline to let the compiler do a slightly better job at optimizing things, and shorten its name. v2: Assert that the new writemask is not zero to avoid undefined hardware behaviour. Reviewed-by: Paul Berry <stereotype441@gmail.com>
2013-11-28 15:07:06 -08:00
static inline dst_reg
writemask(dst_reg reg, unsigned mask)
{
assert(reg.file != HW_REG && reg.file != IMM);
assert((reg.writemask & mask) != 0);
reg.writemask &= mask;
return reg;
}
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
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,
i965/vec4: Pass const references to vec4_instruction(). text data bss dec hex filename 4244821 123200 39648 4407669 434175 i965_dri.so 4231165 123200 39648 4394013 430c1d i965_dri.so Cuts 13k of .text and saves a bunch of useless struct copies. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2014-06-28 13:46:29 -07:00
const dst_reg &dst = dst_reg(),
const src_reg &src0 = src_reg(),
const src_reg &src1 = src_reg(),
const src_reg &src2 = src_reg());
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
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 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;
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/gen6/gs: implement GS_OPCODE_SVB_WRITE opcode This opcode will be used when sending SVB WRITE messages to save transform feedback outputs into Streamed Vertex Buffers. Signed-off-by: Samuel Iglesias Gonsalvez <siglesias@igalia.com> Acked-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
2014-07-18 10:36:10 +02:00
unsigned sol_binding; /**< gen6: SOL binding table index */
bool sol_final_write; /**< gen6: send commit message */
i965/gen6/gs: implement GS_OPCODE_SVB_SET_DST_INDEX opcode This opcode generates code to copy the specified destination index into subregister 5 of the MRF message header. Signed-off-by: Samuel Iglesias Gonsalvez <siglesias@igalia.com> Acked-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
2014-07-18 10:47:15 +02:00
unsigned sol_vertex; /**< gen6: used for setting dst index in SVB header */
i965/gen6/gs: implement GS_OPCODE_SVB_WRITE opcode This opcode will be used when sending SVB WRITE messages to save transform feedback outputs into Streamed Vertex Buffers. Signed-off-by: Samuel Iglesias Gonsalvez <siglesias@igalia.com> Acked-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
2014-07-18 10:36:10 +02: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/vec4: Reswizzle sources when necessary. Despite the comment above the function claiming otherwise, the function did not reswizzle sources, which would lead to bad code generation since commit 04895f5c, which began claiming we could do such swizzling when we could not. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=82932 Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2014-08-31 11:10:02 -07:00
bool can_reswizzle(int dst_writemask, int swizzle, int swizzle_mask);
void reswizzle(int dst_writemask, int swizzle);
i965: Make can_do_source_mods() a member of the instruction classes. Pretty nonsensical to have it as a method of the visitor just for access to brw. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2014-06-23 21:57:31 -07:00
bool can_do_source_mods(struct brw_context *brw);
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/vec4: Rename depends_on_flags() to reads_flag(). To be consistent with the fs backend. Reviewed-by: Eric Anholt <eric@anholt.net>
2014-03-12 00:16:24 -07:00
bool reads_flag()
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: 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/vec4: Add and use vec4_instruction::writes_flag(). To be consistent with the fs backend. Also the instruction scheduler incorrectly considered SEL with a conditional modifier to read the flag register. Reviewed-by: Eric Anholt <eric@anholt.net>
2014-03-12 00:14:07 -07:00
bool writes_flag()
{
return conditional_mod && opcode != BRW_OPCODE_SEL;
}
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: Merge resolving of shader program source Reviewed-by: Matt Turner <mattst88@gmail.com> Signed-off-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
2014-02-18 22:50:13 +02:00
gl_shader_stage stage,
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,
i965: Add GS support to INTEL_DEBUG=shader_time. Previously, time spent in geometry shaders would be counted as part of the vertex shader time. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2014-01-17 14:42:48 -08:00
bool no_spills,
shader_time_shader_type st_base,
shader_time_shader_type st_written,
shader_time_shader_type st_reset);
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/vec4: Mark invariant members as constants in vec4_visitor Reviewed-by: Matt Turner <mattst88@gmail.com> Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Signed-off-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
2014-02-15 10:26:09 +02:00
struct brw_vec4_compile * const c;
const struct brw_vec4_prog_key * const key;
struct brw_vec4_prog_data * const 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: Allocate vec4_visitor's uniform_size and uniform_vector_size arrays dynamically. v2: Don't add function parameters, pass the required size in prog_data->nr_params. v3: - Use the name uniform_array_size instead of uniform_param_count. - Round up when dividing param_count by 4. - Use MAX2() instead of taking the maximum by hand. - Don't crash if prog_data passed to vec4_visitor constructor is NULL v4: Rebase for current master v5 (idr): Trivial whitespace change. Signed-off-by: Petri Latvala <petri.latvala@intel.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=71254 Cc: "10.1" <mesa-stable@lists.freedesktop.org> Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
2014-02-27 16:15:04 +02:00
int *uniform_size;
int *uniform_vector_size;
int uniform_array_size; /*< Size of uniform_[vector_]size arrays */
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: Add invalidate_cfg parameter to invalidate_live_intervals(). Will let us avoid invalidating the CFG if the optimization pass has removed instructions using the new basic block methods. Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
2014-07-12 17:49:32 -07:00
void invalidate_live_intervals(bool invalidate_cfg = true);
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/vec4: Add a pass to reduce swizzles. total instructions in shared programs: 4344280 -> 4288033 (-1.29%) instructions in affected programs: 397468 -> 341221 (-14.15%) Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2014-08-17 15:13:54 -07:00
bool opt_reduce_swizzle();
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/vec4: Move aeb list into opt_cse_local. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2014-07-11 20:36:39 -07:00
bool opt_cse_local(bblock_t *block);
i965/vec4: Add basic common subexpression elimination. [mattst88]: Modified to perform CSE on instructions with the same writemask. Offered no improvement before. total instructions in shared programs: 1995633 -> 1995185 (-0.02%) instructions in affected programs: 14410 -> 13962 (-3.11%) Reviewed-by: Matt Turner <mattst88@gmail.com> Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
2013-03-06 10:48:55 -08:00
bool opt_cse();
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: 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/vec4: Pass const references to instruction functions. text data bss dec hex filename 4231165 123200 39648 4394013 430c1d i965_dri.so 4186277 123200 39648 4349125 425cc5 i965_dri.so Cuts 43k of .text and saves a bunch of useless struct copies. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2014-06-28 13:53:55 -07:00
vec4_instruction *MOV(const dst_reg &dst, const src_reg &src0);
vec4_instruction *NOT(const dst_reg &dst, const src_reg &src0);
vec4_instruction *RNDD(const dst_reg &dst, const src_reg &src0);
vec4_instruction *RNDE(const dst_reg &dst, const src_reg &src0);
vec4_instruction *RNDZ(const dst_reg &dst, const src_reg &src0);
vec4_instruction *FRC(const dst_reg &dst, const src_reg &src0);
vec4_instruction *F32TO16(const dst_reg &dst, const src_reg &src0);
vec4_instruction *F16TO32(const dst_reg &dst, const src_reg &src0);
vec4_instruction *ADD(const dst_reg &dst, const src_reg &src0,
const src_reg &src1);
vec4_instruction *MUL(const dst_reg &dst, const src_reg &src0,
const src_reg &src1);
vec4_instruction *MACH(const dst_reg &dst, const src_reg &src0,
const src_reg &src1);
vec4_instruction *MAC(const dst_reg &dst, const src_reg &src0,
const src_reg &src1);
vec4_instruction *AND(const dst_reg &dst, const src_reg &src0,
const src_reg &src1);
vec4_instruction *OR(const dst_reg &dst, const src_reg &src0,
const src_reg &src1);
vec4_instruction *XOR(const dst_reg &dst, const src_reg &src0,
const src_reg &src1);
vec4_instruction *DP3(const dst_reg &dst, const src_reg &src0,
const src_reg &src1);
vec4_instruction *DP4(const dst_reg &dst, const src_reg &src0,
const src_reg &src1);
vec4_instruction *DPH(const dst_reg &dst, const src_reg &src0,
const src_reg &src1);
vec4_instruction *SHL(const dst_reg &dst, const src_reg &src0,
const src_reg &src1);
vec4_instruction *SHR(const dst_reg &dst, const src_reg &src0,
const src_reg &src1);
vec4_instruction *ASR(const dst_reg &dst, const src_reg &src0,
const 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,
i965: Make a brw_conditional_mod enum. Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
2014-06-29 17:50:20 -07:00
enum brw_conditional_mod condition);
vec4_instruction *IF(src_reg src0, src_reg src1,
enum brw_conditional_mod condition);
i965: Make a brw_predicate enum. Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
2014-06-29 17:58:59 -07:00
vec4_instruction *IF(enum brw_predicate predicate);
i965/vec4: Pass const references to instruction functions. text data bss dec hex filename 4231165 123200 39648 4394013 430c1d i965_dri.so 4186277 123200 39648 4349125 425cc5 i965_dri.so Cuts 43k of .text and saves a bunch of useless struct copies. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2014-06-28 13:53:55 -07:00
vec4_instruction *PULL_CONSTANT_LOAD(const dst_reg &dst,
const src_reg &index);
vec4_instruction *SCRATCH_READ(const dst_reg &dst, const src_reg &index);
vec4_instruction *SCRATCH_WRITE(const dst_reg &dst, const src_reg &src,
const src_reg &index);
vec4_instruction *LRP(const dst_reg &dst, const src_reg &a,
const src_reg &y, const src_reg &x);
vec4_instruction *BFREV(const dst_reg &dst, const src_reg &value);
vec4_instruction *BFE(const dst_reg &dst, const src_reg &bits,
const src_reg &offset, const src_reg &value);
vec4_instruction *BFI1(const dst_reg &dst, const src_reg &bits,
const src_reg &offset);
vec4_instruction *BFI2(const dst_reg &dst, const src_reg &bfi1_dst,
const src_reg &insert, const src_reg &base);
vec4_instruction *FBH(const dst_reg &dst, const src_reg &value);
vec4_instruction *FBL(const dst_reg &dst, const src_reg &value);
vec4_instruction *CBIT(const dst_reg &dst, const src_reg &value);
vec4_instruction *MAD(const dst_reg &dst, const src_reg &c,
const src_reg &b, const src_reg &a);
vec4_instruction *ADDC(const dst_reg &dst, const src_reg &src0,
const src_reg &src1);
vec4_instruction *SUBB(const dst_reg &dst, const src_reg &src0,
const 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: 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: Make a brw_conditional_mod enum. Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
2014-06-29 17:50:20 -07:00
void emit_vp_sop(enum brw_conditional_mod condmod, dst_reg dst,
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
src_reg src0, src_reg src1, src_reg one);
i965: Make a brw_predicate enum. Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
2014-06-29 17:58:59 -07:00
void emit_bool_to_cond_code(ir_rvalue *ir, enum brw_predicate *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_if_gen6(ir_if *ir);
i965: Make a brw_conditional_mod enum. Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
2014-06-29 17:50:20 -07:00
void emit_minmax(enum brw_conditional_mod conditionalmod, dst_reg dst,
src_reg src0, src_reg src1);
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
i965/vec4: Handle ir_triop_lrp on Gen4-5 as well. When the vec4 backend encountered an ir_triop_lrp, it always emitted an actual LRP instruction, which only exists on Gen6+. Gen4-5 used lower_instructions() to decompose ir_triop_lrp at the IR level. Since commit 8d37e9915a3b21 ("glsl: Optimize open-coded lrp into lrp."), we've had an bug where lower_instructions translates ir_triop_lrp into arithmetic, but opt_algebraic reassembles it back into a lrp. To avoid this ordering concern, just handle ir_triop_lrp in the backend. The FS backend already does this, so we may as well do likewise. v2: Add a comment reminding us that we could emit better assembly if we implemented the infrastructure necessary to support using MAC. (Assembly code provided by Eric Anholt). Cc: "10.1" <mesa-stable@lists.freedesktop.org> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=75253 Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Matt Turner <mattst88@gmail.com> Acked-by: Eric Anholt <eric@anholt.net>
2014-02-23 16:29:46 -08:00
void emit_lrp(const dst_reg &dst,
const src_reg &x, const src_reg &y, const src_reg &a);
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: Make a brw_predicate enum. Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
2014-06-29 17:58:59 -07:00
const struct glsl_type *type, brw_predicate 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/vec4: Pass sampler index in src1 for texture ops Signed-off-by: Chris Forbes <chrisf@ijw.co.nz> Reviewed-by: Matt Turner <mattst88@gmail.com> Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
2014-08-04 19:37:58 +12:00
uint32_t gather_channel(ir_texture *ir, uint32_t sampler);
i965/vec4: Add support for nonconst sampler indexing in VS visitor V2: Set force_writemask_all on ADD; this *is* necessary in the VS case too. Signed-off-by: Chris Forbes <chrisf@ijw.co.nz> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2014-08-09 22:08:11 +12:00
src_reg emit_mcs_fetch(ir_texture *ir, src_reg coordinate, src_reg sampler);
i965/vec4: Emit shader w/a for Gen6 gather Signed-off-by: Chris Forbes <chrisf@ijw.co.nz> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2014-02-03 22:15:41 +13:00
void emit_gen6_gather_wa(uint8_t wa, dst_reg dst);
i965/vec4: Pass sampler index in src1 for texture ops Signed-off-by: Chris Forbes <chrisf@ijw.co.nz> Reviewed-by: Matt Turner <mattst88@gmail.com> Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
2014-08-04 19:37:58 +12:00
void swizzle_result(ir_texture *ir, src_reg orig_val, uint32_t 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
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: Generalize emit_urb_slot() to emit to any dst_reg. In gen7+ we emit vertices as they come, however in gen6 geometry shaders we have to buffer vertex data for all vertices and then emit it all in one go at the end. To achieve this we need to generalize emit_urb_slot() to store vertex data in general purpose registers and not only MRF registers. Acked-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
2014-07-17 16:59:10 +02:00
void emit_psiz_and_flags(dst_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);
i965: Generalize emit_urb_slot() to emit to any dst_reg. In gen7+ we emit vertices as they come, however in gen6 geometry shaders we have to buffer vertex data for all vertices and then emit it all in one go at the end. To achieve this we need to generalize emit_urb_slot() to store vertex data in general purpose registers and not only MRF registers. Acked-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
2014-07-17 16:59:10 +02:00
void emit_urb_slot(dst_reg reg, 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
i965/vec4: Remove 'mul_arg' from try_emit_mad(). Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2014-04-28 10:30:50 -07:00
bool try_emit_mad(ir_expression *ir);
i965/vec4: Emit smarter code for b2f of a comparison Previously we would emit the comparison, emit an AND to mask off extra bits from the comparison result, then convert the result to float. Now, do the comparison, then use a cleverly constructed SEL to pick either 0.0f or 1.0f. No piglit regressions on Ivybridge. total instructions in shared programs: 1642311 -> 1639449 (-0.17%) instructions in affected programs: 136533 -> 133671 (-2.10%) GAINED: 0 LOST: 0 Programs that are affected appear to save between 1 and 5 instuctions (just by skimming the output from shader-db report.py. v2: s/b2i/b2f/ in commit subject (noticed by Chris Forbes). Remove extraneous fix_3src_operand (suggested by Matt). The latter change required swapping the order of the operands and using predicate_inverse. Signed-off-by: Ian Romanick <ian.d.romanick@intel.com> Reviewed-by: Matt Turner <mattst88@gmail.com>
2014-06-10 18:07:50 -07:00
bool try_emit_b2f_of_compare(ir_expression *ir);
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: Give dump_instruction() a FILE* argument. Use function overloading rather than default arguments, since gdb doesn't know about default arguments. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2014-05-29 11:45:15 -07:00
void dump_instruction(backend_instruction *inst, FILE *file);
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/gen6/gs: Fix binding table clash between TF surfaces and textures. For gen6 geometry shaders we use the first BRW_MAX_SOL_BINDINGS entries of the binding table for transform feedback surfaces. However, vec4_visitor will setup the binding table so that textures use the same space in the binding table. This is done when calling assign_common_binding_table_offsets(0) as part if its run() method. To fix this clash we add a virtual method to the vec4_visitor hierarchy to assign the binding table offsets, so that we can change this behavior specifically for gen6 geometry shaders by mapping textures right after the first BRW_MAX_SOL_BINDINGS entries. Also, when there is no user-provided geometry shader, we only need to upload the binding table if we have transform feedback, however, in the case of a user-provided geometry shader, we can't only look into transform feedback to make that decision. This fixes multiple piglit tests for textureSize() and texelFetch() when these functions are called from a geometry shader in gen6, like these: bin/textureSize gs sampler2D -fbo -auto bin/texelFetch gs usampler2D -fbo -auto Acked-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
2014-08-01 10:35:20 +02:00
virtual void assign_binding_table_offsets();
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: Add GS support to INTEL_DEBUG=shader_time. Previously, time spent in geometry shaders would be counted as part of the vertex shader time. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2014-01-17 14:42:48 -08:00
const shader_time_shader_type st_base;
const shader_time_shader_type st_written;
const shader_time_shader_type st_reset;
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();
i965: Pass a cfg pointer to generate_{code,assembly}. The loop over all instructions is now two-fold, over all of the blocks and all of the instructions in each block. Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
2014-07-11 21:16:13 -07:00
const unsigned *generate_assembly(const cfg_t *cfg, unsigned *asm_size);
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
private:
i965: Pass a cfg pointer to generate_{code,assembly}. The loop over all instructions is now two-fold, over all of the blocks and all of the instructions in each block. Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
2014-07-11 21:16:13 -07:00
void generate_code(const cfg_t *cfg);
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);
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);
i965/vec4: Combine generate_math[12]_gen6 methods. These are trivial to combine: we should just avoid checking the second operand if it's brw_null_reg. Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Matt Turner <mattst88@gmail.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
2014-06-07 02:32:40 -07:00
void generate_math_gen6(vec4_instruction *inst,
struct brw_reg dst,
struct brw_reg src0,
struct brw_reg src1);
i965/vs: Add support for ir_binop_pow. Fixes vs-pow-float-float.
2011-08-09 12:30:41 -07:00
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,
i965/vec4/Gen4-7: Use src1 for sampler_index instead of ->sampler field Signed-off-by: Chris Forbes <chrisf@ijw.co.nz> Reviewed-by: Matt Turner <mattst88@gmail.com> Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
2014-08-04 19:41:03 +12:00
struct brw_reg dst,
struct brw_reg src,
struct brw_reg sampler_index);
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
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/gen6/gs: Implement GS_OPCODE_URB_WRITE_ALLOCATE. Gen6 geometry shaders need to allocate URB handles for each new vertex they emit after the first (the URB handle for the first vertex is obtained via the FF_SYNC message). This opcode adds the URB allocation mechanism to regular URB writes. Acked-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
2014-07-09 16:28:30 +02:00
void generate_gs_urb_write_allocate(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/gen6/gs: implement GS_OPCODE_SVB_WRITE opcode This opcode will be used when sending SVB WRITE messages to save transform feedback outputs into Streamed Vertex Buffers. Signed-off-by: Samuel Iglesias Gonsalvez <siglesias@igalia.com> Acked-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
2014-07-18 10:36:10 +02:00
void generate_gs_svb_write(vec4_instruction *inst,
struct brw_reg dst,
struct brw_reg src0,
struct brw_reg src1);
i965/gen6/gs: implement GS_OPCODE_SVB_SET_DST_INDEX opcode This opcode generates code to copy the specified destination index into subregister 5 of the MRF message header. Signed-off-by: Samuel Iglesias Gonsalvez <siglesias@igalia.com> Acked-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
2014-07-18 10:47:15 +02:00
void generate_gs_svb_set_destination_index(vec4_instruction *inst,
struct brw_reg dst,
struct brw_reg src);
i965/gen6/gs: Implement GS_OPCODE_SET_DWORD_2. We had GS_OPCODE_SET_DWORD_2_IMMED but this required its source argument to be an immediate. In gen6 we need to set dword 2 of the URB write message header from values stored in separate register, so we need something more flexible. This change replaces GS_OPCODE_SET_DWORD_2_IMMED with GS_OPCODE_SET_DWORD_2. Acked-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
2014-07-17 08:54:03 +02:00
void generate_gs_set_dword_2(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: support gl_InvocationID for gen7 v2: * Make gl_InvocationID a system value v3: * Properly shift from R0.1 into DST.4 by adding GS_OPCODE_GET_INSTANCE_ID Signed-off-by: Jordan Justen <jordan.l.justen@intel.com> Acked-by: Paul Berry <stereotype441@gmail.com> Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
2014-01-25 12:55:24 -08:00
void generate_gs_get_instance_id(struct brw_reg dst);
i965/gen6/gs: implement GS_OPCODE_FF_SYNC_SET_PRIMITIVES opcode This opcode will be used when filling FF_SYNC header before emitting vertices and their data. Signed-off-by: Samuel Iglesias Gonsalvez <siglesias@igalia.com> Acked-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
2014-07-23 12:56:53 +02:00
void generate_gs_ff_sync_set_primitives(struct brw_reg dst,
struct brw_reg src0,
struct brw_reg src1,
struct brw_reg src2);
i965/gen6/gs: Implement GS_OPCODE_FF_SYNC. This implements the FF_SYNC message required in gen6 geometry shaders to get the initial URB handle. Acked-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
2014-07-09 08:46:17 +02:00
void generate_gs_ff_sync(vec4_instruction *inst,
struct brw_reg dst,
i965/gen6/gs: Add an additional parameter to the FF_SYNC opcode. We will use this parameter in later patches to provide information relevant to transform feedback that needs to be set as part of the FF_SYNC message. Signed-off-by: Samuel Iglesias Gonsalvez <siglesias@igalia.com> Acked-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
2014-07-23 10:51:35 +02:00
struct brw_reg src0,
struct brw_reg src1);
i965/gen6/gs: Implement GS_OPCODE_SET_PRIMITIVE_ID. In gen6 the geometry shader payload includes the PrimitiveID information in r0.1. When the shader code uses glPimitiveIdIn we will have to move this to a separate hardware register where we can map this attribute. This opcode takes the selected destination register and moves r0.1 there. Acked-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
2014-07-24 12:14:27 +02:00
void generate_gs_set_primitive_id(struct brw_reg dst);
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: 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: 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
};
} /* 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 a new issue Copy permalink