radeonsi: simplify constant buffer upload for big endian

Point util_memcpy_cpu_to_le32 to a buffer storage directly.

v2: simplify more

Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
gallium/radeon: Set gpu_address to 0 if r600_virtual_address is false

Without this patch I get the following during DMA transfers:
[drm:radeon_cs_ib_chunk] *ERROR* Invalid command stream !
radeon 0000:01:00.0: CP DMA dst buffer too small (21475829792 4096)

This is a fixup for e878e154cdfd4dbb5474f776e0a6d86fcb983098.

Signed-off-by: Niels Ole Salscheider <niels_ole@salscheider-online.de>
Signed-off-by: Marek Olšák <marek.olsak@amd.com>
i965/fs: Fix bad whitespace.
i965/fs: don't read from uninitialized memory while assigning registers

Reviewed-by: Matt Turner <mattst88@gmail.com>
Signed-off-by: Connor Abbott <connor.abbott@intel.com>
i965/fs: set virtual_grf_count in assign_regs()

This lets us call dump_instructions() after register allocation without
failing an assertion.

Reviewed-by: Matt Turner <mattst88@gmail.com>
Signed-off-by: Connor Abbott <connor.abbott@intel.com>
i965: Support the allow_glsl_extension_directive_midshader option.

This adds support for Marek's new driconf parameter, which avoids
totally white rendering in Unigine Valley (which attempts to enable
the GL_ARB_sample_shading extension in an illegal place).

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=75664
Reviewed-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
i965/guardband: Improve comments for guardband clipping

While working in this part of the code I had a great deal of trouble
understanding what it was trying to do, and matching it with the spec.
(mostly due bad wording in the PRM). To help future people, I've cleaned
up the wording and provided some ascii art.

Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Chris Forbes <chrisf@ijw.co.nz>
i965: Simplify viewport extents programming on GEN8

Viewport extents are a 3rd rectangle that defines which pixels get
discarded as part of the rasterization process. The actual pixels drawn
to the screen are an intersection of the drawing rectangle, the viewport
extents, and the scissor rectangle. It permits the use of guardband
clipping in all cases (see later patch). The actual pixels drawn to the
screen are an intersection of the drawing rectangle, the viewport
extents, and the scissor rectangle.

Scissor rectangle is not super important for this discussion as it should
always help do the right thing provided the programmer uses it.

switch (viewport dimensions, drawrect dimension) {
   case viewport > drawing rectangle: no effects; break;
   case viewport == drawing rectangle: no effects; break;
   case viewport < drawing rectangle:
      Pixels (after the viewport transformation but before expensive
      rastersizing and shading operations) which are outside of the
      viewport are discarded.
}

I am unable to find a test case where this improves performance, but in
all my testing it doesn't hurt performance, and intuitively, it should
not ever hurt performance. It also permits us to use the guardband more
freely (see upcoming patch).

v2: Updating commit message.

v3: Commit message updates requested by Ken

Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
i965/guardband: Enable for all viewport dimensions (GEN8+)

The goal of guardband clipping is to try to avoid 3d clipping because it
is an expensive operation. When guardband clipping is disabled, all
geometry that intersects the viewport is sent to the FF 3d clipper.
Objects which are entirely enclosed within the viewport are said to be
"trivially accepted" while those entirely outside of the viewport are,
"trivially rejected".

When guardband clipping is turned on the above behavior is changed such
that if the geometry is within the guardband, and intersects the
viewport, it skips the 3d clipper. Prior to GEN8, this was problematic
if the viewport was smaller than the screen as it could allow for
rendering to occur outside of the viewport. That could be mitigated if
the programmer specified a scissor region which was less than or equal
to the viewport - but this is not required for correctness in OpenGL. In
theory you could be clever with the guardband so as not to invoke this
problem. We do not do this, and have no data that suggests we should
bother (nor the converse data).

With viewport extents in place on GEN8, it should be safe to turn on
guardband clipping for all cases

While here, add a comment to the code which confused me thoroughly.

v2: Update grammar in commit message. Reword comments based on Ken's
suggestion.

Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
i965/clip: Removing scissor atom

Now that we no longer use ctx->DrawBuffer->_Xmin and related fields to
program the screen-space viewport extents, we don't depend on any
scissoring state.  So we can drop the +_NEW_SCISSOR dependency.

On GEN8, a change in scissor state does not effect anything for the
clipper/sf hardware state. The hardware will always do the right thing
once the viewport extents are programmed. We can therefore remove the
unecessary state emission.

Ken originally spotted this.

v2: Reword the commit message. Remove spurious hunk.

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