This should improve our ability to register allocate without spilling.
Unfortuantely, due to the live variable analysis being ignorant of loops, we
still have register allocation failures on some programs.

v2: Add more context to the comment explaining the function.

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

Before, we'd spill one reg, then continue on without actually register
allocating, then assertion fail when we tried to use a vgrf number as a
register number.

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

To validate this code, I ran piglit -t vs quick.tests with the "go spill
everything" debugging code enabled.  There was only one regression:
glsl-vs-unroll-explosion simply ran out of registers.  This should be
fine in the real world, since no one actually spills every single
register.

NOTE: This is a candidate for the 9.0 branch. Even if it proves to have
bugs, it's likely better than simply failing to compile.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>

move_grf_array_access_to_scratch() calculates scratch buffer offsets in
bytes.  However, emit_scratch_read/write() expects the base_offset
parameter to be measured in OWords.

As a result, a shader using a scratch read/write offset greater than
zero (in practice, a shader containing more than one variable in
scratch) would use too large an offset, frequently exceeding the
available scratch space.

This patch corrects the mismatch by removing spurious conversion from
OWords to bytes in move_grf_array_access_to_scratch().

This is based on a patch by Paul Berry.

NOTE: This is a candidate for stable release branches.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>

Version 12 of the EGL_KHR_create_context spec changed this behavior.

NOTE: This is a candidate for the 9.0 branch
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>

Reviewed-by: Tom Stellard <thomas.stellard@amd.com>

Reviewed-by: Tom Stellard <thomas.stellard@amd.com>

Reviewed-by: Tom Stellard <thomas.stellard@amd.com>

Reviewed-by: Tom Stellard <thomas.stellard@amd.com>

Reviewed-by: Tom Stellard <thomas.stellard@amd.com>

Reviewed-by: Tom Stellard <thomas.stellard@amd.com>

This brings us into accordance with the official Python style guide
(http://www.python.org/dev/peps/pep-0008/#indentation).

To preserve the indentation of the c code that is generated by these
scripts, I've avoided re-indenting triple-quoted strings (unless those
strings appear to be docstrings).

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

Not supported by MSVC.

Reviewed-by: Imre Deak <imre.deak@intel.com>

Should fix MSVC build, as windows.h also defines CONST.

CONST usage in get.c is not new, so probably this just appeared now due
to changes in the includes.

This got broken by:
7182a1f glapi: rename/move GL_POLYGON_OFFSET_BIAS to its extension
section

Fix it by appending the _EXT suffix to the enum in the test too.

Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Oliver McFadden <oliver.mcfadden@linux.intel.com>

Since we generate the hash tables in build time, these flags aren't used
any more, remove them.

Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Oliver McFadden <oliver.mcfadden@linux.intel.com>

Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Oliver McFadden <oliver.mcfadden@linux.intel.com>

This will be needed by the next patch, which will switch to using
the parameter descriptor- and hash tables generated by the script.

The hash algorithm remains the same, the output parameter descriptor
table format changes slightly. There the TYPE_API_MASK entries are
removed and an invalid NULL entry is inserted at the beginning. This is
ok, as get.c:find_value() doesn't rely on TYPE_API_MASK any more to
detect an invalid enum.

Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Oliver McFadden <oliver.mcfadden@linux.intel.com>

Needed by the next patch.

Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Oliver McFadden <oliver.mcfadden@linux.intel.com>

The following enums used to be extensions but later became part of the
core specification. The _EXT/_ARB versions of these are not present in
in the current XML spec files, only defined in GL/glext.h

Later we'll need to look up these in a python script using the XML spec.
As a preparation for that remove the _EXT,_ARB suffix from these enums
and rename GL_DISTANCE_ATTENUATION_EXT to GL_POINT_DISTANCE_ATTENUATION.
Naturally, all enums keep their numerical values.

Note that similar renames shouldn't be necessary in the future: in case
of a new extension the XML spec is updated with the new _EXT/_ARB etc.
name and this name is added to the enum table in get.c.  Later the
extension may become part of the core spec, at which point the name w/o
the _EXT/_ARB suffix is added to the XML spec and the table in get.c
remains the same.

GL_BLEND_DST_ALPHA_EXT
GL_BLEND_DST_RGB_EXT
GL_BLEND_SRC_ALPHA_EXT
GL_BLEND_SRC_RGB_EXT
GL_COLOR_SUM_EXT
GL_COMPRESSED_TEXTURE_FORMATS_ARB
GL_CURRENT_FOG_COORDINATE_EXT
GL_CURRENT_SECONDARY_COLOR_EXT
GL_DISTANCE_ATTENUATION_EXT
GL_FOG_COORDINATE_ARRAY_EXT
GL_FOG_COORDINATE_ARRAY_STRIDE_EXT
GL_FOG_COORDINATE_ARRAY_TYPE_EXT
GL_FOG_COORDINATE_SOURCE_EXT
GL_FRAGMENT_SHADER_DERIVATIVE_HINT_ARB
GL_PACK_IMAGE_HEIGHT_EXT
GL_PACK_SKIP_IMAGES_EXT
GL_SECONDARY_COLOR_ARRAY_EXT
GL_SECONDARY_COLOR_ARRAY_SIZE_EXT
GL_SECONDARY_COLOR_ARRAY_STRIDE_EXT
GL_SECONDARY_COLOR_ARRAY_TYPE_EXT
GL_UNPACK_IMAGE_HEIGHT_EXT
GL_UNPACK_SKIP_IMAGES_EXT

Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Oliver McFadden <oliver.mcfadden@linux.intel.com>

When traversing the hash table looking up an enum that is invalid we
eventually reach the first element in the descriptor array. By looking
at the type of that element, which is always TYPE_API_MASK, we know that
we can stop the search and return error. Since this element is always
the first it's enough to check for its index being 0 without looking at
its type.

Later in this patchset, when we generate the hash tables during build
time, this will allow us to remove the TYPE_API_MASK and related flags
completly.

Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Oliver McFadden <oliver.mcfadden@linux.intel.com>

The glGet hash was initialized only once for a single GL API, even if
the application later created a context for a different API. This
resulted in glGet failing for otherwise valid parameters in a context
if that parameter was invalid in another context created earlier.

Fix this by using a separate hash table for each API.

Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Oliver McFadden <oliver.mcfadden@linux.intel.com>

This should be named GL_POLYGON_OFFSET_BIAS_EXT and listed under the
EXT_polygon_offset section. (Solution by Ian Romanick)

Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Oliver McFadden <oliver.mcfadden@linux.intel.com>

Reviewed-by: Jerome Glisse <jglisse@redhat.com>

Also update the register value in more appropriate places
than r600_update_derived_state.

Reviewed-by: Jerome Glisse <jglisse@redhat.com>

Reviewed-by: Jerome Glisse <jglisse@redhat.com>

Reviewed-by: Jerome Glisse <jglisse@redhat.com>

Reviewed-by: Jerome Glisse <jglisse@redhat.com>

Some variables have been removed from there too.

Reviewed-by: Jerome Glisse <jglisse@redhat.com>

Reviewed-by: Jerome Glisse <jglisse@redhat.com>

The workaround for R600 lacking VPORT_SCISSOR_ENABLE has also been simplified.

Reviewed-by: Jerome Glisse <jglisse@redhat.com>

POLY_OFFSET_DB_FMT_CNTL is moved to the framebuffer state, because it only
depends on the zbuffer format.

Reviewed-by: Jerome Glisse <jglisse@redhat.com>

The state object is actually a buffer, it's literally a buffer containing
the shader code.

Reviewed-by: Jerome Glisse <jglisse@redhat.com>

Reviewed-by: Jerome Glisse <jglisse@redhat.com>

This is not so trivial, because we disable blending if the dual src
blending is turned on and the number of color outputs is less than 2.
I decided to create 2 command buffers in the blend state object and just
switch between them when needed, because there are other states unrelated
to blending (like the color mask) and those shouldn't be changed
(the old code had it wrong).

Reviewed-by: Jerome Glisse <jglisse@redhat.com>

Reviewed-by: Jerome Glisse <jglisse@redhat.com>

r600_command_buffer is not an atom.

The "atoms" have evolved into state slots (or groups of state slots) where
you can bind states. There is a fixed amount of atoms (state slots)
in the context.

The command buffers are nothing like that. They represent states, not state
slots.

We could probably give r600_atom a better name someday.

Reviewed-by: Jerome Glisse <jglisse@redhat.com>

The invalidate event support is a careful dance between driver and loader,
where both have to say they can handle it, and then the loader reports
invalidate events for the driver so the driver can do the optimization.

The EGL code doesn't report __DRIuseInvalidateExtension to the driver, so it
has no responsibility to call the driver's invalidate function, and the driver
is doing the glViewport hack because it assume.  This is not
the only time invalidate would need to be called (we need it *any* time an
invalidate event comes down the pipe, but we don't watch for them), so just
stop calling the driver's function.

Acked-by: Chad Versace <chad.versace@linux.intel.com>

This behavior mostly matches glx_dri2.  It's slightly complicated in
comparison because EGL exposes the implementation limits in the EGL config.

Note that platform_x11 was the only one setting swap_available, so the move of
the MaxSwapInterval into it is appropriate.

Acked-by: Chad Versace <chad.versace@linux.intel.com>

Reviewed-by: Chad Versace <chad.versace@linux.intel.com>

Reviewed-by: Chad Versace <chad.versace@linux.intel.com>

Reviewed-by: Chad Versace <chad.versace@linux.intel.com>

There's no reason to say no in this case.

Reviewed-by: Chad Versace <chad.versace@linux.intel.com>

Reviewed-by: Chad Versace <chad.versace@linux.intel.com>

Reviewed-by: Chad Versace <chad.versace@linux.intel.com>

It's been in place but never enabled since 2010.  Note how one piece called a
DRI2 function, suggesting never being tested.

Reviewed-by: Chad Versace <chad.versace@linux.intel.com>

Reviewed-by: Chad Versace <chad.versace@linux.intel.com>