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

1308 lines
38 KiB
C++
Raw Normal View History

i965/fs: Split the BRW native code emit to brw_fs_emit.cpp This is all separate from the visitor and the optimization passes which feed into it. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2011-05-24 16:34:27 -07:00
/*
* Copyright © 2010 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.
*/
/** @file brw_fs_emit.cpp
*
* This file supports emitting code from the FS LIR to the actual
* native instructions.
*/
extern "C" {
#include "main/macros.h"
#include "brw_context.h"
#include "brw_eu.h"
} /* extern "C" */
#include "brw_fs.h"
i965: Move brw_fs_cfg.* to brw_cfg.*. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2012-10-03 13:03:12 -07:00
#include "brw_cfg.h"
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_print_visitor.h"
i965/fs: Split the BRW native code emit to brw_fs_emit.cpp This is all separate from the visitor and the optimization passes which feed into it. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2011-05-24 16:34:27 -07:00
i965/fs: Split final assembly code generation out of fs_visitor. Compiling shaders requires several main steps: 1. Generating FS 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 "fs_generator." There are several reasons for doing so: 1. Future hardware has a different instruction encoding. Splitting this out will allow us to replace fs_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 fs_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 fs_visitor and create IR, while ADD() in fs_generator() can create brw_instructions. (Patches for this upcoming.) Furthermore, this patch changes the order of operations slightly. Rather than doing steps 1-4 for SIMD8, then 1-4 for SIMD16, we now: - Do steps 1-3 for SIMD8, then repeat 1-3 for SIMD16 - Generate final assembly code for both modes together This is because the frontend work can be done independently, but final assembly generation needs to pack both into a single program store to feed the GPU. Reviewed-by: Eric Anholt <eric@anholt.net> Reviewed-by: Paul Berry <stereotype441@gmail.com>
2012-11-09 01:05:47 -08:00
fs_generator::fs_generator(struct brw_context *brw,
struct brw_wm_compile *c,
struct gl_shader_program *prog,
struct gl_fragment_program *fp,
bool dual_source_output)
: brw(brw), c(c), prog(prog), fp(fp), dual_source_output(dual_source_output)
{
intel = &brw->intel;
ctx = &intel->ctx;
shader = prog ? prog->_LinkedShaders[MESA_SHADER_FRAGMENT] : NULL;
mem_ctx = c;
i965/fs: Move struct brw_compile (p) entirely inside fs_generator. The brw_compile structure contains the brw_instruction store and the brw_eu_emit.c state tracking fields. These are only useful for the final assembly generation pass; the earlier compilation stages doesn't need them. This also means that the code generator for future hardware won't have access to the brw_compile structure, which is extremely desirable because it prevents accidental generation of Gen4-7 code. v2: rzalloc p, as suggested by Eric. Reviewed-by: Eric Anholt <eric@anholt.net> Reviewed-by: Paul Berry <stereotype441@gmail.com>
2012-11-20 19:26:52 -08:00
p = rzalloc(mem_ctx, struct brw_compile);
brw_init_compile(brw, p, mem_ctx);
i965/fs: Split final assembly code generation out of fs_visitor. Compiling shaders requires several main steps: 1. Generating FS 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 "fs_generator." There are several reasons for doing so: 1. Future hardware has a different instruction encoding. Splitting this out will allow us to replace fs_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 fs_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 fs_visitor and create IR, while ADD() in fs_generator() can create brw_instructions. (Patches for this upcoming.) Furthermore, this patch changes the order of operations slightly. Rather than doing steps 1-4 for SIMD8, then 1-4 for SIMD16, we now: - Do steps 1-3 for SIMD8, then repeat 1-3 for SIMD16 - Generate final assembly code for both modes together This is because the frontend work can be done independently, but final assembly generation needs to pack both into a single program store to feed the GPU. Reviewed-by: Eric Anholt <eric@anholt.net> Reviewed-by: Paul Berry <stereotype441@gmail.com>
2012-11-09 01:05:47 -08:00
}
fs_generator::~fs_generator()
{
}
i965/fs: Improve performance of shaders that start out with a discard. I had tried this in the past, but ran into trouble with applications that sample from undiscarded pixels in the same subspan. To fix that issue, only jump to the end for an entire subspan at a time. Improves GLbenchmark 2.7 (1024x768) performance by 7.9 +/- 1.5% (n=8). v2: Drop the br variable in the jump instruction -- if I ever do jumps pre-gen6, it'll be a different code block anyway since we don't have HALT until gen6. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2012-12-06 10:15:08 -08:00
void
fs_generator::patch_discard_jumps_to_fb_writes()
{
if (intel->gen < 6 || this->discard_halt_patches.is_empty())
return;
/* There is a somewhat strange undocumented requirement of using
* HALT, according to the simulator. If some channel has HALTed to
* a particular UIP, then by the end of the program, every channel
* must have HALTed to that UIP. Furthermore, the tracking is a
* stack, so you can't do the final halt of a UIP after starting
* halting to a new UIP.
*
* Symptoms of not emitting this instruction on actual hardware
* included GPU hangs and sparkly rendering on the piglit discard
* tests.
*/
struct brw_instruction *last_halt = gen6_HALT(p);
last_halt->bits3.break_cont.uip = 2;
last_halt->bits3.break_cont.jip = 2;
int ip = p->nr_insn;
foreach_list(node, &this->discard_halt_patches) {
ip_record *patch_ip = (ip_record *)node;
struct brw_instruction *patch = &p->store[patch_ip->ip];
assert(patch->header.opcode == BRW_OPCODE_HALT);
/* HALT takes a half-instruction distance from the pre-incremented IP. */
patch->bits3.break_cont.uip = (ip - patch_ip->ip) * 2;
}
this->discard_halt_patches.make_empty();
}
i965/fs: Split the BRW native code emit to brw_fs_emit.cpp This is all separate from the visitor and the optimization passes which feed into it. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2011-05-24 16:34:27 -07:00
void
i965/fs: Split final assembly code generation out of fs_visitor. Compiling shaders requires several main steps: 1. Generating FS 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 "fs_generator." There are several reasons for doing so: 1. Future hardware has a different instruction encoding. Splitting this out will allow us to replace fs_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 fs_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 fs_visitor and create IR, while ADD() in fs_generator() can create brw_instructions. (Patches for this upcoming.) Furthermore, this patch changes the order of operations slightly. Rather than doing steps 1-4 for SIMD8, then 1-4 for SIMD16, we now: - Do steps 1-3 for SIMD8, then repeat 1-3 for SIMD16 - Generate final assembly code for both modes together This is because the frontend work can be done independently, but final assembly generation needs to pack both into a single program store to feed the GPU. Reviewed-by: Eric Anholt <eric@anholt.net> Reviewed-by: Paul Berry <stereotype441@gmail.com>
2012-11-09 01:05:47 -08:00
fs_generator::generate_fb_write(fs_inst *inst)
i965/fs: Split the BRW native code emit to brw_fs_emit.cpp This is all separate from the visitor and the optimization passes which feed into it. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2011-05-24 16:34:27 -07:00
{
intel: Convert from GLboolean to 'bool' from stdbool.h. I initially produced the patch using this bash command: for file in {intel,i915,i965}/*.{c,cpp,h}; do [ ! -h $file ] && sed -i 's/GLboolean/bool/g' $file && sed -i 's/GL_TRUE/true/g' $file && sed -i 's/GL_FALSE/false/g' $file; done Then I manually added #include <stdbool.h> to fix compilation errors, and converted a few functions back to GLboolean that were used in core Mesa's function pointer table to avoid "incompatible pointer" warnings. Finally, I cleaned up some whitespace issues introduced by the change. Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Acked-by: Chad Versace <chad@chad-versace.us> Acked-by: Paul Berry <stereotype441@gmail.com>
2011-10-07 12:26:50 -07:00
bool eot = inst->eot;
i965/fs: Split the BRW native code emit to brw_fs_emit.cpp This is all separate from the visitor and the optimization passes which feed into it. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2011-05-24 16:34:27 -07:00
struct brw_reg implied_header;
i965/gen6+: Add support for GL_ARB_blend_func_extended. v2: Add support for gen6, and don't turn it on if blending is disabled. (fixes GPU hang), and note it in docs/GL3.txt Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2012-04-25 13:58:07 -07:00
uint32_t msg_control;
i965/fs: Split the BRW native code emit to brw_fs_emit.cpp This is all separate from the visitor and the optimization passes which feed into it. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2011-05-24 16:34:27 -07:00
i965/fs: Improve performance of shaders that start out with a discard. I had tried this in the past, but ran into trouble with applications that sample from undiscarded pixels in the same subspan. To fix that issue, only jump to the end for an entire subspan at a time. Improves GLbenchmark 2.7 (1024x768) performance by 7.9 +/- 1.5% (n=8). v2: Drop the br variable in the jump instruction -- if I ever do jumps pre-gen6, it'll be a different code block anyway since we don't have HALT until gen6. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2012-12-06 10:15:08 -08:00
/* Note that the jumps emitted to this point mean that the g0 ->
* base_mrf setup must be inside of this function, so that we jump
* to a point containing it.
*/
patch_discard_jumps_to_fb_writes();
i965/fs: Split the BRW native code emit to brw_fs_emit.cpp This is all separate from the visitor and the optimization passes which feed into it. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2011-05-24 16:34:27 -07:00
/* Header is 2 regs, g0 and g1 are the contents. g0 will be implied
* move, here's g1.
*/
brw_push_insn_state(p);
brw_set_mask_control(p, BRW_MASK_DISABLE);
brw_set_compression_control(p, BRW_COMPRESSION_NONE);
i965/fs: Rewrite discards to use a flag subreg to track discarded pixels. This makes much more sense on gen6+, and will also prove useful for early exit of shaders on discard. v2: fix up a stale comment from before converting gen4-5. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2012-12-06 12:15:13 -08:00
if (fp->UsesKill) {
struct brw_reg pixel_mask;
if (intel->gen >= 6)
pixel_mask = retype(brw_vec1_grf(1, 7), BRW_REGISTER_TYPE_UW);
else
pixel_mask = retype(brw_vec1_grf(0, 0), BRW_REGISTER_TYPE_UW);
brw_MOV(p, pixel_mask, brw_flag_reg(0, 1));
}
i965/fs: Split the BRW native code emit to brw_fs_emit.cpp This is all separate from the visitor and the optimization passes which feed into it. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2011-05-24 16:34:27 -07:00
if (inst->header_present) {
if (intel->gen >= 6) {
brw_set_compression_control(p, BRW_COMPRESSION_COMPRESSED);
brw_MOV(p,
retype(brw_message_reg(inst->base_mrf), BRW_REGISTER_TYPE_UD),
retype(brw_vec8_grf(0, 0), BRW_REGISTER_TYPE_UD));
brw_set_compression_control(p, BRW_COMPRESSION_NONE);
i965/msaa: Add sample-alpha-to-coverage support for multiple render targets Render Target Write message should include source zero alpha value when sample-alpha-to-coverage is enabled for an FBO with multiple render targets. Source zero alpha value is used as fragment coverage for all the render targets. This patch makes piglit tests draw-buffers-alpha-to-coverage and alpha-to-coverage-no-draw-buffer-zero to pass on Sandybridge. No regressions are observed with piglit all.tests. V2: Revert all the changes made in emit_color_write() function to include src0 alpha for targets > 0. Now handling this case in a if block. V3: Correctly calculate the instruction length for buffer zero. Properly handle the case of dual_src_blend when alpha-to-coverage is enabled. Signed-off-by: Anuj Phogat <anuj.phogat@gmail.com> Reviewed-by: Paul Berry <stereotype441@gmail.com>
2012-08-01 16:32:06 -07:00
if (inst->target > 0 &&
c->key.nr_color_regions > 1 &&
c->key.sample_alpha_to_coverage) {
/* Set "Source0 Alpha Present to RenderTarget" bit in message
* header.
*/
brw_OR(p,
vec1(retype(brw_message_reg(inst->base_mrf), BRW_REGISTER_TYPE_UD)),
vec1(retype(brw_vec8_grf(0, 0), BRW_REGISTER_TYPE_UD)),
brw_imm_ud(0x1 << 11));
}
i965/fs: Split the BRW native code emit to brw_fs_emit.cpp This is all separate from the visitor and the optimization passes which feed into it. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2011-05-24 16:34:27 -07:00
if (inst->target > 0) {
/* Set the render target index for choosing BLEND_STATE. */
i965/fs: Fix MRT drawing since the m0->m2 move for shader debug. Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
2011-07-25 15:39:03 -07:00
brw_MOV(p, retype(brw_vec1_reg(BRW_MESSAGE_REGISTER_FILE,
inst->base_mrf, 2),
i965/fs: Split the BRW native code emit to brw_fs_emit.cpp This is all separate from the visitor and the optimization passes which feed into it. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2011-05-24 16:34:27 -07:00
BRW_REGISTER_TYPE_UD),
brw_imm_ud(inst->target));
}
implied_header = brw_null_reg();
} else {
implied_header = retype(brw_vec8_grf(0, 0), BRW_REGISTER_TYPE_UW);
brw_MOV(p,
brw_message_reg(inst->base_mrf + 1),
brw_vec8_grf(1, 0));
}
} else {
implied_header = brw_null_reg();
}
i965/fs: Split final assembly code generation out of fs_visitor. Compiling shaders requires several main steps: 1. Generating FS 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 "fs_generator." There are several reasons for doing so: 1. Future hardware has a different instruction encoding. Splitting this out will allow us to replace fs_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 fs_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 fs_visitor and create IR, while ADD() in fs_generator() can create brw_instructions. (Patches for this upcoming.) Furthermore, this patch changes the order of operations slightly. Rather than doing steps 1-4 for SIMD8, then 1-4 for SIMD16, we now: - Do steps 1-3 for SIMD8, then repeat 1-3 for SIMD16 - Generate final assembly code for both modes together This is because the frontend work can be done independently, but final assembly generation needs to pack both into a single program store to feed the GPU. Reviewed-by: Eric Anholt <eric@anholt.net> Reviewed-by: Paul Berry <stereotype441@gmail.com>
2012-11-09 01:05:47 -08:00
if (this->dual_source_output)
i965/gen6+: Add support for GL_ARB_blend_func_extended. v2: Add support for gen6, and don't turn it on if blending is disabled. (fixes GPU hang), and note it in docs/GL3.txt Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2012-04-25 13:58:07 -07:00
msg_control = BRW_DATAPORT_RENDER_TARGET_WRITE_SIMD8_DUAL_SOURCE_SUBSPAN01;
i965/fs: Move brw_wm_compile::dispatch_width into fs_visitor. Also, rather than having brw_wm_fs_emit poke at it directly, make it a parameter to the fs_visitor constructor. All other changes generated by search and replace (with occasional whitespace fixup). v2: Make dispatch_width const (as suggested by Paul); fix doxygen mistake (pointed out by Eric); update for rebase. Reviewed-by: Eric Anholt <eric@anholt.net> Reviewed-by: Paul Berry <stereotype441@gmail.com>
2012-11-20 13:50:52 -08:00
else if (dispatch_width == 16)
i965/gen6+: Add support for GL_ARB_blend_func_extended. v2: Add support for gen6, and don't turn it on if blending is disabled. (fixes GPU hang), and note it in docs/GL3.txt Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2012-04-25 13:58:07 -07:00
msg_control = BRW_DATAPORT_RENDER_TARGET_WRITE_SIMD16_SINGLE_SOURCE;
else
msg_control = BRW_DATAPORT_RENDER_TARGET_WRITE_SIMD8_SINGLE_SOURCE_SUBSPAN01;
i965/fs: Split the BRW native code emit to brw_fs_emit.cpp This is all separate from the visitor and the optimization passes which feed into it. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2011-05-24 16:34:27 -07:00
brw_pop_insn_state(p);
brw_fb_WRITE(p,
i965/fs: Move brw_wm_compile::dispatch_width into fs_visitor. Also, rather than having brw_wm_fs_emit poke at it directly, make it a parameter to the fs_visitor constructor. All other changes generated by search and replace (with occasional whitespace fixup). v2: Make dispatch_width const (as suggested by Paul); fix doxygen mistake (pointed out by Eric); update for rebase. Reviewed-by: Eric Anholt <eric@anholt.net> Reviewed-by: Paul Berry <stereotype441@gmail.com>
2012-11-20 13:50:52 -08:00
dispatch_width,
i965/fs: Split the BRW native code emit to brw_fs_emit.cpp This is all separate from the visitor and the optimization passes which feed into it. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2011-05-24 16:34:27 -07:00
inst->base_mrf,
implied_header,
i965/gen6+: Add support for GL_ARB_blend_func_extended. v2: Add support for gen6, and don't turn it on if blending is disabled. (fixes GPU hang), and note it in docs/GL3.txt Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2012-04-25 13:58:07 -07:00
msg_control,
i965/fs: Split the BRW native code emit to brw_fs_emit.cpp This is all separate from the visitor and the optimization passes which feed into it. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2011-05-24 16:34:27 -07:00
inst->target,
inst->mlen,
0,
eot,
inst->header_present);
}
/* Computes the integer pixel x,y values from the origin.
*
* This is the basis of gl_FragCoord computation, but is also used
* pre-gen6 for computing the deltas from v0 for computing
* interpolation.
*/
void
i965/fs: Split final assembly code generation out of fs_visitor. Compiling shaders requires several main steps: 1. Generating FS 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 "fs_generator." There are several reasons for doing so: 1. Future hardware has a different instruction encoding. Splitting this out will allow us to replace fs_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 fs_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 fs_visitor and create IR, while ADD() in fs_generator() can create brw_instructions. (Patches for this upcoming.) Furthermore, this patch changes the order of operations slightly. Rather than doing steps 1-4 for SIMD8, then 1-4 for SIMD16, we now: - Do steps 1-3 for SIMD8, then repeat 1-3 for SIMD16 - Generate final assembly code for both modes together This is because the frontend work can be done independently, but final assembly generation needs to pack both into a single program store to feed the GPU. Reviewed-by: Eric Anholt <eric@anholt.net> Reviewed-by: Paul Berry <stereotype441@gmail.com>
2012-11-09 01:05:47 -08:00
fs_generator::generate_pixel_xy(struct brw_reg dst, bool is_x)
i965/fs: Split the BRW native code emit to brw_fs_emit.cpp This is all separate from the visitor and the optimization passes which feed into it. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2011-05-24 16:34:27 -07:00
{
struct brw_reg g1_uw = retype(brw_vec1_grf(1, 0), BRW_REGISTER_TYPE_UW);
struct brw_reg src;
struct brw_reg deltas;
if (is_x) {
src = stride(suboffset(g1_uw, 4), 2, 4, 0);
deltas = brw_imm_v(0x10101010);
} else {
src = stride(suboffset(g1_uw, 5), 2, 4, 0);
deltas = brw_imm_v(0x11001100);
}
i965/fs: Move brw_wm_compile::dispatch_width into fs_visitor. Also, rather than having brw_wm_fs_emit poke at it directly, make it a parameter to the fs_visitor constructor. All other changes generated by search and replace (with occasional whitespace fixup). v2: Make dispatch_width const (as suggested by Paul); fix doxygen mistake (pointed out by Eric); update for rebase. Reviewed-by: Eric Anholt <eric@anholt.net> Reviewed-by: Paul Berry <stereotype441@gmail.com>
2012-11-20 13:50:52 -08:00
if (dispatch_width == 16) {
i965/fs: Split the BRW native code emit to brw_fs_emit.cpp This is all separate from the visitor and the optimization passes which feed into it. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2011-05-24 16:34:27 -07:00
dst = vec16(dst);
}
/* We do this 8 or 16-wide, but since the destination is UW we
* don't do compression in the 16-wide case.
*/
brw_push_insn_state(p);
brw_set_compression_control(p, BRW_COMPRESSION_NONE);
brw_ADD(p, dst, src, deltas);
brw_pop_insn_state(p);
}
void
i965/fs: Split final assembly code generation out of fs_visitor. Compiling shaders requires several main steps: 1. Generating FS 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 "fs_generator." There are several reasons for doing so: 1. Future hardware has a different instruction encoding. Splitting this out will allow us to replace fs_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 fs_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 fs_visitor and create IR, while ADD() in fs_generator() can create brw_instructions. (Patches for this upcoming.) Furthermore, this patch changes the order of operations slightly. Rather than doing steps 1-4 for SIMD8, then 1-4 for SIMD16, we now: - Do steps 1-3 for SIMD8, then repeat 1-3 for SIMD16 - Generate final assembly code for both modes together This is because the frontend work can be done independently, but final assembly generation needs to pack both into a single program store to feed the GPU. Reviewed-by: Eric Anholt <eric@anholt.net> Reviewed-by: Paul Berry <stereotype441@gmail.com>
2012-11-09 01:05:47 -08:00
fs_generator::generate_linterp(fs_inst *inst,
i965/fs: Split the BRW native code emit to brw_fs_emit.cpp This is all separate from the visitor and the optimization passes which feed into it. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2011-05-24 16:34:27 -07:00
struct brw_reg dst, struct brw_reg *src)
{
struct brw_reg delta_x = src[0];
struct brw_reg delta_y = src[1];
struct brw_reg interp = src[2];
if (brw->has_pln &&
delta_y.nr == delta_x.nr + 1 &&
(intel->gen >= 6 || (delta_x.nr & 1) == 0)) {
brw_PLN(p, dst, interp, delta_x);
} else {
brw_LINE(p, brw_null_reg(), interp, delta_x);
brw_MAC(p, dst, suboffset(interp, 1), delta_y);
}
}
i965: Enable faster workaround-free math on Ivybridge. According to the documentation, Ivybridge's math instruction works in SIMD16 mode for the fragment shader, and no longer forbids align16 mode for the vertex shader. The documentation claims that SIMD16 mode isn't supported for INT DIV, but empirical evidence shows that it works fine. Presumably the note is trying to warn us that the variant that returns both quotient and remainder in (dst, dst + 1) doesn't work in SIMD16 mode since dst + 1 would be sechalf(dst), trashing half your results. Since we don't use that variant, we don't care and can just enable SIMD16 everywhere. The documentation also still claims that source modifiers and conditional modifiers aren't supported, but empirical evidence and study of the simulator both show that they work just fine. Goodbye workarounds. Math just works now. Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Paul Berry <stereotype441@gmail.com>
2011-10-18 12:24:47 -07:00
void
i965/fs: Split final assembly code generation out of fs_visitor. Compiling shaders requires several main steps: 1. Generating FS 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 "fs_generator." There are several reasons for doing so: 1. Future hardware has a different instruction encoding. Splitting this out will allow us to replace fs_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 fs_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 fs_visitor and create IR, while ADD() in fs_generator() can create brw_instructions. (Patches for this upcoming.) Furthermore, this patch changes the order of operations slightly. Rather than doing steps 1-4 for SIMD8, then 1-4 for SIMD16, we now: - Do steps 1-3 for SIMD8, then repeat 1-3 for SIMD16 - Generate final assembly code for both modes together This is because the frontend work can be done independently, but final assembly generation needs to pack both into a single program store to feed the GPU. Reviewed-by: Eric Anholt <eric@anholt.net> Reviewed-by: Paul Berry <stereotype441@gmail.com>
2012-11-09 01:05:47 -08:00
fs_generator::generate_math1_gen7(fs_inst *inst,
i965: Enable faster workaround-free math on Ivybridge. According to the documentation, Ivybridge's math instruction works in SIMD16 mode for the fragment shader, and no longer forbids align16 mode for the vertex shader. The documentation claims that SIMD16 mode isn't supported for INT DIV, but empirical evidence shows that it works fine. Presumably the note is trying to warn us that the variant that returns both quotient and remainder in (dst, dst + 1) doesn't work in SIMD16 mode since dst + 1 would be sechalf(dst), trashing half your results. Since we don't use that variant, we don't care and can just enable SIMD16 everywhere. The documentation also still claims that source modifiers and conditional modifiers aren't supported, but empirical evidence and study of the simulator both show that they work just fine. Goodbye workarounds. Math just works now. Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Paul Berry <stereotype441@gmail.com>
2011-10-18 12:24:47 -07:00
struct brw_reg dst,
struct brw_reg src0)
{
assert(inst->mlen == 0);
brw_math(p, dst,
brw_math_function(inst->opcode),
0, src0,
BRW_MATH_DATA_VECTOR,
BRW_MATH_PRECISION_FULL);
}
void
i965/fs: Split final assembly code generation out of fs_visitor. Compiling shaders requires several main steps: 1. Generating FS 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 "fs_generator." There are several reasons for doing so: 1. Future hardware has a different instruction encoding. Splitting this out will allow us to replace fs_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 fs_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 fs_visitor and create IR, while ADD() in fs_generator() can create brw_instructions. (Patches for this upcoming.) Furthermore, this patch changes the order of operations slightly. Rather than doing steps 1-4 for SIMD8, then 1-4 for SIMD16, we now: - Do steps 1-3 for SIMD8, then repeat 1-3 for SIMD16 - Generate final assembly code for both modes together This is because the frontend work can be done independently, but final assembly generation needs to pack both into a single program store to feed the GPU. Reviewed-by: Eric Anholt <eric@anholt.net> Reviewed-by: Paul Berry <stereotype441@gmail.com>
2012-11-09 01:05:47 -08:00
fs_generator::generate_math2_gen7(fs_inst *inst,
i965: Enable faster workaround-free math on Ivybridge. According to the documentation, Ivybridge's math instruction works in SIMD16 mode for the fragment shader, and no longer forbids align16 mode for the vertex shader. The documentation claims that SIMD16 mode isn't supported for INT DIV, but empirical evidence shows that it works fine. Presumably the note is trying to warn us that the variant that returns both quotient and remainder in (dst, dst + 1) doesn't work in SIMD16 mode since dst + 1 would be sechalf(dst), trashing half your results. Since we don't use that variant, we don't care and can just enable SIMD16 everywhere. The documentation also still claims that source modifiers and conditional modifiers aren't supported, but empirical evidence and study of the simulator both show that they work just fine. Goodbye workarounds. Math just works now. Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Paul Berry <stereotype441@gmail.com>
2011-10-18 12:24:47 -07:00
struct brw_reg dst,
struct brw_reg src0,
struct brw_reg src1)
{
assert(inst->mlen == 0);
brw_math2(p, dst, brw_math_function(inst->opcode), src0, src1);
}
i965/fs: Split the BRW native code emit to brw_fs_emit.cpp This is all separate from the visitor and the optimization passes which feed into it. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2011-05-24 16:34:27 -07:00
void
i965/fs: Split final assembly code generation out of fs_visitor. Compiling shaders requires several main steps: 1. Generating FS 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 "fs_generator." There are several reasons for doing so: 1. Future hardware has a different instruction encoding. Splitting this out will allow us to replace fs_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 fs_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 fs_visitor and create IR, while ADD() in fs_generator() can create brw_instructions. (Patches for this upcoming.) Furthermore, this patch changes the order of operations slightly. Rather than doing steps 1-4 for SIMD8, then 1-4 for SIMD16, we now: - Do steps 1-3 for SIMD8, then repeat 1-3 for SIMD16 - Generate final assembly code for both modes together This is because the frontend work can be done independently, but final assembly generation needs to pack both into a single program store to feed the GPU. Reviewed-by: Eric Anholt <eric@anholt.net> Reviewed-by: Paul Berry <stereotype441@gmail.com>
2012-11-09 01:05:47 -08:00
fs_generator::generate_math1_gen6(fs_inst *inst,
i965/fs: Split generate_math into gen4/gen6 and 1/2 operand variants. This mirrors the structure Eric used in the new VS backend, and seems simpler. In particular, the math1/math2 split will avoid having to figure out how many operands there are, as this is already known by the caller. Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Eric Anholt <eric@anholt.net>
2011-08-18 11:55:42 -07:00
struct brw_reg dst,
struct brw_reg src0)
i965/fs: Split the BRW native code emit to brw_fs_emit.cpp This is all separate from the visitor and the optimization passes which feed into it. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2011-05-24 16:34:27 -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
int op = brw_math_function(inst->opcode);
i965/fs: Split the BRW native code emit to brw_fs_emit.cpp This is all separate from the visitor and the optimization passes which feed into it. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2011-05-24 16:34:27 -07:00
i965/fs: Split generate_math into gen4/gen6 and 1/2 operand variants. This mirrors the structure Eric used in the new VS backend, and seems simpler. In particular, the math1/math2 split will avoid having to figure out how many operands there are, as this is already known by the caller. Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Eric Anholt <eric@anholt.net>
2011-08-18 11:55:42 -07:00
assert(inst->mlen == 0);
i965/fs: Split the BRW native code emit to brw_fs_emit.cpp This is all separate from the visitor and the optimization passes which feed into it. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2011-05-24 16:34:27 -07:00
i965/fs: Split generate_math into gen4/gen6 and 1/2 operand variants. This mirrors the structure Eric used in the new VS backend, and seems simpler. In particular, the math1/math2 split will avoid having to figure out how many operands there are, as this is already known by the caller. Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Eric Anholt <eric@anholt.net>
2011-08-18 11:55:42 -07:00
brw_set_compression_control(p, BRW_COMPRESSION_NONE);
brw_math(p, dst,
op,
0, src0,
BRW_MATH_DATA_VECTOR,
BRW_MATH_PRECISION_FULL);
i965/fs: Split the BRW native code emit to brw_fs_emit.cpp This is all separate from the visitor and the optimization passes which feed into it. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2011-05-24 16:34:27 -07:00
i965/fs: Move brw_wm_compile::dispatch_width into fs_visitor. Also, rather than having brw_wm_fs_emit poke at it directly, make it a parameter to the fs_visitor constructor. All other changes generated by search and replace (with occasional whitespace fixup). v2: Make dispatch_width const (as suggested by Paul); fix doxygen mistake (pointed out by Eric); update for rebase. Reviewed-by: Eric Anholt <eric@anholt.net> Reviewed-by: Paul Berry <stereotype441@gmail.com>
2012-11-20 13:50:52 -08:00
if (dispatch_width == 16) {
i965/fs: Split generate_math into gen4/gen6 and 1/2 operand variants. This mirrors the structure Eric used in the new VS backend, and seems simpler. In particular, the math1/math2 split will avoid having to figure out how many operands there are, as this is already known by the caller. Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Eric Anholt <eric@anholt.net>
2011-08-18 11:55:42 -07:00
brw_set_compression_control(p, BRW_COMPRESSION_2NDHALF);
brw_math(p, sechalf(dst),
i965/fs: Split the BRW native code emit to brw_fs_emit.cpp This is all separate from the visitor and the optimization passes which feed into it. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2011-05-24 16:34:27 -07:00
op,
i965/fs: Split generate_math into gen4/gen6 and 1/2 operand variants. This mirrors the structure Eric used in the new VS backend, and seems simpler. In particular, the math1/math2 split will avoid having to figure out how many operands there are, as this is already known by the caller. Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Eric Anholt <eric@anholt.net>
2011-08-18 11:55:42 -07:00
0, sechalf(src0),
i965/fs: Split the BRW native code emit to brw_fs_emit.cpp This is all separate from the visitor and the optimization passes which feed into it. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2011-05-24 16:34:27 -07:00
BRW_MATH_DATA_VECTOR,
BRW_MATH_PRECISION_FULL);
i965/fs: Split generate_math into gen4/gen6 and 1/2 operand variants. This mirrors the structure Eric used in the new VS backend, and seems simpler. In particular, the math1/math2 split will avoid having to figure out how many operands there are, as this is already known by the caller. Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Eric Anholt <eric@anholt.net>
2011-08-18 11:55:42 -07:00
brw_set_compression_control(p, BRW_COMPRESSION_COMPRESSED);
}
}
i965/fs: Split the BRW native code emit to brw_fs_emit.cpp This is all separate from the visitor and the optimization passes which feed into it. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2011-05-24 16:34:27 -07:00
i965/fs: Split generate_math into gen4/gen6 and 1/2 operand variants. This mirrors the structure Eric used in the new VS backend, and seems simpler. In particular, the math1/math2 split will avoid having to figure out how many operands there are, as this is already known by the caller. Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Eric Anholt <eric@anholt.net>
2011-08-18 11:55:42 -07:00
void
i965/fs: Split final assembly code generation out of fs_visitor. Compiling shaders requires several main steps: 1. Generating FS 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 "fs_generator." There are several reasons for doing so: 1. Future hardware has a different instruction encoding. Splitting this out will allow us to replace fs_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 fs_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 fs_visitor and create IR, while ADD() in fs_generator() can create brw_instructions. (Patches for this upcoming.) Furthermore, this patch changes the order of operations slightly. Rather than doing steps 1-4 for SIMD8, then 1-4 for SIMD16, we now: - Do steps 1-3 for SIMD8, then repeat 1-3 for SIMD16 - Generate final assembly code for both modes together This is because the frontend work can be done independently, but final assembly generation needs to pack both into a single program store to feed the GPU. Reviewed-by: Eric Anholt <eric@anholt.net> Reviewed-by: Paul Berry <stereotype441@gmail.com>
2012-11-09 01:05:47 -08:00
fs_generator::generate_math2_gen6(fs_inst *inst,
i965/fs: Split generate_math into gen4/gen6 and 1/2 operand variants. This mirrors the structure Eric used in the new VS backend, and seems simpler. In particular, the math1/math2 split will avoid having to figure out how many operands there are, as this is already known by the caller. Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Eric Anholt <eric@anholt.net>
2011-08-18 11:55:42 -07:00
struct brw_reg dst,
struct brw_reg src0,
struct brw_reg src1)
{
int op = brw_math_function(inst->opcode);
i965/fs: Split the BRW native code emit to brw_fs_emit.cpp This is all separate from the visitor and the optimization passes which feed into it. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2011-05-24 16:34:27 -07:00
i965/fs: Split generate_math into gen4/gen6 and 1/2 operand variants. This mirrors the structure Eric used in the new VS backend, and seems simpler. In particular, the math1/math2 split will avoid having to figure out how many operands there are, as this is already known by the caller. Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Eric Anholt <eric@anholt.net>
2011-08-18 11:55:42 -07:00
assert(inst->mlen == 0);
brw_set_compression_control(p, BRW_COMPRESSION_NONE);
brw_math2(p, dst, op, src0, src1);
i965/fs: Move brw_wm_compile::dispatch_width into fs_visitor. Also, rather than having brw_wm_fs_emit poke at it directly, make it a parameter to the fs_visitor constructor. All other changes generated by search and replace (with occasional whitespace fixup). v2: Make dispatch_width const (as suggested by Paul); fix doxygen mistake (pointed out by Eric); update for rebase. Reviewed-by: Eric Anholt <eric@anholt.net> Reviewed-by: Paul Berry <stereotype441@gmail.com>
2012-11-20 13:50:52 -08:00
if (dispatch_width == 16) {
i965/fs: Split generate_math into gen4/gen6 and 1/2 operand variants. This mirrors the structure Eric used in the new VS backend, and seems simpler. In particular, the math1/math2 split will avoid having to figure out how many operands there are, as this is already known by the caller. Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Eric Anholt <eric@anholt.net>
2011-08-18 11:55:42 -07:00
brw_set_compression_control(p, BRW_COMPRESSION_2NDHALF);
brw_math2(p, sechalf(dst), op, sechalf(src0), sechalf(src1));
brw_set_compression_control(p, BRW_COMPRESSION_COMPRESSED);
}
}
void
i965/fs: Split final assembly code generation out of fs_visitor. Compiling shaders requires several main steps: 1. Generating FS 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 "fs_generator." There are several reasons for doing so: 1. Future hardware has a different instruction encoding. Splitting this out will allow us to replace fs_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 fs_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 fs_visitor and create IR, while ADD() in fs_generator() can create brw_instructions. (Patches for this upcoming.) Furthermore, this patch changes the order of operations slightly. Rather than doing steps 1-4 for SIMD8, then 1-4 for SIMD16, we now: - Do steps 1-3 for SIMD8, then repeat 1-3 for SIMD16 - Generate final assembly code for both modes together This is because the frontend work can be done independently, but final assembly generation needs to pack both into a single program store to feed the GPU. Reviewed-by: Eric Anholt <eric@anholt.net> Reviewed-by: Paul Berry <stereotype441@gmail.com>
2012-11-09 01:05:47 -08:00
fs_generator::generate_math_gen4(fs_inst *inst,
i965/fs: Split generate_math into gen4/gen6 and 1/2 operand variants. This mirrors the structure Eric used in the new VS backend, and seems simpler. In particular, the math1/math2 split will avoid having to figure out how many operands there are, as this is already known by the caller. Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Eric Anholt <eric@anholt.net>
2011-08-18 11:55:42 -07:00
struct brw_reg dst,
struct brw_reg src)
{
int op = brw_math_function(inst->opcode);
assert(inst->mlen >= 1);
brw_set_compression_control(p, BRW_COMPRESSION_NONE);
brw_math(p, dst,
op,
inst->base_mrf, src,
BRW_MATH_DATA_VECTOR,
BRW_MATH_PRECISION_FULL);
i965/fs: Move brw_wm_compile::dispatch_width into fs_visitor. Also, rather than having brw_wm_fs_emit poke at it directly, make it a parameter to the fs_visitor constructor. All other changes generated by search and replace (with occasional whitespace fixup). v2: Make dispatch_width const (as suggested by Paul); fix doxygen mistake (pointed out by Eric); update for rebase. Reviewed-by: Eric Anholt <eric@anholt.net> Reviewed-by: Paul Berry <stereotype441@gmail.com>
2012-11-20 13:50:52 -08:00
if (dispatch_width == 16) {
i965/fs: Split generate_math into gen4/gen6 and 1/2 operand variants. This mirrors the structure Eric used in the new VS backend, and seems simpler. In particular, the math1/math2 split will avoid having to figure out how many operands there are, as this is already known by the caller. Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Eric Anholt <eric@anholt.net>
2011-08-18 11:55:42 -07:00
brw_set_compression_control(p, BRW_COMPRESSION_2NDHALF);
brw_math(p, sechalf(dst),
op,
inst->base_mrf + 1, sechalf(src),
BRW_MATH_DATA_VECTOR,
BRW_MATH_PRECISION_FULL);
brw_set_compression_control(p, BRW_COMPRESSION_COMPRESSED);
i965/fs: Split the BRW native code emit to brw_fs_emit.cpp This is all separate from the visitor and the optimization passes which feed into it. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2011-05-24 16:34:27 -07:00
}
}
void
i965/fs: Split final assembly code generation out of fs_visitor. Compiling shaders requires several main steps: 1. Generating FS 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 "fs_generator." There are several reasons for doing so: 1. Future hardware has a different instruction encoding. Splitting this out will allow us to replace fs_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 fs_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 fs_visitor and create IR, while ADD() in fs_generator() can create brw_instructions. (Patches for this upcoming.) Furthermore, this patch changes the order of operations slightly. Rather than doing steps 1-4 for SIMD8, then 1-4 for SIMD16, we now: - Do steps 1-3 for SIMD8, then repeat 1-3 for SIMD16 - Generate final assembly code for both modes together This is because the frontend work can be done independently, but final assembly generation needs to pack both into a single program store to feed the GPU. Reviewed-by: Eric Anholt <eric@anholt.net> Reviewed-by: Paul Berry <stereotype441@gmail.com>
2012-11-09 01:05:47 -08:00
fs_generator::generate_tex(fs_inst *inst, struct brw_reg dst, struct brw_reg src)
i965/fs: Split the BRW native code emit to brw_fs_emit.cpp This is all separate from the visitor and the optimization passes which feed into it. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2011-05-24 16:34:27 -07:00
{
int msg_type = -1;
int rlen = 4;
uint32_t simd_mode = BRW_SAMPLER_SIMD_MODE_SIMD8;
i965/gen4: Fix sampling from integer textures. On original gen4, the surface format didn't determine the return data type from sampling like it does on g45 and later. Fixes GL_EXT_texture_integer/texture_integer_glsl130 Reviewed-by: Paul Berry <stereotype441@gmail.com>
2011-11-09 16:07:57 -08:00
uint32_t return_format;
switch (dst.type) {
case BRW_REGISTER_TYPE_D:
return_format = BRW_SAMPLER_RETURN_FORMAT_SINT32;
break;
case BRW_REGISTER_TYPE_UD:
return_format = BRW_SAMPLER_RETURN_FORMAT_UINT32;
break;
default:
return_format = BRW_SAMPLER_RETURN_FORMAT_FLOAT32;
break;
}
i965/fs: Split the BRW native code emit to brw_fs_emit.cpp This is all separate from the visitor and the optimization passes which feed into it. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2011-05-24 16:34:27 -07:00
i965/fs: Move brw_wm_compile::dispatch_width into fs_visitor. Also, rather than having brw_wm_fs_emit poke at it directly, make it a parameter to the fs_visitor constructor. All other changes generated by search and replace (with occasional whitespace fixup). v2: Make dispatch_width const (as suggested by Paul); fix doxygen mistake (pointed out by Eric); update for rebase. Reviewed-by: Eric Anholt <eric@anholt.net> Reviewed-by: Paul Berry <stereotype441@gmail.com>
2012-11-20 13:50:52 -08:00
if (dispatch_width == 16)
i965/fs: Split the BRW native code emit to brw_fs_emit.cpp This is all separate from the visitor and the optimization passes which feed into it. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2011-05-24 16:34:27 -07:00
simd_mode = BRW_SAMPLER_SIMD_MODE_SIMD16;
if (intel->gen >= 5) {
switch (inst->opcode) {
i965: Rename texturing ops from FS_OPCODE to SHADER_OPCODE, except TXB. We'll be reusing most of these for the VS shortly. The one exception is TXB (texturing with LOD bias), which is explicitly forbidden in the VS. Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Eric Anholt <eric@anholt.net>
2011-10-26 12:58:37 -07:00
case SHADER_OPCODE_TEX:
i965/fs: Split the BRW native code emit to brw_fs_emit.cpp This is all separate from the visitor and the optimization passes which feed into it. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2011-05-24 16:34:27 -07:00
if (inst->shadow_compare) {
msg_type = GEN5_SAMPLER_MESSAGE_SAMPLE_COMPARE;
} else {
msg_type = GEN5_SAMPLER_MESSAGE_SAMPLE;
}
break;
case FS_OPCODE_TXB:
if (inst->shadow_compare) {
msg_type = GEN5_SAMPLER_MESSAGE_SAMPLE_BIAS_COMPARE;
} else {
msg_type = GEN5_SAMPLER_MESSAGE_SAMPLE_BIAS;
}
break;
i965: Rename texturing ops from FS_OPCODE to SHADER_OPCODE, except TXB. We'll be reusing most of these for the VS shortly. The one exception is TXB (texturing with LOD bias), which is explicitly forbidden in the VS. Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Eric Anholt <eric@anholt.net>
2011-10-26 12:58:37 -07:00
case SHADER_OPCODE_TXL:
i965/fs: Split the BRW native code emit to brw_fs_emit.cpp This is all separate from the visitor and the optimization passes which feed into it. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2011-05-24 16:34:27 -07:00
if (inst->shadow_compare) {
msg_type = GEN5_SAMPLER_MESSAGE_SAMPLE_LOD_COMPARE;
} else {
msg_type = GEN5_SAMPLER_MESSAGE_SAMPLE_LOD;
}
break;
i965: Rename texturing ops from FS_OPCODE to SHADER_OPCODE, except TXB. We'll be reusing most of these for the VS shortly. The one exception is TXB (texturing with LOD bias), which is explicitly forbidden in the VS. Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Eric Anholt <eric@anholt.net>
2011-10-26 12:58:37 -07:00
case SHADER_OPCODE_TXS:
i965/fs: Implement textureSize (TXS) on Gen5+. Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
2011-06-19 01:47:50 -07:00
msg_type = GEN5_SAMPLER_MESSAGE_SAMPLE_RESINFO;
break;
i965: Rename texturing ops from FS_OPCODE to SHADER_OPCODE, except TXB. We'll be reusing most of these for the VS shortly. The one exception is TXB (texturing with LOD bias), which is explicitly forbidden in the VS. Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Eric Anholt <eric@anholt.net>
2011-10-26 12:58:37 -07:00
case SHADER_OPCODE_TXD:
i965/fs: Add support for TXD with shadow comparisons. Our hardware doesn't have a sample_d_c message, so we have to do a regular sample_d and emit instructions to manually perform the comparison. This requires a state dependent recompile whenever the sampler's compare mode or function change. This adds the per-sampler comparison functions to brw_wm_prog_key, but only sets them when the sampler's compare mode is GL_COMPARE_R_TO_TEXTURE (i.e. only for shadow sampling). Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Eric Anholt <eric@anholt.net>
2011-06-10 14:48:46 -07:00
/* There is no sample_d_c message; comparisons are done manually */
i965/fs: Add support for non-shadow textureGrad (TXD) on Ivybridge. This is somewhat ugly, but I couldn't think of a nicer way to handle the interleaved coordinate/derivative parameter loading. Ironlake and Sandybridge will still hit an assertion in visit(). Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Eric Anholt <eric@anholt.net>
2011-06-08 16:08:07 -07:00
msg_type = GEN5_SAMPLER_MESSAGE_SAMPLE_DERIVS;
i965/fs: Split the BRW native code emit to brw_fs_emit.cpp This is all separate from the visitor and the optimization passes which feed into it. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2011-05-24 16:34:27 -07:00
break;
i965: Rename texturing ops from FS_OPCODE to SHADER_OPCODE, except TXB. We'll be reusing most of these for the VS shortly. The one exception is TXB (texturing with LOD bias), which is explicitly forbidden in the VS. Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Eric Anholt <eric@anholt.net>
2011-10-26 12:58:37 -07:00
case SHADER_OPCODE_TXF:
i965/fs: Implement texelFetch() on Ironlake and Sandybridge. Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Eric Anholt <eric@anholt.net>
2011-08-25 17:13:37 -07:00
msg_type = GEN5_SAMPLER_MESSAGE_SAMPLE_LD;
break;
i965: Create a shared enum for hardware and compiler-internal opcodes. This should make gdbing more pleasant, and it might be used in sharing part of the codegen between the VS and FS backends.
2011-05-03 10:55:50 -07:00
default:
assert(!"not reached");
break;
i965/fs: Split the BRW native code emit to brw_fs_emit.cpp This is all separate from the visitor and the optimization passes which feed into it. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2011-05-24 16:34:27 -07:00
}
} else {
switch (inst->opcode) {
i965: Rename texturing ops from FS_OPCODE to SHADER_OPCODE, except TXB. We'll be reusing most of these for the VS shortly. The one exception is TXB (texturing with LOD bias), which is explicitly forbidden in the VS. Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Eric Anholt <eric@anholt.net>
2011-10-26 12:58:37 -07:00
case SHADER_OPCODE_TEX:
i965/fs: Split the BRW native code emit to brw_fs_emit.cpp This is all separate from the visitor and the optimization passes which feed into it. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2011-05-24 16:34:27 -07:00
/* Note that G45 and older determines shadow compare and dispatch width
* from message length for most messages.
*/
i965/fs: Move brw_wm_compile::dispatch_width into fs_visitor. Also, rather than having brw_wm_fs_emit poke at it directly, make it a parameter to the fs_visitor constructor. All other changes generated by search and replace (with occasional whitespace fixup). v2: Make dispatch_width const (as suggested by Paul); fix doxygen mistake (pointed out by Eric); update for rebase. Reviewed-by: Eric Anholt <eric@anholt.net> Reviewed-by: Paul Berry <stereotype441@gmail.com>
2012-11-20 13:50:52 -08:00
assert(dispatch_width == 8);
i965/fs: Split the BRW native code emit to brw_fs_emit.cpp This is all separate from the visitor and the optimization passes which feed into it. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2011-05-24 16:34:27 -07:00
msg_type = BRW_SAMPLER_MESSAGE_SIMD8_SAMPLE;
if (inst->shadow_compare) {
assert(inst->mlen == 6);
} else {
assert(inst->mlen <= 4);
}
break;
case FS_OPCODE_TXB:
if (inst->shadow_compare) {
assert(inst->mlen == 6);
msg_type = BRW_SAMPLER_MESSAGE_SIMD8_SAMPLE_BIAS_COMPARE;
} else {
assert(inst->mlen == 9);
msg_type = BRW_SAMPLER_MESSAGE_SIMD16_SAMPLE_BIAS;
simd_mode = BRW_SAMPLER_SIMD_MODE_SIMD16;
}
break;
i965: Rename texturing ops from FS_OPCODE to SHADER_OPCODE, except TXB. We'll be reusing most of these for the VS shortly. The one exception is TXB (texturing with LOD bias), which is explicitly forbidden in the VS. Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Eric Anholt <eric@anholt.net>
2011-10-26 12:58:37 -07:00
case SHADER_OPCODE_TXL:
i965/fs: Split the BRW native code emit to brw_fs_emit.cpp This is all separate from the visitor and the optimization passes which feed into it. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2011-05-24 16:34:27 -07:00
if (inst->shadow_compare) {
assert(inst->mlen == 6);
msg_type = BRW_SAMPLER_MESSAGE_SIMD8_SAMPLE_LOD_COMPARE;
} else {
assert(inst->mlen == 9);
msg_type = BRW_SAMPLER_MESSAGE_SIMD16_SAMPLE_LOD;
simd_mode = BRW_SAMPLER_SIMD_MODE_SIMD16;
}
break;
i965: Rename texturing ops from FS_OPCODE to SHADER_OPCODE, except TXB. We'll be reusing most of these for the VS shortly. The one exception is TXB (texturing with LOD bias), which is explicitly forbidden in the VS. Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Eric Anholt <eric@anholt.net>
2011-10-26 12:58:37 -07:00
case SHADER_OPCODE_TXD:
i965/fs: Add support for TXD with shadow comparisons. Our hardware doesn't have a sample_d_c message, so we have to do a regular sample_d and emit instructions to manually perform the comparison. This requires a state dependent recompile whenever the sampler's compare mode or function change. This adds the per-sampler comparison functions to brw_wm_prog_key, but only sets them when the sampler's compare mode is GL_COMPARE_R_TO_TEXTURE (i.e. only for shadow sampling). Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Eric Anholt <eric@anholt.net>
2011-06-10 14:48:46 -07:00
/* There is no sample_d_c message; comparisons are done manually */
i965/fs: Add support for non-shadow textureGrad (TXD) on gen4. Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Eric Anholt <eric@anholt.net>
2011-06-08 16:05:34 -07:00
assert(inst->mlen == 7 || inst->mlen == 10);
msg_type = BRW_SAMPLER_MESSAGE_SIMD8_SAMPLE_GRADIENTS;
i965/fs: Split the BRW native code emit to brw_fs_emit.cpp This is all separate from the visitor and the optimization passes which feed into it. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2011-05-24 16:34:27 -07:00
break;
i965: Rename texturing ops from FS_OPCODE to SHADER_OPCODE, except TXB. We'll be reusing most of these for the VS shortly. The one exception is TXB (texturing with LOD bias), which is explicitly forbidden in the VS. Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Eric Anholt <eric@anholt.net>
2011-10-26 12:58:37 -07:00
case SHADER_OPCODE_TXF:
i965/fs: Implement texelFetch() on Gen4. Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Eric Anholt <eric@anholt.net>
2011-09-06 16:39:01 -07:00
assert(inst->mlen == 9);
msg_type = BRW_SAMPLER_MESSAGE_SIMD16_LD;
simd_mode = BRW_SAMPLER_SIMD_MODE_SIMD16;
break;
i965: Rename texturing ops from FS_OPCODE to SHADER_OPCODE, except TXB. We'll be reusing most of these for the VS shortly. The one exception is TXB (texturing with LOD bias), which is explicitly forbidden in the VS. Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Eric Anholt <eric@anholt.net>
2011-10-26 12:58:37 -07:00
case SHADER_OPCODE_TXS:
i965: Implement textureSize (TXS) on Gen4. Also, remove the BRW_SAMPLER_MESSAGE_SIMD8_RESINFO #define because there totally isn't a SIMD8 variant. Unfortunately, resinfo returns FLOAT32 on Broadwater/Crestline, unlike G45 which returns a proper UINT32. This turns out to be simple, however: when we emit MOVs to select the desired half of the SIMD16 result, we can simply override the register type to be float so it's converted to an integer. Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
2011-08-17 10:45:47 -07:00
assert(inst->mlen == 3);
msg_type = BRW_SAMPLER_MESSAGE_SIMD16_RESINFO;
simd_mode = BRW_SAMPLER_SIMD_MODE_SIMD16;
break;
i965: Create a shared enum for hardware and compiler-internal opcodes. This should make gdbing more pleasant, and it might be used in sharing part of the codegen between the VS and FS backends.
2011-05-03 10:55:50 -07:00
default:
assert(!"not reached");
break;
i965/fs: Split the BRW native code emit to brw_fs_emit.cpp This is all separate from the visitor and the optimization passes which feed into it. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2011-05-24 16:34:27 -07:00
}
}
assert(msg_type != -1);
if (simd_mode == BRW_SAMPLER_SIMD_MODE_SIMD16) {
rlen = 8;
dst = vec16(dst);
}
i965/fs: Move message header and texture offset setup to generate_tex(). Setting the texture offset bits in the message header involves very specific hardware register descriptions. As such, I feel it's better suited for the lower level "generate" layer that has direct access to the weird register layouts, rather than at the fs_inst abstraction layer. This also parallels the approach I took in the VS backend. Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Eric Anholt <eric@anholt.net>
2012-08-04 20:33:13 -07:00
/* Load the message header if present. If there's a texture offset,
* we need to set it up explicitly and load the offset bitfield.
* Otherwise, we can use an implied move from g0 to the first message reg.
*/
if (inst->texture_offset) {
brw_push_insn_state(p);
brw_set_compression_control(p, BRW_COMPRESSION_NONE);
/* Explicitly set up the message header by copying g0 to the MRF. */
brw_MOV(p, retype(brw_message_reg(inst->base_mrf), BRW_REGISTER_TYPE_UD),
retype(brw_vec8_grf(0, 0), BRW_REGISTER_TYPE_UD));
/* Then set the offset bits in DWord 2. */
brw_MOV(p, retype(brw_vec1_reg(BRW_MESSAGE_REGISTER_FILE,
inst->base_mrf, 2), BRW_REGISTER_TYPE_UD),
brw_imm_ud(inst->texture_offset));
brw_pop_insn_state(p);
} else if (inst->header_present) {
/* Set up an implied move from g0 to the MRF. */
src = retype(brw_vec8_grf(0, 0), BRW_REGISTER_TYPE_UW);
}
i965/fs: Split the BRW native code emit to brw_fs_emit.cpp This is all separate from the visitor and the optimization passes which feed into it. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2011-05-24 16:34:27 -07:00
brw_SAMPLE(p,
retype(dst, BRW_REGISTER_TYPE_UW),
inst->base_mrf,
src,
SURF_INDEX_TEXTURE(inst->sampler),
inst->sampler,
WRITEMASK_XYZW,
msg_type,
rlen,
inst->mlen,
inst->header_present,
i965/gen4: Fix sampling from integer textures. On original gen4, the surface format didn't determine the return data type from sampling like it does on g45 and later. Fixes GL_EXT_texture_integer/texture_integer_glsl130 Reviewed-by: Paul Berry <stereotype441@gmail.com>
2011-11-09 16:07:57 -08:00
simd_mode,
return_format);
i965/fs: Split the BRW native code emit to brw_fs_emit.cpp This is all separate from the visitor and the optimization passes which feed into it. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2011-05-24 16:34:27 -07:00
}
/* For OPCODE_DDX and OPCODE_DDY, per channel of output we've got input
* looking like:
*
* arg0: ss0.tl ss0.tr ss0.bl ss0.br ss1.tl ss1.tr ss1.bl ss1.br
*
* and we're trying to produce:
*
* DDX DDY
* dst: (ss0.tr - ss0.tl) (ss0.tl - ss0.bl)
* (ss0.tr - ss0.tl) (ss0.tr - ss0.br)
* (ss0.br - ss0.bl) (ss0.tl - ss0.bl)
* (ss0.br - ss0.bl) (ss0.tr - ss0.br)
* (ss1.tr - ss1.tl) (ss1.tl - ss1.bl)
* (ss1.tr - ss1.tl) (ss1.tr - ss1.br)
* (ss1.br - ss1.bl) (ss1.tl - ss1.bl)
* (ss1.br - ss1.bl) (ss1.tr - ss1.br)
*
* and add another set of two more subspans if in 16-pixel dispatch mode.
*
* For DDX, it ends up being easy: width = 2, horiz=0 gets us the same result
* for each pair, and vertstride = 2 jumps us 2 elements after processing a
* pair. But for DDY, it's harder, as we want to produce the pairs swizzled
* between each other. We could probably do it like ddx and swizzle the right
* order later, but bail for now and just produce
* ((ss0.tl - ss0.bl)x4 (ss1.tl - ss1.bl)x4)
*/
void
i965/fs: Split final assembly code generation out of fs_visitor. Compiling shaders requires several main steps: 1. Generating FS 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 "fs_generator." There are several reasons for doing so: 1. Future hardware has a different instruction encoding. Splitting this out will allow us to replace fs_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 fs_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 fs_visitor and create IR, while ADD() in fs_generator() can create brw_instructions. (Patches for this upcoming.) Furthermore, this patch changes the order of operations slightly. Rather than doing steps 1-4 for SIMD8, then 1-4 for SIMD16, we now: - Do steps 1-3 for SIMD8, then repeat 1-3 for SIMD16 - Generate final assembly code for both modes together This is because the frontend work can be done independently, but final assembly generation needs to pack both into a single program store to feed the GPU. Reviewed-by: Eric Anholt <eric@anholt.net> Reviewed-by: Paul Berry <stereotype441@gmail.com>
2012-11-09 01:05:47 -08:00
fs_generator::generate_ddx(fs_inst *inst, struct brw_reg dst, struct brw_reg src)
i965/fs: Split the BRW native code emit to brw_fs_emit.cpp This is all separate from the visitor and the optimization passes which feed into it. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2011-05-24 16:34:27 -07:00
{
struct brw_reg src0 = brw_reg(src.file, src.nr, 1,
BRW_REGISTER_TYPE_F,
BRW_VERTICAL_STRIDE_2,
BRW_WIDTH_2,
BRW_HORIZONTAL_STRIDE_0,
BRW_SWIZZLE_XYZW, WRITEMASK_XYZW);
struct brw_reg src1 = brw_reg(src.file, src.nr, 0,
BRW_REGISTER_TYPE_F,
BRW_VERTICAL_STRIDE_2,
BRW_WIDTH_2,
BRW_HORIZONTAL_STRIDE_0,
BRW_SWIZZLE_XYZW, WRITEMASK_XYZW);
brw_ADD(p, dst, src0, negate(src1));
}
i965: Compute dFdy() correctly for FBOs. On i965, dFdx() and dFdy() are computed by taking advantage of the fact that each consecutive set of 4 pixels dispatched to the fragment shader always constitutes a contiguous 2x2 block of pixels in a fixed arrangement known as a "sub-span". So we calculate dFdx() by taking the difference between the values computed for the left and right halves of the sub-span, and we calculate dFdy() by taking the difference between the values computed for the top and bottom halves of the sub-span. However, there's a subtlety when FBOs are in use: since FBOs use a coordinate system where the origin is at the upper left, and window system framebuffers use a coordinate system where the origin is at the lower left, the computation of dFdy() needs to be negated for FBOs. This patch modifies the fragment shader back-ends to negate the value of dFdy() when an FBO is in use. It also modifies the code that populates the program key (brw_wm_populate_key() and brw_fs_precompile()) so that they always record in the program key whether we are rendering to an FBO or to a window system framebuffer; this ensures that the fragment shader will get recompiled when switching between FBO and non-FBO use. This will result in unnecessary recompiles of fragment shaders that don't use dFdy(). To fix that, we will need to adapt the GLSL and NV_fragment_program front-ends to record whether or not a given shader uses dFdy(). I plan to implement this in a future patch series; I've left FIXME comments in the code as a reminder. Fixes Piglit test "fbo-deriv". NOTE: This is a candidate for stable release branches. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2012-06-20 13:40:45 -07:00
/* The negate_value boolean is used to negate the derivative computation for
* FBOs, since they place the origin at the upper left instead of the lower
* left.
*/
i965/fs: Split the BRW native code emit to brw_fs_emit.cpp This is all separate from the visitor and the optimization passes which feed into it. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2011-05-24 16:34:27 -07:00
void
i965/fs: Split final assembly code generation out of fs_visitor. Compiling shaders requires several main steps: 1. Generating FS 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 "fs_generator." There are several reasons for doing so: 1. Future hardware has a different instruction encoding. Splitting this out will allow us to replace fs_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 fs_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 fs_visitor and create IR, while ADD() in fs_generator() can create brw_instructions. (Patches for this upcoming.) Furthermore, this patch changes the order of operations slightly. Rather than doing steps 1-4 for SIMD8, then 1-4 for SIMD16, we now: - Do steps 1-3 for SIMD8, then repeat 1-3 for SIMD16 - Generate final assembly code for both modes together This is because the frontend work can be done independently, but final assembly generation needs to pack both into a single program store to feed the GPU. Reviewed-by: Eric Anholt <eric@anholt.net> Reviewed-by: Paul Berry <stereotype441@gmail.com>
2012-11-09 01:05:47 -08:00
fs_generator::generate_ddy(fs_inst *inst, struct brw_reg dst, struct brw_reg src,
i965: Compute dFdy() correctly for FBOs. On i965, dFdx() and dFdy() are computed by taking advantage of the fact that each consecutive set of 4 pixels dispatched to the fragment shader always constitutes a contiguous 2x2 block of pixels in a fixed arrangement known as a "sub-span". So we calculate dFdx() by taking the difference between the values computed for the left and right halves of the sub-span, and we calculate dFdy() by taking the difference between the values computed for the top and bottom halves of the sub-span. However, there's a subtlety when FBOs are in use: since FBOs use a coordinate system where the origin is at the upper left, and window system framebuffers use a coordinate system where the origin is at the lower left, the computation of dFdy() needs to be negated for FBOs. This patch modifies the fragment shader back-ends to negate the value of dFdy() when an FBO is in use. It also modifies the code that populates the program key (brw_wm_populate_key() and brw_fs_precompile()) so that they always record in the program key whether we are rendering to an FBO or to a window system framebuffer; this ensures that the fragment shader will get recompiled when switching between FBO and non-FBO use. This will result in unnecessary recompiles of fragment shaders that don't use dFdy(). To fix that, we will need to adapt the GLSL and NV_fragment_program front-ends to record whether or not a given shader uses dFdy(). I plan to implement this in a future patch series; I've left FIXME comments in the code as a reminder. Fixes Piglit test "fbo-deriv". NOTE: This is a candidate for stable release branches. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2012-06-20 13:40:45 -07:00
bool negate_value)
i965/fs: Split the BRW native code emit to brw_fs_emit.cpp This is all separate from the visitor and the optimization passes which feed into it. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2011-05-24 16:34:27 -07:00
{
struct brw_reg src0 = brw_reg(src.file, src.nr, 0,
BRW_REGISTER_TYPE_F,
BRW_VERTICAL_STRIDE_4,
BRW_WIDTH_4,
BRW_HORIZONTAL_STRIDE_0,
BRW_SWIZZLE_XYZW, WRITEMASK_XYZW);
struct brw_reg src1 = brw_reg(src.file, src.nr, 2,
BRW_REGISTER_TYPE_F,
BRW_VERTICAL_STRIDE_4,
BRW_WIDTH_4,
BRW_HORIZONTAL_STRIDE_0,
BRW_SWIZZLE_XYZW, WRITEMASK_XYZW);
i965: Compute dFdy() correctly for FBOs. On i965, dFdx() and dFdy() are computed by taking advantage of the fact that each consecutive set of 4 pixels dispatched to the fragment shader always constitutes a contiguous 2x2 block of pixels in a fixed arrangement known as a "sub-span". So we calculate dFdx() by taking the difference between the values computed for the left and right halves of the sub-span, and we calculate dFdy() by taking the difference between the values computed for the top and bottom halves of the sub-span. However, there's a subtlety when FBOs are in use: since FBOs use a coordinate system where the origin is at the upper left, and window system framebuffers use a coordinate system where the origin is at the lower left, the computation of dFdy() needs to be negated for FBOs. This patch modifies the fragment shader back-ends to negate the value of dFdy() when an FBO is in use. It also modifies the code that populates the program key (brw_wm_populate_key() and brw_fs_precompile()) so that they always record in the program key whether we are rendering to an FBO or to a window system framebuffer; this ensures that the fragment shader will get recompiled when switching between FBO and non-FBO use. This will result in unnecessary recompiles of fragment shaders that don't use dFdy(). To fix that, we will need to adapt the GLSL and NV_fragment_program front-ends to record whether or not a given shader uses dFdy(). I plan to implement this in a future patch series; I've left FIXME comments in the code as a reminder. Fixes Piglit test "fbo-deriv". NOTE: This is a candidate for stable release branches. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2012-06-20 13:40:45 -07:00
if (negate_value)
brw_ADD(p, dst, src1, negate(src0));
else
brw_ADD(p, dst, src0, negate(src1));
i965/fs: Split the BRW native code emit to brw_fs_emit.cpp This is all separate from the visitor and the optimization passes which feed into it. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2011-05-24 16:34:27 -07:00
}
i965/fs: Improve performance of shaders that start out with a discard. I had tried this in the past, but ran into trouble with applications that sample from undiscarded pixels in the same subspan. To fix that issue, only jump to the end for an entire subspan at a time. Improves GLbenchmark 2.7 (1024x768) performance by 7.9 +/- 1.5% (n=8). v2: Drop the br variable in the jump instruction -- if I ever do jumps pre-gen6, it'll be a different code block anyway since we don't have HALT until gen6. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2012-12-06 10:15:08 -08:00
void
fs_generator::generate_discard_jump(fs_inst *inst)
{
assert(intel->gen >= 6);
/* This HALT will be patched up at FB write time to point UIP at the end of
* the program, and at brw_uip_jip() JIP will be set to the end of the
* current block (or the program).
*/
this->discard_halt_patches.push_tail(new(mem_ctx) ip_record(p->nr_insn));
brw_push_insn_state(p);
brw_set_mask_control(p, BRW_MASK_DISABLE);
gen6_HALT(p);
brw_pop_insn_state(p);
}
i965/fs: Split the BRW native code emit to brw_fs_emit.cpp This is all separate from the visitor and the optimization passes which feed into it. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2011-05-24 16:34:27 -07:00
void
i965/fs: Split final assembly code generation out of fs_visitor. Compiling shaders requires several main steps: 1. Generating FS 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 "fs_generator." There are several reasons for doing so: 1. Future hardware has a different instruction encoding. Splitting this out will allow us to replace fs_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 fs_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 fs_visitor and create IR, while ADD() in fs_generator() can create brw_instructions. (Patches for this upcoming.) Furthermore, this patch changes the order of operations slightly. Rather than doing steps 1-4 for SIMD8, then 1-4 for SIMD16, we now: - Do steps 1-3 for SIMD8, then repeat 1-3 for SIMD16 - Generate final assembly code for both modes together This is because the frontend work can be done independently, but final assembly generation needs to pack both into a single program store to feed the GPU. Reviewed-by: Eric Anholt <eric@anholt.net> Reviewed-by: Paul Berry <stereotype441@gmail.com>
2012-11-09 01:05:47 -08:00
fs_generator::generate_spill(fs_inst *inst, struct brw_reg src)
i965/fs: Split the BRW native code emit to brw_fs_emit.cpp This is all separate from the visitor and the optimization passes which feed into it. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2011-05-24 16:34:27 -07:00
{
assert(inst->mlen != 0);
brw_MOV(p,
retype(brw_message_reg(inst->base_mrf + 1), BRW_REGISTER_TYPE_UD),
retype(src, BRW_REGISTER_TYPE_UD));
brw_oword_block_write_scratch(p, brw_message_reg(inst->base_mrf), 1,
inst->offset);
}
void
i965/fs: Split final assembly code generation out of fs_visitor. Compiling shaders requires several main steps: 1. Generating FS 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 "fs_generator." There are several reasons for doing so: 1. Future hardware has a different instruction encoding. Splitting this out will allow us to replace fs_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 fs_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 fs_visitor and create IR, while ADD() in fs_generator() can create brw_instructions. (Patches for this upcoming.) Furthermore, this patch changes the order of operations slightly. Rather than doing steps 1-4 for SIMD8, then 1-4 for SIMD16, we now: - Do steps 1-3 for SIMD8, then repeat 1-3 for SIMD16 - Generate final assembly code for both modes together This is because the frontend work can be done independently, but final assembly generation needs to pack both into a single program store to feed the GPU. Reviewed-by: Eric Anholt <eric@anholt.net> Reviewed-by: Paul Berry <stereotype441@gmail.com>
2012-11-09 01:05:47 -08:00
fs_generator::generate_unspill(fs_inst *inst, struct brw_reg dst)
i965/fs: Split the BRW native code emit to brw_fs_emit.cpp This is all separate from the visitor and the optimization passes which feed into it. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2011-05-24 16:34:27 -07:00
{
assert(inst->mlen != 0);
/* Clear any post destination dependencies that would be ignored by
* the block read. See the B-Spec for pre-gen5 send instruction.
*
* This could use a better solution, since texture sampling and
* math reads could potentially run into it as well -- anywhere
* that we have a SEND with a destination that is a register that
* was written but not read within the last N instructions (what's
* N? unsure). This is rare because of dead code elimination, but
* not impossible.
*/
if (intel->gen == 4 && !intel->is_g4x)
brw_MOV(p, brw_null_reg(), dst);
brw_oword_block_read_scratch(p, dst, brw_message_reg(inst->base_mrf), 1,
inst->offset);
if (intel->gen == 4 && !intel->is_g4x) {
/* gen4 errata: destination from a send can't be used as a
* destination until it's been read. Just read it so we don't
* have to worry.
*/
brw_MOV(p, brw_null_reg(), dst);
}
}
void
i965/fs: Rename the existing pull constant load opcode. We're going to use another send message for handling loads with a varying per-fragment array index.
2012-11-07 10:42:34 -08:00
fs_generator::generate_uniform_pull_constant_load(fs_inst *inst,
struct brw_reg dst,
struct brw_reg index,
struct brw_reg offset)
i965/fs: Split the BRW native code emit to brw_fs_emit.cpp This is all separate from the visitor and the optimization passes which feed into it. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2011-05-24 16:34:27 -07:00
{
assert(inst->mlen != 0);
/* Clear any post destination dependencies that would be ignored by
* the block read. See the B-Spec for pre-gen5 send instruction.
*
* This could use a better solution, since texture sampling and
* math reads could potentially run into it as well -- anywhere
* that we have a SEND with a destination that is a register that
* was written but not read within the last N instructions (what's
* N? unsure). This is rare because of dead code elimination, but
* not impossible.
*/
if (intel->gen == 4 && !intel->is_g4x)
brw_MOV(p, brw_null_reg(), dst);
i965/fs: Communicate the pull constant block read parameters through fs_regs. I wanted to add the surface index as a variable value for UBO support, and a reg seemed like the obvious way to go. This exposes more of the information to CSE, which we'll probably want to apply to pull constant loads for UBOs eventually (you might access 4 floats in a row, each of which would produce an oword block read of the same block). Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2012-06-20 15:41:14 -07:00
assert(index.file == BRW_IMMEDIATE_VALUE &&
index.type == BRW_REGISTER_TYPE_UD);
uint32_t surf_index = index.dw1.ud;
assert(offset.file == BRW_IMMEDIATE_VALUE &&
offset.type == BRW_REGISTER_TYPE_UD);
uint32_t read_offset = offset.dw1.ud;
i965/fs: Split the BRW native code emit to brw_fs_emit.cpp This is all separate from the visitor and the optimization passes which feed into it. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2011-05-24 16:34:27 -07:00
brw_oword_block_read(p, dst, brw_message_reg(inst->base_mrf),
i965/fs: Communicate the pull constant block read parameters through fs_regs. I wanted to add the surface index as a variable value for UBO support, and a reg seemed like the obvious way to go. This exposes more of the information to CSE, which we'll probably want to apply to pull constant loads for UBOs eventually (you might access 4 floats in a row, each of which would produce an oword block read of the same block). Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2012-06-20 15:41:14 -07:00
read_offset, surf_index);
i965/fs: Split the BRW native code emit to brw_fs_emit.cpp This is all separate from the visitor and the optimization passes which feed into it. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2011-05-24 16:34:27 -07:00
if (intel->gen == 4 && !intel->is_g4x) {
/* gen4 errata: destination from a send can't be used as a
* destination until it's been read. Just read it so we don't
* have to worry.
*/
brw_MOV(p, brw_null_reg(), dst);
}
}
i965/fs: Set up gen7 UBO loads as sends from GRFs. This gives the instruction scheduler a chance to schedule between the loads, whereas before it was restricted due to the dependencies between the MRFs for setting them up. For one shader in gles3conform, it goes from getting stuck in register allocation for as long as anybody's bothered to leave it running down to 23 seconds, thanks to the LIFO scheduling. Acked-by: Kenneth Graunke <kenneth@whitecape.org>
2012-12-05 00:06:30 -08:00
void
fs_generator::generate_uniform_pull_constant_load_gen7(fs_inst *inst,
struct brw_reg dst,
struct brw_reg index,
struct brw_reg offset)
{
assert(inst->mlen == 0);
assert(index.file == BRW_IMMEDIATE_VALUE &&
index.type == BRW_REGISTER_TYPE_UD);
uint32_t surf_index = index.dw1.ud;
assert(offset.file == BRW_GENERAL_REGISTER_FILE);
brw_push_insn_state(p);
brw_set_compression_control(p, BRW_COMPRESSION_NONE);
brw_set_mask_control(p, BRW_MASK_DISABLE);
struct brw_instruction *send = brw_next_insn(p, BRW_OPCODE_SEND);
brw_pop_insn_state(p);
brw_set_dest(p, send, dst);
brw_set_src0(p, send, offset);
uint32_t msg_control = BRW_DATAPORT_OWORD_BLOCK_2_OWORDS;
uint32_t msg_type = BRW_DATAPORT_READ_MESSAGE_OWORD_BLOCK_READ;
bool header_present = true;
brw_set_dp_read_message(p, send,
surf_index,
msg_control,
msg_type,
BRW_DATAPORT_READ_TARGET_DATA_CACHE,
1,
header_present,
1);
}
i965/fs: Add instruction emit for varying-index reads of uniforms. The gen7 send-from-GRF path is sufficiently different from the perspective of IR generation and optimization that I just made it a separate opcode. v2: fix whitespace, rebase on Ken's recent refactor.
2012-11-07 11:18:34 -08:00
void
fs_generator::generate_varying_pull_constant_load(fs_inst *inst,
struct brw_reg dst,
struct brw_reg index)
{
assert(intel->gen < 7); /* Should use the gen7 variant. */
assert(inst->header_present);
assert(index.file == BRW_IMMEDIATE_VALUE &&
index.type == BRW_REGISTER_TYPE_UD);
uint32_t surf_index = index.dw1.ud;
uint32_t msg_type, msg_control, rlen;
if (intel->gen >= 6)
msg_type = GEN6_DATAPORT_READ_MESSAGE_DWORD_SCATTERED_READ;
else if (intel->gen == 5 || intel->is_g4x)
msg_type = G45_DATAPORT_READ_MESSAGE_DWORD_SCATTERED_READ;
else
msg_type = BRW_DATAPORT_READ_MESSAGE_DWORD_SCATTERED_READ;
if (dispatch_width == 16) {
msg_control = BRW_DATAPORT_DWORD_SCATTERED_BLOCK_16DWORDS;
rlen = 2;
} else {
msg_control = BRW_DATAPORT_DWORD_SCATTERED_BLOCK_8DWORDS;
rlen = 1;
}
struct brw_reg header = brw_vec8_grf(0, 0);
gen6_resolve_implied_move(p, &header, inst->base_mrf);
struct brw_instruction *send = brw_next_insn(p, BRW_OPCODE_SEND);
brw_set_dest(p, send, dst);
brw_set_src0(p, send, header);
if (intel->gen < 6)
send->header.destreg__conditionalmod = inst->base_mrf;
brw_set_dp_read_message(p, send,
surf_index,
msg_control,
msg_type,
BRW_DATAPORT_READ_TARGET_DATA_CACHE,
inst->mlen,
inst->header_present,
rlen);
}
void
fs_generator::generate_varying_pull_constant_load_gen7(fs_inst *inst,
struct brw_reg dst,
struct brw_reg index,
struct brw_reg offset)
{
assert(intel->gen >= 7);
/* Varying-offset pull constant loads are treated as a normal expression on
* gen7, so the fact that it's a send message is hidden at the IR level.
*/
assert(!inst->header_present);
assert(!inst->mlen);
assert(index.file == BRW_IMMEDIATE_VALUE &&
index.type == BRW_REGISTER_TYPE_UD);
uint32_t surf_index = index.dw1.ud;
uint32_t msg_control, rlen, mlen;
if (dispatch_width == 16) {
msg_control = BRW_DATAPORT_DWORD_SCATTERED_BLOCK_16DWORDS;
mlen = rlen = 2;
} else {
msg_control = BRW_DATAPORT_DWORD_SCATTERED_BLOCK_8DWORDS;
mlen = rlen = 1;
}
struct brw_instruction *send = brw_next_insn(p, BRW_OPCODE_SEND);
brw_set_dest(p, send, dst);
brw_set_src0(p, send, offset);
if (intel->gen < 6)
send->header.destreg__conditionalmod = inst->base_mrf;
brw_set_dp_read_message(p, send,
surf_index,
msg_control,
GEN7_DATAPORT_DC_DWORD_SCATTERED_READ,
BRW_DATAPORT_READ_TARGET_DATA_CACHE,
mlen,
inst->header_present,
rlen);
}
i965/fs: Add FS_OPCODE_MOV_DISPATCH_TO_FLAGS to fragment shader backend. In order to compute centroid varyings correctly, the fragment shader needs to be able to load the current pixel/sample mask into a flag register. This patch adds an opcode to the fragment shader back-end to do this; the opcode gets translated into the instruction mov(1) f0<1>UW g1.14<0,1,0>UW { align1 WE_all } Since this instruction clobbers f0, instruction scheduling has to treat it the same as instructions that have a conditional modifier. Reviewed-by: Eric Anholt <eric@anholt.net>
2012-06-18 14:50:04 -07:00
/**
* Cause the current pixel/sample mask (from R1.7 bits 15:0) to be transferred
* into the flags register (f0.0).
*
* Used only on Gen6 and above.
*/
void
i965/fs: Add an instruction flag for choosing the flag subregister. We're going to redo discard handling to track discards in the other flag subregister, saving instructions in the discard and allowing predicated jumps out to the end of the shader. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2012-12-06 10:36:11 -08:00
fs_generator::generate_mov_dispatch_to_flags(fs_inst *inst)
i965/fs: Add FS_OPCODE_MOV_DISPATCH_TO_FLAGS to fragment shader backend. In order to compute centroid varyings correctly, the fragment shader needs to be able to load the current pixel/sample mask into a flag register. This patch adds an opcode to the fragment shader back-end to do this; the opcode gets translated into the instruction mov(1) f0<1>UW g1.14<0,1,0>UW { align1 WE_all } Since this instruction clobbers f0, instruction scheduling has to treat it the same as instructions that have a conditional modifier. Reviewed-by: Eric Anholt <eric@anholt.net>
2012-06-18 14:50:04 -07:00
{
i965/fs: Add an instruction flag for choosing the flag subregister. We're going to redo discard handling to track discards in the other flag subregister, saving instructions in the discard and allowing predicated jumps out to the end of the shader. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2012-12-06 10:36:11 -08:00
struct brw_reg flags = brw_flag_reg(0, inst->flag_subreg);
i965/fs: Rewrite discards to use a flag subreg to track discarded pixels. This makes much more sense on gen6+, and will also prove useful for early exit of shaders on discard. v2: fix up a stale comment from before converting gen4-5. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2012-12-06 12:15:13 -08:00
struct brw_reg dispatch_mask;
if (intel->gen >= 6)
dispatch_mask = retype(brw_vec1_grf(1, 7), BRW_REGISTER_TYPE_UW);
else
dispatch_mask = retype(brw_vec1_grf(0, 0), BRW_REGISTER_TYPE_UW);
i965/fs: Add FS_OPCODE_MOV_DISPATCH_TO_FLAGS to fragment shader backend. In order to compute centroid varyings correctly, the fragment shader needs to be able to load the current pixel/sample mask into a flag register. This patch adds an opcode to the fragment shader back-end to do this; the opcode gets translated into the instruction mov(1) f0<1>UW g1.14<0,1,0>UW { align1 WE_all } Since this instruction clobbers f0, instruction scheduling has to treat it the same as instructions that have a conditional modifier. Reviewed-by: Eric Anholt <eric@anholt.net>
2012-06-18 14:50:04 -07:00
brw_push_insn_state(p);
brw_set_mask_control(p, BRW_MASK_DISABLE);
i965/fs: Rewrite discards to use a flag subreg to track discarded pixels. This makes much more sense on gen6+, and will also prove useful for early exit of shaders on discard. v2: fix up a stale comment from before converting gen4-5. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2012-12-06 12:15:13 -08:00
brw_MOV(p, flags, dispatch_mask);
i965/fs: Add FS_OPCODE_MOV_DISPATCH_TO_FLAGS to fragment shader backend. In order to compute centroid varyings correctly, the fragment shader needs to be able to load the current pixel/sample mask into a flag register. This patch adds an opcode to the fragment shader back-end to do this; the opcode gets translated into the instruction mov(1) f0<1>UW g1.14<0,1,0>UW { align1 WE_all } Since this instruction clobbers f0, instruction scheduling has to treat it the same as instructions that have a conditional modifier. Reviewed-by: Eric Anholt <eric@anholt.net>
2012-06-18 14:50:04 -07:00
brw_pop_insn_state(p);
}
i965/fs: Make register file enum 0 be the undefined register file. In 6d874d0ee18b3694c49e0206fa519bd8b746ec24, I checked whether a register that had been stored was BAD_FILE (as opposed to a legitimate GRF), but actually the unset register was ARF NULL because it had been memset to 0. Finding BAD_FILE for unset values in debugging was my intention with that file, so make it the case more often by rearranging the enum. There was only one place we relied on the magic enum register_file to hardware register file correspondance anyway.
2011-11-23 10:13:39 -08:00
static uint32_t brw_file_from_reg(fs_reg *reg)
{
switch (reg->file) {
case ARF:
return BRW_ARCHITECTURE_REGISTER_FILE;
case GRF:
return BRW_GENERAL_REGISTER_FILE;
case MRF:
return BRW_MESSAGE_REGISTER_FILE;
case IMM:
return BRW_IMMEDIATE_VALUE;
default:
assert(!"not reached");
return BRW_GENERAL_REGISTER_FILE;
}
}
i965/fs: Split the BRW native code emit to brw_fs_emit.cpp This is all separate from the visitor and the optimization passes which feed into it. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2011-05-24 16:34:27 -07:00
static struct brw_reg
brw_reg_from_fs_reg(fs_reg *reg)
{
struct brw_reg brw_reg;
switch (reg->file) {
case GRF:
case ARF:
case MRF:
if (reg->smear == -1) {
i965/fs: Make register file enum 0 be the undefined register file. In 6d874d0ee18b3694c49e0206fa519bd8b746ec24, I checked whether a register that had been stored was BAD_FILE (as opposed to a legitimate GRF), but actually the unset register was ARF NULL because it had been memset to 0. Finding BAD_FILE for unset values in debugging was my intention with that file, so make it the case more often by rearranging the enum. There was only one place we relied on the magic enum register_file to hardware register file correspondance anyway.
2011-11-23 10:13:39 -08:00
brw_reg = brw_vec8_reg(brw_file_from_reg(reg), reg->reg, 0);
i965/fs: Split the BRW native code emit to brw_fs_emit.cpp This is all separate from the visitor and the optimization passes which feed into it. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2011-05-24 16:34:27 -07:00
} else {
i965/fs: Make register file enum 0 be the undefined register file. In 6d874d0ee18b3694c49e0206fa519bd8b746ec24, I checked whether a register that had been stored was BAD_FILE (as opposed to a legitimate GRF), but actually the unset register was ARF NULL because it had been memset to 0. Finding BAD_FILE for unset values in debugging was my intention with that file, so make it the case more often by rearranging the enum. There was only one place we relied on the magic enum register_file to hardware register file correspondance anyway.
2011-11-23 10:13:39 -08:00
brw_reg = brw_vec1_reg(brw_file_from_reg(reg), reg->reg, reg->smear);
i965/fs: Split the BRW native code emit to brw_fs_emit.cpp This is all separate from the visitor and the optimization passes which feed into it. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2011-05-24 16:34:27 -07:00
}
brw_reg = retype(brw_reg, reg->type);
if (reg->sechalf)
brw_reg = sechalf(brw_reg);
break;
case IMM:
switch (reg->type) {
case BRW_REGISTER_TYPE_F:
brw_reg = brw_imm_f(reg->imm.f);
break;
case BRW_REGISTER_TYPE_D:
brw_reg = brw_imm_d(reg->imm.i);
break;
case BRW_REGISTER_TYPE_UD:
brw_reg = brw_imm_ud(reg->imm.u);
break;
default:
assert(!"not reached");
brw_reg = brw_null_reg();
break;
}
break;
case FIXED_HW_REG:
brw_reg = reg->fixed_hw_reg;
break;
case BAD_FILE:
/* Probably unused. */
brw_reg = brw_null_reg();
break;
case UNIFORM:
assert(!"not reached");
brw_reg = brw_null_reg();
break;
default:
assert(!"not reached");
brw_reg = brw_null_reg();
break;
}
if (reg->abs)
brw_reg = brw_abs(brw_reg);
if (reg->negate)
brw_reg = negate(brw_reg);
return brw_reg;
}
i965/fs: Set up gen7 UBO loads as sends from GRFs. This gives the instruction scheduler a chance to schedule between the loads, whereas before it was restricted due to the dependencies between the MRFs for setting them up. For one shader in gles3conform, it goes from getting stuck in register allocation for as long as anybody's bothered to leave it running down to 23 seconds, thanks to the LIFO scheduling. Acked-by: Kenneth Graunke <kenneth@whitecape.org>
2012-12-05 00:06:30 -08:00
/**
* Sets the second dword of a vgrf for gen7+ message setup.
*
* For setting up gen7 messages in VGRFs, we need to be able to set the second
* dword for some payloads where in the MRF world we'd have just used
* brw_message_reg(). We don't want to bake it into the send message's code
* generation because that means we don't get a chance to schedule the
* instructions.
*/
void
fs_generator::generate_set_global_offset(fs_inst *inst,
struct brw_reg dst,
struct brw_reg src,
struct brw_reg value)
{
/* We use a matching src and dst to get the information on how this
* instruction works exposed to various optimization passes that would
* otherwise treat it as completely overwriting the dst.
*/
assert(src.file == dst.file && src.nr == dst.nr);
assert(value.file == BRW_IMMEDIATE_VALUE);
brw_push_insn_state(p);
brw_set_compression_control(p, BRW_COMPRESSION_NONE);
brw_set_mask_control(p, BRW_MASK_DISABLE);
brw_MOV(p, retype(brw_vec1_reg(dst.file, dst.nr, 2), value.type), value);
brw_pop_insn_state(p);
}
i965/fs: Split the BRW native code emit to brw_fs_emit.cpp This is all separate from the visitor and the optimization passes which feed into it. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2011-05-24 16:34:27 -07:00
void
i965/fs: Split final assembly code generation out of fs_visitor. Compiling shaders requires several main steps: 1. Generating FS 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 "fs_generator." There are several reasons for doing so: 1. Future hardware has a different instruction encoding. Splitting this out will allow us to replace fs_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 fs_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 fs_visitor and create IR, while ADD() in fs_generator() can create brw_instructions. (Patches for this upcoming.) Furthermore, this patch changes the order of operations slightly. Rather than doing steps 1-4 for SIMD8, then 1-4 for SIMD16, we now: - Do steps 1-3 for SIMD8, then repeat 1-3 for SIMD16 - Generate final assembly code for both modes together This is because the frontend work can be done independently, but final assembly generation needs to pack both into a single program store to feed the GPU. Reviewed-by: Eric Anholt <eric@anholt.net> Reviewed-by: Paul Berry <stereotype441@gmail.com>
2012-11-09 01:05:47 -08:00
fs_generator::generate_code(exec_list *instructions)
i965/fs: Split the BRW native code emit to brw_fs_emit.cpp This is all separate from the visitor and the optimization passes which feed into it. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2011-05-24 16:34:27 -07:00
{
i965: Move program dump to a helper function in brw_eu.c. It's going to get more complicated when we do instruction compaction. This also introduces putting the program offset in the output. v2: Use next_insn_offset in brw_get_program(), too. Reviewed-by: Paul Berry <stereotype441@gmail.com>
2012-02-03 11:50:42 +01:00
int last_native_insn_offset = p->next_insn_offset;
i965/fs: Split the BRW native code emit to brw_fs_emit.cpp This is all separate from the visitor and the optimization passes which feed into it. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2011-05-24 16:34:27 -07:00
const char *last_annotation_string = NULL;
i965: Replace brw_wm_* with dumping code into the fs_visitor. This makes a giant pile of code newly dead. It also fixes TXB on newer chipsets, which has been totally broken (I now have a piglit test for that). It passes the same set of Ian's ARB_fragment_program tests. It also improves high-settings ETQW performance by 3.2 +/- 1.9% (n=3), thanks to better optimization and having 8-wide along with 16-wide shaders. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=24355 Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2012-08-27 14:35:01 -07:00
const void *last_annotation_ir = NULL;
i965/fs: Split the BRW native code emit to brw_fs_emit.cpp This is all separate from the visitor and the optimization passes which feed into it. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2011-05-24 16:34:27 -07:00
if (unlikely(INTEL_DEBUG & DEBUG_WM)) {
i965: Replace brw_wm_* with dumping code into the fs_visitor. This makes a giant pile of code newly dead. It also fixes TXB on newer chipsets, which has been totally broken (I now have a piglit test for that). It passes the same set of Ian's ARB_fragment_program tests. It also improves high-settings ETQW performance by 3.2 +/- 1.9% (n=3), thanks to better optimization and having 8-wide along with 16-wide shaders. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=24355 Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2012-08-27 14:35:01 -07:00
if (shader) {
printf("Native code for fragment shader %d (%d-wide dispatch):\n",
i965/fs: Move brw_wm_compile::dispatch_width into fs_visitor. Also, rather than having brw_wm_fs_emit poke at it directly, make it a parameter to the fs_visitor constructor. All other changes generated by search and replace (with occasional whitespace fixup). v2: Make dispatch_width const (as suggested by Paul); fix doxygen mistake (pointed out by Eric); update for rebase. Reviewed-by: Eric Anholt <eric@anholt.net> Reviewed-by: Paul Berry <stereotype441@gmail.com>
2012-11-20 13:50:52 -08:00
prog->Name, dispatch_width);
i965: Replace brw_wm_* with dumping code into the fs_visitor. This makes a giant pile of code newly dead. It also fixes TXB on newer chipsets, which has been totally broken (I now have a piglit test for that). It passes the same set of Ian's ARB_fragment_program tests. It also improves high-settings ETQW performance by 3.2 +/- 1.9% (n=3), thanks to better optimization and having 8-wide along with 16-wide shaders. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=24355 Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2012-08-27 14:35:01 -07:00
} else {
printf("Native code for fragment program %d (%d-wide dispatch):\n",
i965/fs: Move brw_wm_compile::fp to fs_visitor. Also change it from a brw_fragment_program to a gl_fragment_program, since that seems to be what everything wants anyway. Reviewed-by: Eric Anholt <eric@anholt.net> Reviewed-by: Paul Berry <stereotype441@gmail.com>
2012-11-20 14:41:21 -08:00
fp->Base.Id, dispatch_width);
i965: Replace brw_wm_* with dumping code into the fs_visitor. This makes a giant pile of code newly dead. It also fixes TXB on newer chipsets, which has been totally broken (I now have a piglit test for that). It passes the same set of Ian's ARB_fragment_program tests. It also improves high-settings ETQW performance by 3.2 +/- 1.9% (n=3), thanks to better optimization and having 8-wide along with 16-wide shaders. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=24355 Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2012-08-27 14:35:01 -07:00
}
i965/fs: Split the BRW native code emit to brw_fs_emit.cpp This is all separate from the visitor and the optimization passes which feed into it. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2011-05-24 16:34:27 -07:00
}
i965: Rename fs_cfg types to not mention fs. fs_bblock_link -> bblock_link fs_bblock -> bblock_t (to avoid conflicting with all the fs_bblock *bblock) fs_cfg -> cfg_t (to avoid conflicting with all the fs_cfg *cfg) Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2012-10-03 13:16:09 -07:00
cfg_t *cfg = NULL;
i965: Add basic block generator. This takes the fs_inst list generated by the visitor, and generates a list of basic blocks with edges between them. This is a building block for data-flow analysis.
2012-04-10 12:01:50 -07:00
if (unlikely(INTEL_DEBUG & DEBUG_WM))
i965/fs: Split final assembly code generation out of fs_visitor. Compiling shaders requires several main steps: 1. Generating FS 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 "fs_generator." There are several reasons for doing so: 1. Future hardware has a different instruction encoding. Splitting this out will allow us to replace fs_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 fs_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 fs_visitor and create IR, while ADD() in fs_generator() can create brw_instructions. (Patches for this upcoming.) Furthermore, this patch changes the order of operations slightly. Rather than doing steps 1-4 for SIMD8, then 1-4 for SIMD16, we now: - Do steps 1-3 for SIMD8, then repeat 1-3 for SIMD16 - Generate final assembly code for both modes together This is because the frontend work can be done independently, but final assembly generation needs to pack both into a single program store to feed the GPU. Reviewed-by: Eric Anholt <eric@anholt.net> Reviewed-by: Paul Berry <stereotype441@gmail.com>
2012-11-09 01:05:47 -08:00
cfg = new(mem_ctx) cfg_t(mem_ctx, instructions);
i965: Add basic block generator. This takes the fs_inst list generated by the visitor, and generates a list of basic blocks with edges between them. This is a building block for data-flow analysis.
2012-04-10 12:01:50 -07:00
i965/fs: Split final assembly code generation out of fs_visitor. Compiling shaders requires several main steps: 1. Generating FS 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 "fs_generator." There are several reasons for doing so: 1. Future hardware has a different instruction encoding. Splitting this out will allow us to replace fs_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 fs_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 fs_visitor and create IR, while ADD() in fs_generator() can create brw_instructions. (Patches for this upcoming.) Furthermore, this patch changes the order of operations slightly. Rather than doing steps 1-4 for SIMD8, then 1-4 for SIMD16, we now: - Do steps 1-3 for SIMD8, then repeat 1-3 for SIMD16 - Generate final assembly code for both modes together This is because the frontend work can be done independently, but final assembly generation needs to pack both into a single program store to feed the GPU. Reviewed-by: Eric Anholt <eric@anholt.net> Reviewed-by: Paul Berry <stereotype441@gmail.com>
2012-11-09 01:05:47 -08:00
foreach_list(node, instructions) {
i965/fs: Stop using the exec_list iterator. The old style has gone out of favor in the project, but I kept copy and pasting from existing iterator code.
2011-07-29 11:52:39 -07:00
fs_inst *inst = (fs_inst *)node;
i965/fs: Split the BRW native code emit to brw_fs_emit.cpp This is all separate from the visitor and the optimization passes which feed into it. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2011-05-24 16:34:27 -07:00
struct brw_reg src[3], dst;
if (unlikely(INTEL_DEBUG & DEBUG_WM)) {
i965: Add basic block generator. This takes the fs_inst list generated by the visitor, and generates a list of basic blocks with edges between them. This is a building block for data-flow analysis.
2012-04-10 12:01:50 -07:00
foreach_list(node, &cfg->block_list) {
i965: Rename fs_cfg types to not mention fs. fs_bblock_link -> bblock_link fs_bblock -> bblock_t (to avoid conflicting with all the fs_bblock *bblock) fs_cfg -> cfg_t (to avoid conflicting with all the fs_cfg *cfg) Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2012-10-03 13:16:09 -07:00
bblock_link *link = (bblock_link *)node;
bblock_t *block = link->block;
i965: Add basic block generator. This takes the fs_inst list generated by the visitor, and generates a list of basic blocks with edges between them. This is a building block for data-flow analysis.
2012-04-10 12:01:50 -07:00
if (block->start == inst) {
printf(" START B%d", block->block_num);
foreach_list(predecessor_node, &block->parents) {
i965: Rename fs_cfg types to not mention fs. fs_bblock_link -> bblock_link fs_bblock -> bblock_t (to avoid conflicting with all the fs_bblock *bblock) fs_cfg -> cfg_t (to avoid conflicting with all the fs_cfg *cfg) Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2012-10-03 13:16:09 -07:00
bblock_link *predecessor_link =
(bblock_link *)predecessor_node;
bblock_t *predecessor_block = predecessor_link->block;
i965: Add basic block generator. This takes the fs_inst list generated by the visitor, and generates a list of basic blocks with edges between them. This is a building block for data-flow analysis.
2012-04-10 12:01:50 -07:00
printf(" <-B%d", predecessor_block->block_num);
}
printf("\n");
}
}
i965/fs: Split the BRW native code emit to brw_fs_emit.cpp This is all separate from the visitor and the optimization passes which feed into it. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2011-05-24 16:34:27 -07:00
if (last_annotation_ir != inst->ir) {
last_annotation_ir = inst->ir;
if (last_annotation_ir) {
printf(" ");
i965: Replace brw_wm_* with dumping code into the fs_visitor. This makes a giant pile of code newly dead. It also fixes TXB on newer chipsets, which has been totally broken (I now have a piglit test for that). It passes the same set of Ian's ARB_fragment_program tests. It also improves high-settings ETQW performance by 3.2 +/- 1.9% (n=3), thanks to better optimization and having 8-wide along with 16-wide shaders. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=24355 Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2012-08-27 14:35:01 -07:00
if (shader)
((ir_instruction *)inst->ir)->print();
else {
const prog_instruction *fpi;
fpi = (const prog_instruction *)inst->ir;
printf("%d: ", (int)(fpi - fp->Base.Instructions));
_mesa_fprint_instruction_opt(stdout,
fpi,
0, PROG_PRINT_DEBUG, NULL);
}
i965/fs: Split the BRW native code emit to brw_fs_emit.cpp This is all separate from the visitor and the optimization passes which feed into it. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2011-05-24 16:34:27 -07:00
printf("\n");
}
}
if (last_annotation_string != inst->annotation) {
last_annotation_string = inst->annotation;
if (last_annotation_string)
printf(" %s\n", last_annotation_string);
}
}
for (unsigned int i = 0; i < 3; i++) {
src[i] = brw_reg_from_fs_reg(&inst->src[i]);
i965/fs: Fix comparisions 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 fs-op-neg-* Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
2011-10-03 15:12:10 -07:00
/* The accumulator result appears to get used for the
* conditional modifier generation. When negating a UD
* value, there is a 33rd bit generated for the sign in the
* accumulator value, so now you can't check, for example,
* equality with a 32-bit value. See piglit fs-op-neg-uvec4.
*/
assert(!inst->conditional_mod ||
inst->src[i].type != BRW_REGISTER_TYPE_UD ||
!inst->src[i].negate);
i965/fs: Split the BRW native code emit to brw_fs_emit.cpp This is all separate from the visitor and the optimization passes which feed into it. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2011-05-24 16:34:27 -07:00
}
dst = brw_reg_from_fs_reg(&inst->dst);
brw_set_conditionalmod(p, inst->conditional_mod);
i965: Share the predicate field between FS and VS. Note that BRW_PREDICATE_NONE is 0 and BRW_PREDICATE_NORMAL is 1, so that's a lot like the true/false we had in the FS before. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2012-10-03 13:23:05 -07:00
brw_set_predicate_control(p, inst->predicate);
i965/fs: Split the BRW native code emit to brw_fs_emit.cpp This is all separate from the visitor and the optimization passes which feed into it. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2011-05-24 16:34:27 -07:00
brw_set_predicate_inverse(p, inst->predicate_inverse);
i965/fs: Add an instruction flag for choosing the flag subregister. We're going to redo discard handling to track discards in the other flag subregister, saving instructions in the discard and allowing predicated jumps out to the end of the shader. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2012-12-06 10:36:11 -08:00
brw_set_flag_reg(p, 0, inst->flag_subreg);
i965/fs: Split the BRW native code emit to brw_fs_emit.cpp This is all separate from the visitor and the optimization passes which feed into it. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2011-05-24 16:34:27 -07:00
brw_set_saturate(p, inst->saturate);
i965: Add a flag for instructions with normal writemasking disabled. For getting values from the new timestamp register, the channels we load have nothing to do with the pixels dispatched.
2012-11-28 14:16:03 -08:00
brw_set_mask_control(p, inst->force_writemask_all);
i965/fs: Split the BRW native code emit to brw_fs_emit.cpp This is all separate from the visitor and the optimization passes which feed into it. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2011-05-24 16:34:27 -07:00
i965/fs: Move brw_wm_compile::dispatch_width into fs_visitor. Also, rather than having brw_wm_fs_emit poke at it directly, make it a parameter to the fs_visitor constructor. All other changes generated by search and replace (with occasional whitespace fixup). v2: Make dispatch_width const (as suggested by Paul); fix doxygen mistake (pointed out by Eric); update for rebase. Reviewed-by: Eric Anholt <eric@anholt.net> Reviewed-by: Paul Berry <stereotype441@gmail.com>
2012-11-20 13:50:52 -08:00
if (inst->force_uncompressed || dispatch_width == 8) {
i965/fs: Split the BRW native code emit to brw_fs_emit.cpp This is all separate from the visitor and the optimization passes which feed into it. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2011-05-24 16:34:27 -07:00
brw_set_compression_control(p, BRW_COMPRESSION_NONE);
} else if (inst->force_sechalf) {
brw_set_compression_control(p, BRW_COMPRESSION_2NDHALF);
} else {
brw_set_compression_control(p, BRW_COMPRESSION_COMPRESSED);
}
switch (inst->opcode) {
case BRW_OPCODE_MOV:
brw_MOV(p, dst, src[0]);
break;
case BRW_OPCODE_ADD:
brw_ADD(p, dst, src[0], src[1]);
break;
case BRW_OPCODE_MUL:
brw_MUL(p, dst, src[0], src[1]);
break;
i965/fs: Fix 32-bit integer multiplication. The MUL opcode does a 16bit * 32bit multiply, and we need to do the MACH to get the top 16bit * 32bit added in. Fixes fs-op-mult-int-*, fs-op-mult-ivec* Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2011-08-15 22:36:18 -07:00
case BRW_OPCODE_MACH:
brw_set_acc_write_control(p, 1);
brw_MACH(p, dst, src[0], src[1]);
brw_set_acc_write_control(p, 0);
break;
i965/fs: Split the BRW native code emit to brw_fs_emit.cpp This is all separate from the visitor and the optimization passes which feed into it. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2011-05-24 16:34:27 -07:00
i965/fs: Add support for generating MADs. Improves nexuiz performance 0.65% +/- .10% (n=5) on my gen6, and .39% +/- .11% (n=10) on gen7. No statistically significant performance difference on warsow (n=5, but only one shader has MADs). v2: Add support for MADs in 16-wide by using compression control. v3: Don't generate MADs when it will force an immediate to be moved to a temp. (it's not clear whether this is a win or not, but it should result in less questionable change to codegen compared to v2). Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> (v2)
2012-02-07 00:59:11 +01:00
case BRW_OPCODE_MAD:
brw_set_access_mode(p, BRW_ALIGN_16);
i965/fs: Move brw_wm_compile::dispatch_width into fs_visitor. Also, rather than having brw_wm_fs_emit poke at it directly, make it a parameter to the fs_visitor constructor. All other changes generated by search and replace (with occasional whitespace fixup). v2: Make dispatch_width const (as suggested by Paul); fix doxygen mistake (pointed out by Eric); update for rebase. Reviewed-by: Eric Anholt <eric@anholt.net> Reviewed-by: Paul Berry <stereotype441@gmail.com>
2012-11-20 13:50:52 -08:00
if (dispatch_width == 16) {
i965/fs: Add support for generating MADs. Improves nexuiz performance 0.65% +/- .10% (n=5) on my gen6, and .39% +/- .11% (n=10) on gen7. No statistically significant performance difference on warsow (n=5, but only one shader has MADs). v2: Add support for MADs in 16-wide by using compression control. v3: Don't generate MADs when it will force an immediate to be moved to a temp. (it's not clear whether this is a win or not, but it should result in less questionable change to codegen compared to v2). Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> (v2)
2012-02-07 00:59:11 +01:00
brw_set_compression_control(p, BRW_COMPRESSION_NONE);
brw_MAD(p, dst, src[0], src[1], src[2]);
brw_set_compression_control(p, BRW_COMPRESSION_2NDHALF);
brw_MAD(p, sechalf(dst), sechalf(src[0]), sechalf(src[1]), sechalf(src[2]));
brw_set_compression_control(p, BRW_COMPRESSION_COMPRESSED);
} else {
brw_MAD(p, dst, src[0], src[1], src[2]);
}
brw_set_access_mode(p, BRW_ALIGN_1);
break;
i965/fs: Split the BRW native code emit to brw_fs_emit.cpp This is all separate from the visitor and the optimization passes which feed into it. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2011-05-24 16:34:27 -07:00
case BRW_OPCODE_FRC:
brw_FRC(p, dst, src[0]);
break;
case BRW_OPCODE_RNDD:
brw_RNDD(p, dst, src[0]);
break;
case BRW_OPCODE_RNDE:
brw_RNDE(p, dst, src[0]);
break;
case BRW_OPCODE_RNDZ:
brw_RNDZ(p, dst, src[0]);
break;
case BRW_OPCODE_AND:
brw_AND(p, dst, src[0], src[1]);
break;
case BRW_OPCODE_OR:
brw_OR(p, dst, src[0], src[1]);
break;
case BRW_OPCODE_XOR:
brw_XOR(p, dst, src[0], src[1]);
break;
case BRW_OPCODE_NOT:
brw_NOT(p, dst, src[0]);
break;
case BRW_OPCODE_ASR:
brw_ASR(p, dst, src[0], src[1]);
break;
case BRW_OPCODE_SHR:
brw_SHR(p, dst, src[0], src[1]);
break;
case BRW_OPCODE_SHL:
brw_SHL(p, dst, src[0], src[1]);
break;
case BRW_OPCODE_CMP:
brw_CMP(p, dst, inst->conditional_mod, src[0], src[1]);
break;
case BRW_OPCODE_SEL:
brw_SEL(p, dst, src[0], src[1]);
break;
case BRW_OPCODE_IF:
if (inst->src[0].file != BAD_FILE) {
/* The instruction has an embedded compare (only allowed on gen6) */
assert(intel->gen == 6);
gen6_IF(p, inst->conditional_mod, src[0], src[1]);
} else {
i965/fs: Move brw_wm_compile::dispatch_width into fs_visitor. Also, rather than having brw_wm_fs_emit poke at it directly, make it a parameter to the fs_visitor constructor. All other changes generated by search and replace (with occasional whitespace fixup). v2: Make dispatch_width const (as suggested by Paul); fix doxygen mistake (pointed out by Eric); update for rebase. Reviewed-by: Eric Anholt <eric@anholt.net> Reviewed-by: Paul Berry <stereotype441@gmail.com>
2012-11-20 13:50:52 -08:00
brw_IF(p, dispatch_width == 16 ? BRW_EXECUTE_16 : BRW_EXECUTE_8);
i965/fs: Split the BRW native code emit to brw_fs_emit.cpp This is all separate from the visitor and the optimization passes which feed into it. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2011-05-24 16:34:27 -07:00
}
break;
case BRW_OPCODE_ELSE:
brw_ELSE(p);
break;
case BRW_OPCODE_ENDIF:
brw_ENDIF(p);
break;
case BRW_OPCODE_DO:
i965: Don't make consumers of brw_WHILE do pre-gen6 BREAK/CONT patching. The EU code itself can just do this work, since all the consumers were duplicating it. Reviewed-by: Yuanhan Liu <yuanhan.liu@linux.intel.com>
2011-12-06 12:30:03 -08:00
brw_DO(p, BRW_EXECUTE_8);
i965/fs: Split the BRW native code emit to brw_fs_emit.cpp This is all separate from the visitor and the optimization passes which feed into it. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2011-05-24 16:34:27 -07:00
break;
case BRW_OPCODE_BREAK:
i965: Don't make consumers of brw_CONT/brw_WHILE track if depth in loop. The codegen backends all had this same tracking, so just do it at the EU level. Reviewed-by: Yuanhan Liu <yuanhan.liu@linux.intel.com>
2011-12-06 12:44:41 -08:00
brw_BREAK(p);
i965/fs: Split the BRW native code emit to brw_fs_emit.cpp This is all separate from the visitor and the optimization passes which feed into it. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2011-05-24 16:34:27 -07:00
brw_set_predicate_control(p, BRW_PREDICATE_NONE);
break;
case BRW_OPCODE_CONTINUE:
/* FINISHME: We need to write the loop instruction support still. */
if (intel->gen >= 6)
i965: Drop unused do_insn argument from gen6_CONT(). The branch distances get patched up later at the WHILE instruction. Reviewed-by: Yuanhan Liu <yuanhan.liu@linux.intel.com>
2011-12-06 12:09:58 -08:00
gen6_CONT(p);
i965/fs: Split the BRW native code emit to brw_fs_emit.cpp This is all separate from the visitor and the optimization passes which feed into it. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2011-05-24 16:34:27 -07:00
else
i965: Don't make consumers of brw_CONT/brw_WHILE track if depth in loop. The codegen backends all had this same tracking, so just do it at the EU level. Reviewed-by: Yuanhan Liu <yuanhan.liu@linux.intel.com>
2011-12-06 12:44:41 -08:00
brw_CONT(p);
i965/fs: Split the BRW native code emit to brw_fs_emit.cpp This is all separate from the visitor and the optimization passes which feed into it. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2011-05-24 16:34:27 -07:00
brw_set_predicate_control(p, BRW_PREDICATE_NONE);
break;
i965: Don't make consumers of brw_WHILE do pre-gen6 BREAK/CONT patching. The EU code itself can just do this work, since all the consumers were duplicating it. Reviewed-by: Yuanhan Liu <yuanhan.liu@linux.intel.com>
2011-12-06 12:30:03 -08:00
case BRW_OPCODE_WHILE:
brw_WHILE(p);
i965/fs: Split the BRW native code emit to brw_fs_emit.cpp This is all separate from the visitor and the optimization passes which feed into it. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2011-05-24 16:34:27 -07:00
break;
i965: Rename math FS_OPCODE_* to SHADER_OPCODE_*. I want to just use the same enums in the VS.
2011-08-05 12:38:58 -07:00
case SHADER_OPCODE_RCP:
case SHADER_OPCODE_RSQ:
case SHADER_OPCODE_SQRT:
case SHADER_OPCODE_EXP2:
case SHADER_OPCODE_LOG2:
case SHADER_OPCODE_SIN:
case SHADER_OPCODE_COS:
i965: Enable faster workaround-free math on Ivybridge. According to the documentation, Ivybridge's math instruction works in SIMD16 mode for the fragment shader, and no longer forbids align16 mode for the vertex shader. The documentation claims that SIMD16 mode isn't supported for INT DIV, but empirical evidence shows that it works fine. Presumably the note is trying to warn us that the variant that returns both quotient and remainder in (dst, dst + 1) doesn't work in SIMD16 mode since dst + 1 would be sechalf(dst), trashing half your results. Since we don't use that variant, we don't care and can just enable SIMD16 everywhere. The documentation also still claims that source modifiers and conditional modifiers aren't supported, but empirical evidence and study of the simulator both show that they work just fine. Goodbye workarounds. Math just works now. Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Paul Berry <stereotype441@gmail.com>
2011-10-18 12:24:47 -07:00
if (intel->gen >= 7) {
generate_math1_gen7(inst, dst, src[0]);
} else if (intel->gen == 6) {
i965/fs: Split generate_math into gen4/gen6 and 1/2 operand variants. This mirrors the structure Eric used in the new VS backend, and seems simpler. In particular, the math1/math2 split will avoid having to figure out how many operands there are, as this is already known by the caller. Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Eric Anholt <eric@anholt.net>
2011-08-18 11:55:42 -07:00
generate_math1_gen6(inst, dst, src[0]);
} else {
generate_math_gen4(inst, dst, src[0]);
}
break;
i965/fs: Implement integer quotient and remainder math operations. Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Tested-by: Ian Romanick <ian.d.romanick@intel.com> Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Reviewed-by: Eric Anholt <eric@anholt.net>
2011-09-28 17:37:54 -07:00
case SHADER_OPCODE_INT_QUOTIENT:
case SHADER_OPCODE_INT_REMAINDER:
i965/fs: Split generate_math into gen4/gen6 and 1/2 operand variants. This mirrors the structure Eric used in the new VS backend, and seems simpler. In particular, the math1/math2 split will avoid having to figure out how many operands there are, as this is already known by the caller. Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Eric Anholt <eric@anholt.net>
2011-08-18 11:55:42 -07:00
case SHADER_OPCODE_POW:
i965: Fix Sandybridge regression introduced by workaround-free math. Commit a73c65c5342bf41fa0dfefe7daa9197ce6a11db4 had a typo which accidentally enabled the workaround-free Gen7 code on Gen6. Fixes GPU hangs in anything using pow() or integer division/modulus. Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
2011-11-07 12:07:44 -08:00
if (intel->gen >= 7) {
i965: Enable faster workaround-free math on Ivybridge. According to the documentation, Ivybridge's math instruction works in SIMD16 mode for the fragment shader, and no longer forbids align16 mode for the vertex shader. The documentation claims that SIMD16 mode isn't supported for INT DIV, but empirical evidence shows that it works fine. Presumably the note is trying to warn us that the variant that returns both quotient and remainder in (dst, dst + 1) doesn't work in SIMD16 mode since dst + 1 would be sechalf(dst), trashing half your results. Since we don't use that variant, we don't care and can just enable SIMD16 everywhere. The documentation also still claims that source modifiers and conditional modifiers aren't supported, but empirical evidence and study of the simulator both show that they work just fine. Goodbye workarounds. Math just works now. Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Paul Berry <stereotype441@gmail.com>
2011-10-18 12:24:47 -07:00
generate_math2_gen7(inst, dst, src[0], src[1]);
} else if (intel->gen == 6) {
i965/fs: Split generate_math into gen4/gen6 and 1/2 operand variants. This mirrors the structure Eric used in the new VS backend, and seems simpler. In particular, the math1/math2 split will avoid having to figure out how many operands there are, as this is already known by the caller. Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Eric Anholt <eric@anholt.net>
2011-08-18 11:55:42 -07:00
generate_math2_gen6(inst, dst, src[0], src[1]);
} else {
generate_math_gen4(inst, dst, src[0]);
}
i965/fs: Split the BRW native code emit to brw_fs_emit.cpp This is all separate from the visitor and the optimization passes which feed into it. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2011-05-24 16:34:27 -07:00
break;
case FS_OPCODE_PIXEL_X:
generate_pixel_xy(dst, true);
break;
case FS_OPCODE_PIXEL_Y:
generate_pixel_xy(dst, false);
break;
case FS_OPCODE_CINTERP:
brw_MOV(p, dst, src[0]);
break;
case FS_OPCODE_LINTERP:
generate_linterp(inst, dst, src);
break;
i965: Rename texturing ops from FS_OPCODE to SHADER_OPCODE, except TXB. We'll be reusing most of these for the VS shortly. The one exception is TXB (texturing with LOD bias), which is explicitly forbidden in the VS. Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Eric Anholt <eric@anholt.net>
2011-10-26 12:58:37 -07:00
case SHADER_OPCODE_TEX:
i965/fs: Split the BRW native code emit to brw_fs_emit.cpp This is all separate from the visitor and the optimization passes which feed into it. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2011-05-24 16:34:27 -07:00
case FS_OPCODE_TXB:
i965: Rename texturing ops from FS_OPCODE to SHADER_OPCODE, except TXB. We'll be reusing most of these for the VS shortly. The one exception is TXB (texturing with LOD bias), which is explicitly forbidden in the VS. Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Eric Anholt <eric@anholt.net>
2011-10-26 12:58:37 -07:00
case SHADER_OPCODE_TXD:
case SHADER_OPCODE_TXF:
case SHADER_OPCODE_TXL:
case SHADER_OPCODE_TXS:
i965/fs: Split the BRW native code emit to brw_fs_emit.cpp This is all separate from the visitor and the optimization passes which feed into it. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2011-05-24 16:34:27 -07:00
generate_tex(inst, dst, src[0]);
break;
case FS_OPCODE_DDX:
generate_ddx(inst, dst, src[0]);
break;
case FS_OPCODE_DDY:
i965: Avoid unnecessary recompiles for shaders that don't use dFdy(). The i965 back-end needs to compile dFdy() differently for FBOs and window system framebuffers, because Y coordinates are flipped between the two (see commit 82d2596: i965: Compute dFdy() correctly for FBOs). This patch avoids unnecessarily recompiling shaders that don't use dFdy(), by only setting render_to_fbo in the wm program key if the shader actually uses dFdy(). Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
2012-06-20 13:40:45 -07:00
/* Make sure fp->UsesDFdy flag got set (otherwise there's no
* guarantee that c->key.render_to_fbo is set).
*/
assert(fp->UsesDFdy);
i965: Compute dFdy() correctly for FBOs. On i965, dFdx() and dFdy() are computed by taking advantage of the fact that each consecutive set of 4 pixels dispatched to the fragment shader always constitutes a contiguous 2x2 block of pixels in a fixed arrangement known as a "sub-span". So we calculate dFdx() by taking the difference between the values computed for the left and right halves of the sub-span, and we calculate dFdy() by taking the difference between the values computed for the top and bottom halves of the sub-span. However, there's a subtlety when FBOs are in use: since FBOs use a coordinate system where the origin is at the upper left, and window system framebuffers use a coordinate system where the origin is at the lower left, the computation of dFdy() needs to be negated for FBOs. This patch modifies the fragment shader back-ends to negate the value of dFdy() when an FBO is in use. It also modifies the code that populates the program key (brw_wm_populate_key() and brw_fs_precompile()) so that they always record in the program key whether we are rendering to an FBO or to a window system framebuffer; this ensures that the fragment shader will get recompiled when switching between FBO and non-FBO use. This will result in unnecessary recompiles of fragment shaders that don't use dFdy(). To fix that, we will need to adapt the GLSL and NV_fragment_program front-ends to record whether or not a given shader uses dFdy(). I plan to implement this in a future patch series; I've left FIXME comments in the code as a reminder. Fixes Piglit test "fbo-deriv". NOTE: This is a candidate for stable release branches. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2012-06-20 13:40:45 -07:00
generate_ddy(inst, dst, src[0], c->key.render_to_fbo);
i965/fs: Split the BRW native code emit to brw_fs_emit.cpp This is all separate from the visitor and the optimization passes which feed into it. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2011-05-24 16:34:27 -07:00
break;
case FS_OPCODE_SPILL:
generate_spill(inst, src[0]);
break;
case FS_OPCODE_UNSPILL:
generate_unspill(inst, dst);
break;
i965/fs: Rename the existing pull constant load opcode. We're going to use another send message for handling loads with a varying per-fragment array index.
2012-11-07 10:42:34 -08:00
case FS_OPCODE_UNIFORM_PULL_CONSTANT_LOAD:
generate_uniform_pull_constant_load(inst, dst, src[0], src[1]);
i965/fs: Split the BRW native code emit to brw_fs_emit.cpp This is all separate from the visitor and the optimization passes which feed into it. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2011-05-24 16:34:27 -07:00
break;
i965/fs: Set up gen7 UBO loads as sends from GRFs. This gives the instruction scheduler a chance to schedule between the loads, whereas before it was restricted due to the dependencies between the MRFs for setting them up. For one shader in gles3conform, it goes from getting stuck in register allocation for as long as anybody's bothered to leave it running down to 23 seconds, thanks to the LIFO scheduling. Acked-by: Kenneth Graunke <kenneth@whitecape.org>
2012-12-05 00:06:30 -08:00
case FS_OPCODE_UNIFORM_PULL_CONSTANT_LOAD_GEN7:
generate_uniform_pull_constant_load_gen7(inst, dst, src[0], src[1]);
break;
i965/fs: Add instruction emit for varying-index reads of uniforms. The gen7 send-from-GRF path is sufficiently different from the perspective of IR generation and optimization that I just made it a separate opcode. v2: fix whitespace, rebase on Ken's recent refactor.
2012-11-07 11:18:34 -08:00
case FS_OPCODE_VARYING_PULL_CONSTANT_LOAD:
generate_varying_pull_constant_load(inst, dst, src[0]);
break;
case FS_OPCODE_VARYING_PULL_CONSTANT_LOAD_GEN7:
generate_varying_pull_constant_load_gen7(inst, dst, src[0], src[1]);
break;
i965/fs: Split the BRW native code emit to brw_fs_emit.cpp This is all separate from the visitor and the optimization passes which feed into it. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2011-05-24 16:34:27 -07:00
case FS_OPCODE_FB_WRITE:
generate_fb_write(inst);
break;
i965/fs: Add FS_OPCODE_MOV_DISPATCH_TO_FLAGS to fragment shader backend. In order to compute centroid varyings correctly, the fragment shader needs to be able to load the current pixel/sample mask into a flag register. This patch adds an opcode to the fragment shader back-end to do this; the opcode gets translated into the instruction mov(1) f0<1>UW g1.14<0,1,0>UW { align1 WE_all } Since this instruction clobbers f0, instruction scheduling has to treat it the same as instructions that have a conditional modifier. Reviewed-by: Eric Anholt <eric@anholt.net>
2012-06-18 14:50:04 -07:00
case FS_OPCODE_MOV_DISPATCH_TO_FLAGS:
i965/fs: Add an instruction flag for choosing the flag subregister. We're going to redo discard handling to track discards in the other flag subregister, saving instructions in the discard and allowing predicated jumps out to the end of the shader. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2012-12-06 10:36:11 -08:00
generate_mov_dispatch_to_flags(inst);
i965/fs: Add FS_OPCODE_MOV_DISPATCH_TO_FLAGS to fragment shader backend. In order to compute centroid varyings correctly, the fragment shader needs to be able to load the current pixel/sample mask into a flag register. This patch adds an opcode to the fragment shader back-end to do this; the opcode gets translated into the instruction mov(1) f0<1>UW g1.14<0,1,0>UW { align1 WE_all } Since this instruction clobbers f0, instruction scheduling has to treat it the same as instructions that have a conditional modifier. Reviewed-by: Eric Anholt <eric@anholt.net>
2012-06-18 14:50:04 -07:00
break;
i965/fs: Improve performance of shaders that start out with a discard. I had tried this in the past, but ran into trouble with applications that sample from undiscarded pixels in the same subspan. To fix that issue, only jump to the end for an entire subspan at a time. Improves GLbenchmark 2.7 (1024x768) performance by 7.9 +/- 1.5% (n=8). v2: Drop the br variable in the jump instruction -- if I ever do jumps pre-gen6, it'll be a different code block anyway since we don't have HALT until gen6. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2012-12-06 10:15:08 -08:00
case FS_OPCODE_DISCARD_JUMP:
generate_discard_jump(inst);
break;
i965: Add a debug flag for counting cycles spent in each compiled shader. This can be used for two purposes: Using hand-coded shaders to determine per-instruction timings, or figuring out which shader to optimize in a whole application. Note that this doesn't cover the instructions that set up the message to the URB/FB write -- we'd need to convert the MRF usage in these instructions to GRFs so that our offsets/times don't overwrite our shader outputs. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> (v1) v2: Check the timestamp reset flag in the VS, which is apparently getting set fairly regularly in the range we watch, resulting in negative numbers getting added to our 32-bit counter, and thus large values added to our uint64_t. v3: Rebase on reladdr changes, removing a new safety check that proved impossible to satisfy. Add a comment to the AOP defs from Ken's review, and put them in a slightly more sensible spot. v4: Check timestamp reset in the FS as well.
2012-11-27 14:10:52 -08:00
case SHADER_OPCODE_SHADER_TIME_ADD:
brw_shader_time_add(p, inst->base_mrf, SURF_INDEX_WM_SHADER_TIME);
break;
i965/fs: Set up gen7 UBO loads as sends from GRFs. This gives the instruction scheduler a chance to schedule between the loads, whereas before it was restricted due to the dependencies between the MRFs for setting them up. For one shader in gles3conform, it goes from getting stuck in register allocation for as long as anybody's bothered to leave it running down to 23 seconds, thanks to the LIFO scheduling. Acked-by: Kenneth Graunke <kenneth@whitecape.org>
2012-12-05 00:06:30 -08:00
case FS_OPCODE_SET_GLOBAL_OFFSET:
generate_set_global_offset(inst, dst, src[0], src[1]);
break;
i965/fs: Split the BRW native code emit to brw_fs_emit.cpp This is all separate from the visitor and the optimization passes which feed into it. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2011-05-24 16:34:27 -07:00
default:
i965: Remove duplicate brw_opcodes table in favor of opcode_descs. brw_optimize.c's brw_opcodes table was a copy of brw_disasm.c's opcode_descs table, but with an additional field: is_arith. Now that I've deleted that, the two are identical. Keep the one in brw_disasm.c. Reviewed-by: Eric Anholt <eric@anholt.net>
2012-11-14 14:24:31 -08:00
if (inst->opcode < (int) ARRAY_SIZE(opcode_descs)) {
i965/fs: Split the BRW native code emit to brw_fs_emit.cpp This is all separate from the visitor and the optimization passes which feed into it. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2011-05-24 16:34:27 -07:00
_mesa_problem(ctx, "Unsupported opcode `%s' in FS",
i965: Remove duplicate brw_opcodes table in favor of opcode_descs. brw_optimize.c's brw_opcodes table was a copy of brw_disasm.c's opcode_descs table, but with an additional field: is_arith. Now that I've deleted that, the two are identical. Keep the one in brw_disasm.c. Reviewed-by: Eric Anholt <eric@anholt.net>
2012-11-14 14:24:31 -08:00
opcode_descs[inst->opcode].name);
i965/fs: Split the BRW native code emit to brw_fs_emit.cpp This is all separate from the visitor and the optimization passes which feed into it. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2011-05-24 16:34:27 -07:00
} else {
_mesa_problem(ctx, "Unsupported opcode %d in FS", inst->opcode);
}
i965/fs: Abort on unsupported opcodes rather than failing. Final code generation should never fail. This is a bug, and there should be no user-triggerable cases where this could occur. Also, we're not going to have a fail() method in a moment. v2: Just abort() rather than assert, to cover the NDEBUG case (suggested by Eric). Reviewed-by: Eric Anholt <eric@anholt.net> Reviewed-by: Paul Berry <stereotype441@gmail.com>
2012-11-20 17:02:23 -08:00
abort();
i965/fs: Split the BRW native code emit to brw_fs_emit.cpp This is all separate from the visitor and the optimization passes which feed into it. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2011-05-24 16:34:27 -07:00
}
if (unlikely(INTEL_DEBUG & DEBUG_WM)) {
i965: Move program dump to a helper function in brw_eu.c. It's going to get more complicated when we do instruction compaction. This also introduces putting the program offset in the output. v2: Use next_insn_offset in brw_get_program(), too. Reviewed-by: Paul Berry <stereotype441@gmail.com>
2012-02-03 11:50:42 +01:00
brw_dump_compile(p, stdout,
last_native_insn_offset, p->next_insn_offset);
i965: Add basic block generator. This takes the fs_inst list generated by the visitor, and generates a list of basic blocks with edges between them. This is a building block for data-flow analysis.
2012-04-10 12:01:50 -07:00
foreach_list(node, &cfg->block_list) {
i965: Rename fs_cfg types to not mention fs. fs_bblock_link -> bblock_link fs_bblock -> bblock_t (to avoid conflicting with all the fs_bblock *bblock) fs_cfg -> cfg_t (to avoid conflicting with all the fs_cfg *cfg) Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2012-10-03 13:16:09 -07:00
bblock_link *link = (bblock_link *)node;
bblock_t *block = link->block;
i965: Add basic block generator. This takes the fs_inst list generated by the visitor, and generates a list of basic blocks with edges between them. This is a building block for data-flow analysis.
2012-04-10 12:01:50 -07:00
if (block->end == inst) {
printf(" END B%d", block->block_num);
foreach_list(successor_node, &block->children) {
i965: Rename fs_cfg types to not mention fs. fs_bblock_link -> bblock_link fs_bblock -> bblock_t (to avoid conflicting with all the fs_bblock *bblock) fs_cfg -> cfg_t (to avoid conflicting with all the fs_cfg *cfg) Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2012-10-03 13:16:09 -07:00
bblock_link *successor_link =
(bblock_link *)successor_node;
bblock_t *successor_block = successor_link->block;
i965: Add basic block generator. This takes the fs_inst list generated by the visitor, and generates a list of basic blocks with edges between them. This is a building block for data-flow analysis.
2012-04-10 12:01:50 -07:00
printf(" ->B%d", successor_block->block_num);
}
printf("\n");
}
}
i965/fs: Split the BRW native code emit to brw_fs_emit.cpp This is all separate from the visitor and the optimization passes which feed into it. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2011-05-24 16:34:27 -07:00
}
i965: Move program dump to a helper function in brw_eu.c. It's going to get more complicated when we do instruction compaction. This also introduces putting the program offset in the output. v2: Use next_insn_offset in brw_get_program(), too. Reviewed-by: Paul Berry <stereotype441@gmail.com>
2012-02-03 11:50:42 +01:00
last_native_insn_offset = p->next_insn_offset;
i965/fs: Split the BRW native code emit to brw_fs_emit.cpp This is all separate from the visitor and the optimization passes which feed into it. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2011-05-24 16:34:27 -07:00
}
if (unlikely(INTEL_DEBUG & DEBUG_WM)) {
printf("\n");
}
brw_set_uip_jip(p);
/* OK, while the INTEL_DEBUG=wm above is very nice for debugging FS
* emit issues, it doesn't get the jump distances into the output,
* which is often something we want to debug. So this is here in
* case you're doing that.
*/
if (0) {
i965: Move program dump to a helper function in brw_eu.c. It's going to get more complicated when we do instruction compaction. This also introduces putting the program offset in the output. v2: Use next_insn_offset in brw_get_program(), too. Reviewed-by: Paul Berry <stereotype441@gmail.com>
2012-02-03 11:50:42 +01:00
brw_dump_compile(p, stdout, 0, p->next_insn_offset);
i965/fs: Split the BRW native code emit to brw_fs_emit.cpp This is all separate from the visitor and the optimization passes which feed into it. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2011-05-24 16:34:27 -07:00
}
}
i965/fs: Split final assembly code generation out of fs_visitor. Compiling shaders requires several main steps: 1. Generating FS 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 "fs_generator." There are several reasons for doing so: 1. Future hardware has a different instruction encoding. Splitting this out will allow us to replace fs_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 fs_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 fs_visitor and create IR, while ADD() in fs_generator() can create brw_instructions. (Patches for this upcoming.) Furthermore, this patch changes the order of operations slightly. Rather than doing steps 1-4 for SIMD8, then 1-4 for SIMD16, we now: - Do steps 1-3 for SIMD8, then repeat 1-3 for SIMD16 - Generate final assembly code for both modes together This is because the frontend work can be done independently, but final assembly generation needs to pack both into a single program store to feed the GPU. Reviewed-by: Eric Anholt <eric@anholt.net> Reviewed-by: Paul Berry <stereotype441@gmail.com>
2012-11-09 01:05:47 -08:00
const unsigned *
fs_generator::generate_assembly(exec_list *simd8_instructions,
exec_list *simd16_instructions,
unsigned *assembly_size)
{
dispatch_width = 8;
generate_code(simd8_instructions);
if (simd16_instructions) {
/* We have to do a compaction pass now, or the one at the end of
* execution will squash down where our prog_offset start needs
* to be.
*/
brw_compact_instructions(p);
/* align to 64 byte boundary. */
while ((p->nr_insn * sizeof(struct brw_instruction)) % 64) {
brw_NOP(p);
}
/* Save off the start of this 16-wide program */
c->prog_data.prog_offset_16 = p->nr_insn * sizeof(struct brw_instruction);
brw_set_compression_control(p, BRW_COMPRESSION_COMPRESSED);
dispatch_width = 16;
generate_code(simd16_instructions);
}
return brw_get_program(p, assembly_size);
}
Reference in a new issue Copy permalink