meta: Set correct viewport and projection in decompress_texture_image.

_mesa_meta_begin() sets up an orthographic project and initializes the
viewport based on the current drawbuffer's width and height.  This is
likely the window size, since it occurs before the meta operation binds
any temporary buffers.

decompress_texture_image needs the viewport to be the size of the image
it's trying to draw.  Otherwise, it may only draw part of the image.

v2: Actually set the projection properly too.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=68250
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Cc: Mak Nazecic-Andrlon <owlberteinstein@gmail.com>
mesa: Specify a better GL_MAX_SERVER_WAIT_TIMEOUT limit.

The previous value of (GLuint64) ~0 has some problems:

GL_MAX_SERVER_WAIT_TIMEOUT is supposed to be a GLuint64 value, but has
to be queried via GetInteger64v(), which returns a GLint64.  This means
that some applications are likely to treat it as a signed integer, where
~0 means -1.  Negative values are nonsensical and problematic.

When interpreted correctly, ~0 translates to about 0.58 million years,
which seems rather excessive.

This patch changes it to 0x1fff7fffffff, which is about 1.11 years.
This is still plenty long, and is the same as both an int64 and uint64.
Applications that accidentally store it in a 32-bit int/unsigned also
get a non-negative value, which is again the same as both int and
unsigned.  This value was suggested by Ian Romanick.

v2: Add the ULL prefix on the constant (suggested by Ian).

Fixes Piglit's spec/!OpenGL 3.2/get-integer-64v.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Cc: mesa-stable@lists.freedesktop.org
mesa: Fix assertion error with glDebugMessageControl

enums were being converted twice resulting in incorrect values.
The extra conversion has been removed and the redundant assert is
removed also.

Cc: 9.2 <mesa-stable@lists.freedesktop.org>

Signed-off-by: Timothy Arceri <t_arceri@yahoo.com.au>
Reviewed-by: Brian Paul <brianp@vmware.com>
glsl: Refactor handling of gl_ClipDistance/gl_ClipVertex linkage rules for GS.

This patch extracts the following logic from
validate_vertex_shader_executable():

(a) Generate an error if the shader writes to both gl_ClipDistance and
    gl_ClipVertex.

(b) Record whether the shader writes to gl_ClipDistance in
    gl_shader_program for use by the back-end.

(c) Record the size of gl_ClipDistance in gl_shader_program for use by
    transform feedback logic.

And moves it into a function that is shared between vertex and
geometry shaders.

Strictly speaking we only need to have shared logic for (b) and (c)
right now (since (a) only matters in compatibility contexts, and we're
only implementing geometry shaders in core contexts right now).  But
the three are closely related enough that it seems sensible to keep
them together.

Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
mesa/program: Make prog_instruction.h and program.h safe to include from C++.

Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
i965: Make brw_{program,vs}.h safe to include from C++.

Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
i965: Initialize all elements of ctx->ShaderCompilerOptions.

Otherwise any GS that requires lowering (e.g. one that uses
gl_ClipDistance as an input or output) will fail to work.

Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
i965: Stop including brw_vs.h from brw_vec4.h.

This is backwards from what we are going to want in the long term, which is:

- brw_vec4.h declares general-purpose vec4 infrastructure needed by
  both VS and GS
- brw_vs.h includes brw_vec4.h and adds VS-specific parts.
- brw_gs.h includes brw_vec4.h and adds GS-specific parts.

Note that at the moment brw_vec.h contains a fair amount of
VS-specific declarations--I plan to address that in a later patch.

Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
i965: Make brw_{shader,vec4}.h safe to include from C.

The patch that follows will move the definition of struct
brw_vec4_prog_key from brw_vs.h to brw_vec4.h, making it necessary for
brw_vs.h to include brw_vec4.h (because brw_vs.h defines struct
brw_vs_prog_key, which contains brw_vec4_prog_key as a member).  Since
brw_vs.h is included from C source files, that means that brw_vec4.h
will need to be safe to include from C.  Same for brw_shader.h, since
it is included by brw_vec4.h.

Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
i965/vec4: Move vec4 data structures and functions to brw_vec4.{cpp,h}.

This patch moves the following things into brw_vec4.{cpp,h}:

- struct brw_vec4_compile
- struct brw_vec4_prog_key
- brw_vec4_prog_data_compare()
- brw_vec4_prog_data_free()

This will allow us to avoid having to include brw_vs.h in
geometry-shader-specific files.

Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
i965/vec4: Allow for dispatch_grf_start_reg to vary.

Both 3DSTATE_VS and 3DSTATE_GS have a dispatch_grf_start_reg control,
which determines the register where the hardware delivers data sourced
from the URB (push constants followed by per-vertex input data).

For vertex shaders, we always set dispatch_grf_start_reg to 1, since
R1 is always the first register available for push constants in vertex
shaders.

For geometry shaders, we'll need the flexibility to set
dispatch_grf_start_reg to different values depending on the behvaiour
of the geometry shader; if it accesses gl_PrimitiveIDIn, we'll need to
set it to 2 to allow the primitive ID to be delivered to the thread in
R1.

This patch eliminates the assumption that dispatch_grf_start_reg is
always 1.  In vec4_visitor, we record the regnum that was passed to
vec4_visitor::setup_uniforms() in prog_data for later use.  In
vec4_generator, we consult this value when converting an abstract
UNIFORM register to a concrete hardware register.  And in the code
that emits 3DSTATE_VS, we set dispatch_grf_start_reg based on the
value recorded in prog_data.

This will allow us to set dispatch_grf_start_reg to the appropriate
value when compiling geometry shaders.  Vertex shaders will continue
to always use a dispatch_grf_start_reg of 1.

v2: Make dispatch_grf_start_reg "unsigned" rather than "GLuint".

Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
i965/vec4: Virtualize setup_payload instead of setup_attributes.

When I initially generalized the vec4_visitor class in preparation for
geometry shaders, I assumed that the setup_attributes() function would
need to be different between vertex and geometry shaders, but its
caller, setup_payload(), could be shared.  So I made
setup_attributes() a virtual function.

It turns out this isn't true; setup_payload() needs to be different
too, since the geometry shader payload sometimes includes an extra
register (primitive ID) that has to come before uniforms.

So setup_payload() needs to be the virtual function instead of
setup_attributes().

Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
i965/gs: Add brw->geometry_program.

Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
i965/gs: Add a case to brwBindProgram() for geometry shaders.

Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
i965/gs: Create structs for use by GS program compilation.

v2: Make id "unsigned" rather than "GLuint".

Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
i965/gs: Add a case to brwNewProgram() for geometry shaders.

Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
i965: Combine 4 boolean args of brw_urb_WRITE into a flags bitfield.

The arguments to brw_urb_WRITE() were getting pretty unwieldy, and we
have to add more flags to support geometry shaders anyhow.

Also plumb these flags through brw_clip_emit_vue(),
brw_set_urb_message(), and the vec4_instruction class.

Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
i965/gs: Add a flag allowing URB write messages to use a per-slot offset.

This will be used by geometry shaders to implement the EmitVertex()
function, since it requires writing data to a dynamically-determined
offset within the geometry shader's URB entry.

Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
i965/gs: Add GS_OPCODE_URB_WRITE.

Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
i965/gs: Add GS_OPCODE_THREAD_END.

Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>