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

383 lines
13 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 "brw_shader.h"
i965: Clean up #includes in the compiler. Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
2015-11-22 18:27:42 -08: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: Move IR object definitions to separate header files. One should be able to manipulate i965 IR without pulling the whole FS/VEC4 visitor classes -- Optimization passes and other transformations would ideally be visitor-agnostic. Among other issues this avoids a circular dependency between the header file where such visitor-agnostic code will be defined and the main FS/VEC4 header where both IR (layer below) and visitor (layer above) happen to be defined. Reviewed-by: Matt Turner <mattst88@gmail.com>
2015-02-06 01:11:18 +02:00
#include "brw_ir_vec4.h"
i965: Make brw_{shader,vec4}.h safe to include from C. The patch that follows will move the definition of struct brw_vec4_prog_key from brw_vs.h to brw_vec4.h, making it necessary for brw_vs.h to include brw_vec4.h (because brw_vs.h defines struct brw_vs_prog_key, which contains brw_vec4_prog_key as a member). Since brw_vs.h is included from C source files, that means that brw_vec4.h will need to be safe to include from C. Same for brw_shader.h, since it is included by brw_vec4.h. Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Matt Turner <mattst88@gmail.com>
2013-08-21 07:53:42 -07:00
#endif
i965: Start adding the VS visitor and codegen. The low-level IR is a mashup of brw_fs.cpp and ir_to_mesa.cpp. It's currently controlled by the INTEL_NEW_VS=1 environment variable, and only tested for the trivial "gl_Position = gl_Vertex;" shader so far.
2011-05-02 09:45:40 -07:00
i965: Fix Android build by removing relative includes Replace each occurence of #include "../glsl/*.h" with #include "glsl/*.h" Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Signed-off-by: Chad Versace <chad@chad-versace.us>
2011-08-26 13:58:41 -07:00
#include "glsl/ir.h"
i965/nir/vec4: Add implementation placeholders for a new NIR->vec4 pass This patch will add a brw_vec4_nir.cpp file filled with entry point methods to the main functionality, following a structure similar to brw_fs_nir.cpp. Subsequent patches in this series will be adding the implementations for these methods, incrementally. Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>
2015-06-16 12:08:09 +02:00
#include "glsl/nir/nir.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
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: Wrap vec4_generator in a C function. vec4_generator is a class for convenience, but only exports a single method as its public API. It makes much more sense to just export a single function. Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Matt Turner <mattst88@gmail.com>
2015-10-22 15:01:27 -07:00
const unsigned *
brw_vec4_generate_assembly(const struct brw_compiler *compiler,
void *log_data,
void *mem_ctx,
const nir_shader *nir,
struct brw_vue_prog_data *prog_data,
const struct cfg_t *cfg,
unsigned *out_assembly_size);
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 {
i965/vec4: Make live_intervals part of the vec4_visitor class. Like in fs_visitor. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2014-10-29 13:27:37 -07:00
class vec4_live_variables;
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/vec4: Delete the old ir_visitor code Reviewed-by: Matt Turner <mattst88@gmail.com>
2015-09-21 11:03:29 -07:00
class vec4_visitor : public backend_shader
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: Remove the brw_context from the visitors As of this commit, nothing actually needs the brw_context. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Chris Forbes <chrisf@ijw.co.nz>
2015-06-22 17:17:56 -07:00
vec4_visitor(const struct brw_compiler *compiler,
i965/vec4: Plumb log_data through so the backend_shader field gets set. Jason plumbed this through a while back in the FS backend, but apparently we were just passing NULL in the vec4 backend. This patch passes brw in as intended. Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
2015-06-29 21:58:47 -07:00
void *log_data,
i965: Remove the brw_vue_prog_key base class. The legacy userclip fields are only used for the vertex shader, and at that point there's only program_string_id and the tex struct, which are common to all keys. So there's no need for a "VUE" key base class. Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Chris Forbes <chrisf@ijw.co.nz>
2015-08-27 18:24:39 -07:00
const struct brw_sampler_prog_key_data *key,
i965: Rename brw_vec4_prog_data/key to brw_bue_prog_data/key These structs aren't vec4 specific, they are shared by shader stages operating on Vertex URB Entries (VUEs). VUEs are the data structures in the URB that hold vertex data between the pipeline geometry stages. Using vue in the name instead of vec4 makes a lot more sense, especially when we add scalar vertex shader support. Signed-off-by: Kristian Høgsberg <krh@bitplanet.net> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2014-11-25 14:29:48 -08:00
struct brw_vue_prog_data *prog_data,
i965: Use a const nir_shader in backend_shader Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
2015-10-05 19:26:02 -07:00
const nir_shader *shader,
i965/vs: Don't hardcode DEBUG_VS in generic vec4 code. Since the vec4_visitor and vec4_generator classes are going to be re-used for geometry shaders, we can't enable their debug functionality based on (INTEL_DEBUG & DEBUG_VS) anymore. Instead, add a debug_flag boolean to these two classes, so that when they're instantiated the caller can specify whether debug dumps are needed. Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Eric Anholt <eric@anholt.net> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2013-03-22 21:55:03 -07:00
void *mem_ctx,
i965: 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,
i965: Pull calls to get_shader_time_index out of the visitor Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Chris Forbes <chrisf@ijw.co.nz>
2015-06-19 15:40:09 -07:00
int shader_time_index);
i965: Make vec4_visitor's destructor virtual We need a virtual destructor when at least one of the class' methods is virtual. Failure to do so might lead to undefined behavior when destructing derived classes. Fixes the following warning: brw_vec4_gs_visitor.cpp: In function 'const unsigned int* brw::brw_gs_emit(brw_context*, gl_shader_program*, brw_gs_compile*, void*, unsigned int*)': brw_vec4_gs_visitor.cpp:703:11: warning: deleting object of polymorphic class type 'brw::vec4_gs_visitor' which has non-virtual destructor might cause undefined behaviour [-Wdelete-non-virtual-dtor] delete gs; Curro: This shouldn't be causing any actual bugs at the moment because gen6_gs_visitor is the only subclass of vec4_visitor destroyed through a pointer of a base class (vec4_gs_visitor *) and its destructor is basically the same as its parent's. Anyway it seems sensible to change this so it doesn't bite us in the future. Reviewed-by: Francisco Jerez <currojerez@riseup.net>
2015-10-05 09:02:54 +02:00
virtual ~vec4_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
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: Store a key_tex pointer in vec4_visitor. I'm about to remove the base class for VS/GS/HS/DS program keys, at which point we won't be able to use key->tex anymore. Instead, we'll need to store a direct pointer (like we do in the FS backend). Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Chris Forbes <chrisf@ijw.co.nz>
2015-08-27 23:55:28 -07:00
const struct brw_sampler_prog_key_data * const key_tex;
i965: Rename brw_vec4_prog_data/key to brw_bue_prog_data/key These structs aren't vec4 specific, they are shared by shader stages operating on Vertex URB Entries (VUEs). VUEs are the data structures in the URB that hold vertex data between the pipeline geometry stages. Using vue in the name instead of vec4 makes a lot more sense, especially when we add scalar vertex shader support. Signed-off-by: Kristian Høgsberg <krh@bitplanet.net> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2014-11-25 14:29:48 -08:00
struct brw_vue_prog_data * const prog_data;
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 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/vec4: Make live_intervals part of the vec4_visitor class. Like in fs_visitor. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2014-10-29 13:27:37 -07:00
brw::vec4_live_variables *live_intervals;
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
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
/* 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;
i965/vec4: Get rid of the uniform_vector_size array The uniform_vector_size array was only ever used by pack_uniform_registers which no longer needs it. Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
2015-09-30 11:02:14 -07:00
int uniform_array_size; /*< Size of the uniform_size array */
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: Move legacy clip plane handling to vec4_vs_visitor. This is now only used for the vertex shader, so it makes sense to get it out of any paths run by the geometry shader. Instead of passing the gl_clip_plane array into the run() method (which is shared among all subclasses), we add it as a vec4_vs_visitor constructor parameter. This eliminates the bogus NULL parameter in the GS case. Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Chris Forbes <chrisf@ijw.co.nz>
2015-08-27 23:49:03 -07:00
bool run();
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 fail(const char *msg, ...);
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 setup_uniforms(int payload_reg);
i965: Define the setup_vector_uniform_values() backend_visitor interface. This cleans up the VEC4 implementation of setup_uniform_values() somewhat and will avoid duplication of the image uniform upload code by having a common interface to upload a vector of uniforms on either back-end. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2015-06-28 21:04:17 +03:00
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: Remove cfg-invalidating parameter from invalidate_live_intervals. Everything has been converted to preserve the CFG. Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
2014-09-01 10:54:00 -07:00
void invalidate_live_intervals();
i965/vs: Add support for splitting virtual GRFs. This should improve our ability to register allocate without spilling. Unfortuantely, due to the live variable analysis being ignorant of loops, we still have register allocation failures on some programs. v2: Add more context to the comment explaining the function. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> (v1)
2012-10-03 10:04:22 -07:00
void split_virtual_grfs();
i965/vec4: Add pass to gather constants into a vector-float MOV. Currently only handles consecutive instructions with the same destination that collectively write all channels. total instructions in shared programs: 5879798 -> 5869011 (-0.18%) instructions in affected programs: 465236 -> 454449 (-2.32%) Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
2014-12-20 11:50:31 -08:00
bool opt_vector_float();
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/vec4: Define helpers to calculate the common live interval of a range of variables. These will be especially useful when we start keeping track of liveness information for each subregister. Reviewed-by: Matt Turner <mattst88@gmail.com>
2015-03-18 20:49:43 +02:00
int var_range_start(unsigned v, unsigned n) const;
int var_range_end(unsigned v, unsigned n) const;
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/vec4: adding vec4_cmod_propagation optimization vec4 port of fs_cmod_propagation. Shader-db results (no vec4 grepping): total instructions in shared programs: 6240413 -> 6235841 (-0.07%) instructions in affected programs: 401933 -> 397361 (-1.14%) total loops in shared programs: 1979 -> 1979 (0.00%) helped: 2265 HURT: 0 v2: remove extra space and combine two if blocks, as suggested by Matt Turner v3: add condition check to bail out if current inst and inst being scanned has different writemask, as pointed by Matt Turner v3: updated shader-db numbers v4: remove block from foreach_inst_in_block_*_starting_from after commit 801f151917fedb13c5c6e96281a18d833dd6901f Reviewed-by: Matt Turner <mattst88@gmail.com>
2015-09-28 17:00:19 +02:00
bool opt_cmod_propagation();
i965/vec4: Add parameter to skip doing constant propagation. After CSEing some MOV ..., VF instructions we have code like mov tmp, [1F, 2F, 3F, 4F]VF mov r10, tmp mov r11, tmp ... use r10 use r11 We want to copy propagate tmp into the uses of r10 and r11, but *not* constant propagate the VF immediate into the uses of tmp. Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
2014-12-20 17:37:09 -08:00
bool opt_copy_propagation(bool do_constant_prop = true);
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: Perform basic optimizations on the FIND_LIVE_CHANNEL opcode. v2: Save some CPU cycles by doing 'return progress' rather than 'depth++' in the discard jump special case. Reviewed-by: Matt Turner <mattst88@gmail.com> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2015-02-20 20:25:04 +02:00
bool eliminate_find_live_channel();
i965/vec4/gen8: Handle the MUL dest hazard exception Fix one of the few cases where we can't reliable touch the destination hazard bits. I am explicitly doing this patch individually so it is easy to backport. I was tempted to do this patch before the previous patch which reorganized the code, but I believe even doing that first, this is still easy to backport. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=84212 Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Reviewed-by: Matt Turner <mattst88@gmail.com>
2014-11-21 10:47:41 -08:00
bool is_dep_ctrl_unsafe(const vec4_instruction *inst);
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/vec4: Convert src_reg/dst_reg to brw_reg at the end of the visitor. This patch makes the visitor convert registers to the HW_REG file at the very end, after register allocation, post-RA scheduling, and dependency control flagging. After that, everything is in fixed brw_regs. This simplifies the code generator, as it can just use the hardware registers rather than having to interpret our abstract files. In particular, interpreting the UNIFORM file meant reading prog_data to figure out where push constants are supposed to start. Having the part of the code that performs register allocation also translate everything to hardware registers seems sensible. Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Matt Turner <mattst88@gmail.com>
2015-10-22 16:04:15 -07:00
void convert_to_hw_regs();
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: Use const references in emit() functions. Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Matt Turner <mattst88@gmail.com> Reviewed-by: Francisco Jerez <currojerez@riseup.net>
2014-11-10 17:20:37 -08:00
vec4_instruction *emit(enum opcode opcode, const dst_reg &dst);
vec4_instruction *emit(enum opcode opcode, const dst_reg &dst,
const src_reg &src0);
vec4_instruction *emit(enum opcode opcode, const dst_reg &dst,
const src_reg &src0, const src_reg &src1);
vec4_instruction *emit(enum opcode opcode, const dst_reg &dst,
const src_reg &src0, const src_reg &src1,
const src_reg &src2);
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: Preserve CFG in spill_reg(). Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
2014-08-24 19:38:21 -07:00
vec4_instruction *emit_before(bblock_t *block,
vec4_instruction *inst,
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 *new_inst);
i965: Use macros to create prototypes for emitter helpers. We do this almost everywhere else; this should make it easier to modify. Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Matt Turner <mattst88@gmail.com> Reviewed-by: Francisco Jerez <currojerez@riseup.net>
2014-11-10 17:14:48 -08:00
#define EMIT1(op) vec4_instruction *op(const dst_reg &, const src_reg &);
#define EMIT2(op) vec4_instruction *op(const dst_reg &, const src_reg &, const src_reg &);
#define EMIT3(op) vec4_instruction *op(const dst_reg &, const src_reg &, const src_reg &, const src_reg &);
EMIT1(MOV)
EMIT1(NOT)
EMIT1(RNDD)
EMIT1(RNDE)
EMIT1(RNDZ)
EMIT1(FRC)
EMIT1(F32TO16)
EMIT1(F16TO32)
EMIT2(ADD)
EMIT2(MUL)
EMIT2(MACH)
EMIT2(MAC)
EMIT2(AND)
EMIT2(OR)
EMIT2(XOR)
EMIT2(DP3)
EMIT2(DP4)
EMIT2(DPH)
EMIT2(SHL)
EMIT2(SHR)
EMIT2(ASR)
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: Use macros to create prototypes for emitter helpers. We do this almost everywhere else; this should make it easier to modify. Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Matt Turner <mattst88@gmail.com> Reviewed-by: Francisco Jerez <currojerez@riseup.net>
2014-11-10 17:14:48 -08:00
EMIT1(SCRATCH_READ)
EMIT2(SCRATCH_WRITE)
EMIT3(LRP)
EMIT1(BFREV)
EMIT3(BFE)
EMIT2(BFI1)
EMIT3(BFI2)
EMIT1(FBH)
EMIT1(FBL)
EMIT1(CBIT)
EMIT3(MAD)
EMIT2(ADDC)
EMIT2(SUBB)
#undef EMIT1
#undef EMIT2
#undef EMIT3
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/vec4: Return the emitted instruction in emit_minmax() Needed in the NIR backend to set the "saturate" value of the instruction. Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>
2015-06-17 00:32:58 +02:00
vec4_instruction *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: Return the emitted instruction in emit_lrp() Needed in the NIR backend to set the "saturate" value of the instruction. Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>
2015-06-17 10:01:07 +02:00
vec4_instruction *emit_lrp(const dst_reg &dst, const src_reg &x,
const src_reg &y, const src_reg &a);
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
i965: Fix stride field for the result of emit_uniformize(). This is essentially the same problem fixed in an earlier patch for immediates. Setting the stride to zero will be particularly useful for my future SIMD lowering pass, because we will be able to just check whether the stride of a source register is zero and skip emitting the copies required to unzip it in that case. Instead of setting stride to zero in every caller of emit_uniformize() I've changed the function to return the result as its return value (previously it was being written into a caller-provided destination register), because this way we can enforce that the result is used with the correct regioning from the function itself. The changes to the prototype of its VEC4 counterpart are mainly for the sake of symmetry, VEC4 registers don't have stride. Reviewed-by: Samuel Iglesias Gonsálvez <siglesias@igalia.com>
2015-07-13 15:52:28 +03:00
/**
* Copy any live channel from \p src to the first channel of the
* result.
*/
src_reg emit_uniformize(const src_reg &src);
i965: Define helper function to copy an arbitrary live component from some register. Reviewed-by: Matt Turner <mattst88@gmail.com>
2015-03-20 14:16:09 +02:00
i965/vec4_visitor: Make some function arguments const references Reviewed-by: Matt Turner <mattst88@gmail.com>
2015-08-10 11:48:14 -07:00
src_reg fix_3src_operand(const src_reg &src);
src_reg resolve_source_modifiers(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
i965/vec4: Return the last emitted instruction in emit_math() Needed in the NIR backend to set the "saturate" value of the instruction. Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>
2015-06-17 00:04:09 +02:00
vec4_instruction *emit_math(enum opcode opcode, const dst_reg &dst, const src_reg &src0,
const src_reg &src1 = src_reg());
i965/vec4_visitor: Make some function arguments const references Reviewed-by: Matt Turner <mattst88@gmail.com>
2015-08-10 11:48:14 -07:00
src_reg fix_math_operand(const 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: Optimize unpackUnorm4x8(). Reduces the number of instructions needed to implement unpackUnorm4x8() from 11 -> 4. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2014-03-08 17:29:33 -08:00
void emit_unpack_unorm_4x8(const dst_reg &dst, src_reg src0);
i965/vec4: Optimize unpackSnorm4x8(). Reduces the number of instructions needed to implement unpackSnorm4x8() from 16 -> 6. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2014-03-09 20:22:23 -07:00
void emit_unpack_snorm_4x8(const dst_reg &dst, src_reg src0);
i965/vec4: Optimize packUnorm4x8(). Reduces the number of instructions needed to implement packUnorm4x8() from 11 -> 6.
2014-03-10 13:27:46 -07:00
void emit_pack_unorm_4x8(const dst_reg &dst, const src_reg &src0);
i965/vec4: Optimize packSnorm4x8(). Reduces the number of instructions needed to implement packSnorm4x8() from 13 -> 7.
2014-03-10 14:11:05 -07:00
void emit_pack_snorm_4x8(const dst_reg &dst, const src_reg &src0);
i965/vs/gen7: Emit code for GLSL ES 3.00 pack/unpack operations (v3) FIXME: This patch emits VS code that violates documented hardware restrictions and then relies on undocumented behavior that results from that violation. This patch passes all tests, but should be fixed ASAP to conform to the hardware documentation. v2: Explain undocumented hardware behavior. Improve comments. v3: Use ALU1 helper methods F32TO16() and F16TO32(). [for anholt] Reviewed-by: Eric Anholt <eric@anholt.net> Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> (v1) Signed-off-by: Chad Versace <chad.versace@linux.intel.com>
2013-01-09 11:44:31 -08:00
i965/ir/vec4: Refactor visit(ir_texture *ir) Splitted in two. The emission is moved to a new vec4_visitor method, vec4_visitor::emit_texture, ir order to be reused on the nir path. Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>
2015-07-06 14:33:21 +02:00
void emit_texture(ir_texture_opcode op,
dst_reg dest,
const glsl_type *dest_type,
src_reg coordinate,
int coord_components,
src_reg shadow_comparitor,
src_reg lod, src_reg lod2,
src_reg sample_index,
uint32_t constant_offset,
src_reg offset_value,
src_reg mcs,
bool is_cube_array,
uint32_t sampler, src_reg sampler_reg);
i965/vec4: Change vec4_visitor::emit_mcs_fetch() method to allow reuse This patch changes the signature of emit_mcs_fetch() to accept lower level arguments. The purpose is to reuse it in the upcoming NIR->vec4 pass. Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>
2015-06-18 11:31:54 +02:00
src_reg emit_mcs_fetch(const glsl_type *coordinate_type, 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/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: Handle vertex color clamping in emit_urb_slot(). Vertex color clamping only applies to a few specific built-ins: COL0/1 and BFC0/1 (aka gl_[Secondary]{Front,Back}Color). It seems weird to handle special cases in a function called emit_generic_urb_slot(). emit_urb_slot() is all about handling special cases, so it makes more sense to handle this there. Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Matt Turner <mattst88@gmail.com> Reviewed-by: Chris Forbes <chrisf@ijw.co.nz>
2014-12-01 00:53:02 -08:00
vec4_instruction *emit_generic_urb_slot(dst_reg reg, int varying);
i965: Virtualize vec4_visitor::emit_urb_slot(). This avoids a downcast of key, which won't exist in the base class soon. I'm not a huge fan of this patch, but given that we're currently using inheritance, this seems like the "right" way to do it. The alternative is to make key a void pointer in the parent class and continue downcasting. Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Chris Forbes <chrisf@ijw.co.nz>
2015-08-28 00:29:05 -07:00
virtual 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();
i965: Pull calls to get_shader_time_index out of the visitor Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Chris Forbes <chrisf@ijw.co.nz>
2015-06-19 15:40:09 -07:00
void emit_shader_time_write(int shader_time_subindex, 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/vec4: Preserve CFG in spill_reg(). Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
2014-08-24 19:38:21 -07:00
src_reg get_scratch_offset(bblock_t *block, vec4_instruction *inst,
i965/vs: Move virtual GRFs with array accesses to them to scratch space.
2011-08-07 12:15:26 -07:00
src_reg *reladdr, int reg_offset);
i965/vec4: Preserve CFG in spill_reg(). Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
2014-08-24 19:38:21 -07:00
src_reg get_pull_constant_offset(bblock_t *block, vec4_instruction *inst,
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 *reladdr, int reg_offset);
i965/vec4: Preserve CFG in spill_reg(). Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
2014-08-24 19:38:21 -07:00
void emit_scratch_read(bblock_t *block, vec4_instruction *inst,
i965/vs: Move virtual GRFs with array accesses to them to scratch space.
2011-08-07 12:15:26 -07:00
dst_reg dst,
src_reg orig_src,
int base_offset);
i965/vec4: Preserve CFG in spill_reg(). Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
2014-08-24 19:38:21 -07:00
void emit_scratch_write(bblock_t *block, vec4_instruction *inst,
i965/vs: Move virtual GRFs with array accesses to them to scratch space.
2011-08-07 12:15:26 -07:00
int base_offset);
i965/vec4: Preserve CFG in spill_reg(). Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
2014-08-24 19:38:21 -07:00
void emit_pull_constant_load(bblock_t *block, vec4_instruction *inst,
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
dst_reg dst,
src_reg orig_src,
int base_offset);
i965/vec4: Add a helper function to emit VS_OPCODE_PULL_CONSTANT_LOAD There were three places in the visitor that had a similar chunk of code to emit the VS_OPCODE_PULL_CONSTANT_LOAD opcode using a register for the offset. This patch combines the chunks into a helper function to reduce the code duplication. It will also be useful in the next patch to expand what happens on Gen9+. This shouldn't introduce any functional changes. Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
2015-04-15 14:28:26 +01:00
void emit_pull_constant_load_reg(dst_reg dst,
src_reg surf_index,
src_reg offset,
bblock_t *before_block,
vec4_instruction *before_inst);
i965: Handle scratch accesses where reladdr also points to scratch space This is a problem when we have IR like this: (array_ref (var_ref temps) (swiz x (expression ivec4 bitcast_f2i (swiz xxxx (array_ref (var_ref temps) (constant int (2)) ) )) )) ) ) where we are indexing an array with the result of an expression that accesses the same array. In this scenario, temps will be moved to scratch space and we will need to add scratch reads/writes for all accesses to temps, however, the current implementation does not consider the case where a reladdr pointer (obtained by indexing into temps trough a expression) points to a register that is also stored in scratch space (as in this case, where the expression used to index temps access temps[2]), and thus, requires a scratch read before it is accessed. v2 (Francisco Jerez): - Handle also recursive reladdr addressing. - Do not memcpy dst_reg into src_reg when rewriting reladdr. v3 (Francisco Jerez): - Reduce complexity by moving recursive reladdr scratch access handling to a separate recursive function. - Do not skip demoting reladdr index registers to scratch space if the top level GRF has already been visited. v4 (Francisco Jerez) - Remove redundant checks. - Simplify code by making emit_resolve_reladdr return a register with the original src data except for reg, reg_offset and reladdr. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89508 Reviewed-by: Francisco Jerez <currojerez@riseup.net>
2015-03-17 10:48:04 +01:00
src_reg emit_resolve_reladdr(int scratch_loc[], bblock_t *block,
vec4_instruction *inst, src_reg src);
i965/vs: Move virtual GRFs with array accesses to them to scratch space.
2011-08-07 12:15:26 -07:00
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: 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/vec4: Move is_high_sample() method to vec4_visitor class The is_high_sample() method is currently accessible only in the implementation of vec4_visitor. Since we need to reuse it in the upcoming NIR->vec4 pass, lets make it a method of the class instead. Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>
2015-06-18 09:37:33 +02:00
bool is_high_sampler(src_reg sampler);
i965/vec4: Move type_size() method to brw_vec4_visitor class The type_size() method is currently accessible only in the implementation of vec4_visitor. Since we need to reuse it in the upcoming NIR->vec4 pass, lets make it a method of the class instead. Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>
2015-06-16 13:39:48 +02:00
i965/vec4: Optimize predicate handling for any/all. For a select whose condition is any(v), instead of emitting cmp.nz.f0(8) null<1>D g1<0,4,1>D 0D mov(8) g7<1>.xUD 0x00000000UD (+f0.any4h) mov(8) g7<1>.xUD 0xffffffffUD cmp.nz.f0(8) null<1>D g7<4,4,1>.xD 0D (+f0) sel(8) g8<1>UD g4<4,4,1>UD g3<4,4,1>UD we now emit cmp.nz.f0(8) null<1>D g1<0,4,1>D 0D (+f0.any4h) sel(8) g9<1>UD g4<4,4,1>UD g3<4,4,1>UD Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2015-11-25 21:54:30 -08:00
bool optimize_predicate(nir_alu_instr *instr, enum brw_predicate *predicate);
i965/nir/vec4: Add implementation placeholders for a new NIR->vec4 pass This patch will add a brw_vec4_nir.cpp file filled with entry point methods to the main functionality, following a structure similar to brw_fs_nir.cpp. Subsequent patches in this series will be adding the implementations for these methods, incrementally. Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>
2015-06-16 12:08:09 +02:00
virtual void emit_nir_code();
i965/backend_shader: Add a field to store the NIR shader Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2015-10-01 12:23:53 -07:00
virtual void nir_setup_uniforms();
i965/nir/vec4: Add setup for system values Similar to other variable setups, system values will initialize the corresponding register inside a 'nir_system_values' map, which will then be queried later when processing the different system value intrinsics for the appropriate register. Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>
2015-06-16 17:08:04 +02:00
virtual void nir_setup_system_value_intrinsic(nir_intrinsic_instr *instr);
i965/backend_shader: Add a field to store the NIR shader Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2015-10-01 12:23:53 -07:00
virtual void nir_setup_system_values();
i965/nir/vec4: Add implementation placeholders for a new NIR->vec4 pass This patch will add a brw_vec4_nir.cpp file filled with entry point methods to the main functionality, following a structure similar to brw_fs_nir.cpp. Subsequent patches in this series will be adding the implementations for these methods, incrementally. Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>
2015-06-16 12:08:09 +02:00
virtual void nir_emit_impl(nir_function_impl *impl);
virtual void nir_emit_cf_list(exec_list *list);
virtual void nir_emit_if(nir_if *if_stmt);
virtual void nir_emit_loop(nir_loop *loop);
virtual void nir_emit_block(nir_block *block);
virtual void nir_emit_instr(nir_instr *instr);
virtual void nir_emit_load_const(nir_load_const_instr *instr);
virtual void nir_emit_intrinsic(nir_intrinsic_instr *instr);
virtual void nir_emit_alu(nir_alu_instr *instr);
virtual void nir_emit_jump(nir_jump_instr *instr);
virtual void nir_emit_texture(nir_tex_instr *instr);
i965/vec4_nir: Use partial SSA form rather than full non-SSA We made this switch in the FS backend some time ago and it seems to make a number of things a bit easier. In particular, supporting SSA values takes very little work in the backend and allows us to take advantage of the majority of the SSA information even after we've gotten rid of Phi nodes. Reviewed-by: Eduardo Lima Mitev <elima@igalia.com>
2015-09-09 13:55:39 -07:00
virtual void nir_emit_undef(nir_ssa_undef_instr *instr);
i965/nir/vec4: Implement nir_intrinsic_ssbo_atomic_* Reviewed-by: Kristian Høgsberg <krh@bitplanet.net>
2015-08-07 11:31:13 +02:00
virtual void nir_emit_ssbo_atomic(int op, nir_intrinsic_instr *instr);
i965/nir/vec4: Add implementation placeholders for a new NIR->vec4 pass This patch will add a brw_vec4_nir.cpp file filled with entry point methods to the main functionality, following a structure similar to brw_fs_nir.cpp. Subsequent patches in this series will be adding the implementations for these methods, incrementally. Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>
2015-06-16 12:08:09 +02:00
i965/nir/vec4: Add get_nir_dst() and get_nir_src() methods These methods are essential for the implementation of the NIR->vec4 pass. They work similar to their fs_nir counter-parts. When processing instructions, these methods are invoked to resolve the brw registers (source or destination) corresponding to the NIR sources or destination. It uses the map of NIR register index to brw register for all registers locally allocated in a block. Signed-off-by: Samuel Iglesias Gonsalvez <siglesias@igalia.com> Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>
2015-06-16 17:43:02 +02:00
dst_reg get_nir_dest(nir_dest dest, enum brw_reg_type type);
dst_reg get_nir_dest(nir_dest dest, nir_alu_type type);
dst_reg get_nir_dest(nir_dest dest);
src_reg get_nir_src(nir_src src, enum brw_reg_type type,
unsigned num_components = 4);
src_reg get_nir_src(nir_src src, nir_alu_type type,
unsigned num_components = 4);
src_reg get_nir_src(nir_src src,
unsigned num_components = 4);
i965: Add tessellation control shaders. The TCS is the first tessellation shader stage, and the most complicated. It has access to each of the control points in the input patch, and computes a new output patch. There is one logical invocation per output control point; all invocations run in parallel, and can communicate by reading and writing output variables. One of the main responsibilities of the TCS is to write the special gl_TessLevelOuter[] and gl_TessLevelInner[] output variables which control how much new geometry the hardware tessellation engine will produce. Otherwise, it simply writes outputs that are passed along to the TES. We run in SIMD4x2 mode, handling two logical invocations per EU thread. The hardware doesn't properly manage the dispatch mask for us; it always initializes it to 0xFF. We wrap the whole program in an IF..ENDIF block to handle an odd number of invocations, essentially falling back to SIMD4x1 on the last thread. v2: Update comments (requested by Jordan Justen). Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
2015-11-17 01:07:39 -08:00
src_reg get_indirect_offset(nir_intrinsic_instr *instr);
i965/nir/vec4: Add get_nir_dst() and get_nir_src() methods These methods are essential for the implementation of the NIR->vec4 pass. They work similar to their fs_nir counter-parts. When processing instructions, these methods are invoked to resolve the brw registers (source or destination) corresponding to the NIR sources or destination. It uses the map of NIR register index to brw register for all registers locally allocated in a block. Signed-off-by: Samuel Iglesias Gonsalvez <siglesias@igalia.com> Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>
2015-06-16 17:43:02 +02:00
i965/vec4: Redefine make_reg_for_system_value() to allow reuse in NIR->vec4 pass The new virtual method is more flexible, it has a signature: dst_reg *make_reg_for_system_value(int location, const glsl_type *type); v2 (Jason Ekstrand): Use the new version in unit tests so make check passes again Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>
2015-06-16 17:01:29 +02:00
virtual dst_reg *make_reg_for_system_value(int location,
const glsl_type *type) = 0;
i965/nir/vec4: Add shader function implementation It basically allocates registers local to a function in a nir_locals map, then emits all its control-flow blocks. Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>
2015-07-22 09:34:35 +02:00
dst_reg *nir_locals;
i965/nir/vec4: Implement load_const intrinsic Similar to fs_nir backend, a nir_local_values map will be filled with newly allocated registers as the load_const instrinsic instructions are processed. Later, get_nir_src() will fetch the registers from this map for sources that are ssa. Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>
2015-07-01 16:10:49 +02:00
dst_reg *nir_ssa_values;
i965/nir/vec4: Add setup for system values Similar to other variable setups, system values will initialize the corresponding register inside a 'nir_system_values' map, which will then be queried later when processing the different system value intrinsics for the appropriate register. Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>
2015-06-16 17:08:04 +02:00
dst_reg *nir_system_values;
i965/nir/vec4: Add setup of input variables in NIR->vec4 pass This implementation sets up a map of input variable offsets to source registers that are already initialized with the corresponding register offset. This map will then be queried when processing load_input intrinsic operations, to obtain the correct register source from which the input data will be loaded. Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>
2015-06-16 13:50:43 +02:00
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/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_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/gs: Refactor ir_emit_vertex and ir_end_primitive So the implementation is independent of GLSL IR and the visit methods of the vec4 visitor. This way we will be able to reuse that implementation directly from the NIR vec4 backend. Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>
2015-06-29 13:37:31 +02:00
virtual void gs_emit_vertex(int stream_id);
virtual void gs_end_primitive();
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
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
i965: Pull calls to get_shader_time_index out of the visitor Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Chris Forbes <chrisf@ijw.co.nz>
2015-06-19 15:40:09 -07:00
int shader_time_index;
i965/vec4: Move c->last_scratch into vec4_visitor. Nothing outside of vec4_visitor uses it, so we may as well keep it internal. Commit db9c915abcc5ad78d2d11d0e732f04cc94631350 for the vec4 backend. (The empty class will be going away soon.) Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
2015-06-28 21:02:15 -07:00
unsigned last_scratch; /**< measured in 32-byte (register size) units */
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: Start adding the VS visitor and codegen. The low-level IR is a mashup of brw_fs.cpp and ir_to_mesa.cpp. It's currently controlled by the INTEL_NEW_VS=1 environment variable, and only tested for the trivial "gl_Position = gl_Vertex;" shader so far.
2011-05-02 09:45:40 -07:00
} /* namespace brw */
i965: Make brw_{shader,vec4}.h safe to include from C. The patch that follows will move the definition of struct brw_vec4_prog_key from brw_vs.h to brw_vec4.h, making it necessary for brw_vs.h to include brw_vec4.h (because brw_vs.h defines struct brw_vs_prog_key, which contains brw_vec4_prog_key as a member). Since brw_vs.h is included from C source files, that means that brw_vec4.h will need to be safe to include from C. Same for brw_shader.h, since it is included by brw_vec4.h. Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Matt Turner <mattst88@gmail.com>
2013-08-21 07:53:42 -07:00
#endif /* __cplusplus */
i965: Start adding the VS visitor and codegen. The low-level IR is a mashup of brw_fs.cpp and ir_to_mesa.cpp. It's currently controlled by the INTEL_NEW_VS=1 environment variable, and only tested for the trivial "gl_Position = gl_Vertex;" shader so far.
2011-05-02 09:45:40 -07:00
#endif /* BRW_VEC4_H */
Reference in New Issue Copy Permalink