i965/fs: Remove force_sechalf stack

Only Gen4 color write setup uses the force_sechalf flag, and it only
sets it on a single instruction.  It also already has to get a pointer
to the instruction and manually set the saturate flag, so we may as well
just set force_sechalf the same way and avoid the complexity of a stack.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
i965: Move enum brw_urb_write_flags from brw_eu.h to brw_defines.h.

Broadwell code should not include brw_eu.h (since it is for Gen4-7
assembly encoding), but needs the URB write flags enum.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
i965: Move ud_reg_to_w() from brw_fs_generator.cpp to brw_reg.h.

This makes it available from other files, which will be useful for
Broadwell.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
i965: Make swizzle_to_scs non-static.

We'll need this for Broadwell code as well.

Normally, when we make things public, we add the "brw" prefix.  I'm not
crazy about that in this case, since it deals with prog_instruction.h's
SWIZZLE_XYZW values, rather than the BRW_SWIZZLE_XYZW enums.  However,
I can't think of a better name, and at least the comments and code make
it clear.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
i965: Add device info structs for Broadwell.

As always, the chipset limits here are placeholders, rather than the
actual values.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
i965: Claim OpenGL 3.3 support on Broadwell.

Bugs aside, basically everything ought to work.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
i965: Disable HiZ on Broadwell for now.

HiZ is difficult to implement, and while it's essential for performance,
we don't need it right away for purposes of hardware enabling.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
i965: Disable BLORP on Broadwell for now.

BLORP is essential.  However, porting it to Gen8 is a huge amount of
work.  Disabling it for now allows us to proceed with basic hardware
enablement.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
i965: Reserve space for "Vertex Count" in GS outputs.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
i965: Add a new representation for Broadwell shader instructions.

Broadwell significantly changes the EU instruction encoding.  Many of
the fields got moved to different bit positions; some even got split
in two.

With so many changes, it was infeasible to continue using struct
brw_instruction.  We needed a new representation.

This new approach is a bit different: rather than a struct, I created a
class that has four DWords, and helper functions that read/write various
bits.  This has several advantages:

1. We can create several different names for the same bits.  For
   example, conditional modifiers, SFID for SEND instructions, and the
   MATH instruction's function opcode are all stored in bits 27:24.

   In each situation, we can use the appropriate setter function:
   set_sfid(), set_math_function(), or set_cond_modifier().  This
   is much easier to follow.

2. Since the fields are expressed using the original 128-bit numbers,
   the code to create the getter/setter functions follows the table in
   the documentation very closely.

To aid in debugging, I've enabled -fkeep-inline-functions when building
gen8_instruction.cpp.  Otherwise, these functions cannot be called by
gdb, making it insanely difficult to print out anything.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
i965: Implement a disassembler for Broadwell's new instruction encoding

Heavily based on Keith Packard's existing brw_disasm.c code.  I've tried
to go through most of the pieces (like SFIDs) and update the lists to
include features added in recent generations.

I had to use C++ since my new instruction representation requires it.
Unfortunately, C++98 doesn't allow the use of C99 array initializers,
which makes the arrays mapping values to strings harder to read.  I
tried to compensate for this failing by adding additional comments.

The disassembly can definitely be improved, but this should at least
get INTEL_DEBUG=vs/fs working.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
i965: Add a new infrastructure for generating Broadwell shader assembly.

This replaces the brw_eu_emit.c layer for Broadwell.  It will be
used by both the vector and scalar shader backends.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
i965: Create a new vec4 backend for Broadwell.

This replaces the old vec4_generator backend.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
i965: Create a new fragment shader backend for Broadwell.

This replaces the old fs_generator backend.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
i965/vs: Always store pull constant offsets in GRFs on Gen8.

We need to SEND from a GRF, and we can only obtain those prior to
register allocation.

This allows us to do pull constant loads without the MRF hack.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
i965/vs: Don't copy propagate into SEND-from-GRF messages.

SEND can't deal with swizzles, source modifiers, and so on.  This should
avoid problems with VS pull constant loads on Broadwell.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
i965: Duplicate gen7_atoms to gen8_atoms.

It's going to diverge significantly.  Starting out with a copy allows
future patches to change atoms one by one.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
i965: Use the Sandybridge VUE format on Broadwell as well.

It hasn't changed.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
i965: Bump generation assertions on workaround flushes.

These workaround flushes may not be necessary on Gen8.  Investigation is
needed.  Tentatively, let's do them out of caution.

v2: [chadv]
  - Comment that flush may not be needed.
  - Make assertion conditions symmetrical.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
i965: Introduce an OUT_RELOC64 macro.

Broadwell uses 48-bit addresses.  The first DWord is the low 32 bits,
and the second DWord is the high 16 bits.

Since individual buffers shouldn't be larger than 4GB in size, any
offsets into those buffers (buffer->offset + delta) should fit in the
low 32 bits.  So I believe we can simply emit 0 for the high 16-bits,
and drm_intel_bo_emit_reloc() should patch it up.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>