mesa: Init Geom.UsesEndPrimitive in shader programs.

Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
mesa: Copy Geom.UsesEndPrimitive when cloning a geometry program.

Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Cc: "10.1 10.2" <mesa-stable@lists.freedesktop.org>
r600g/compute: Add an intermediate resource for OpenCL buffers

This patch changes completely the way buffers are added to the
compute_memory_pool. Before this, whenever we were going to
map a buffer or write to or read from it, it would get placed
into the pool. Now, every unallocated buffer has its own
r600_resource until it is allocated in the pool.

NOTE: This patch also increase the GPU memory usage at the moment
of putting every buffer in it's place. More or less, the memory
usage is ~2x(sum of every buffer size)

v2: Cleanup

v3: Use temporary variables to avoid so many castings in functions,
    as suggested by Tom Stellard

Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
r600g/compute: Add an util function to know if an item is in the pool

Every item that has been placed in the pool must have start_in_dw
different from -1.

Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
r600g/compute: Add statuses to the compute_memory_items

These statuses will help track whether the items are mapped
or if they should be promoted to or demoted from the pool

v2: Use the new is_item_in_pool util function,
    as suggested by Tom Stellard

Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
r600g/compute: divide the item list in two

Now we will have a list with the items that are in the pool
(item_list) and the items that are outside it (unallocated_list)

Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
r600g/compute: Only move to the pool the buffers marked for promoting

Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
r600g/compute: Avoid problems when promoting items mapped for reading

Acording to the OpenCL spec, it is possible to have a buffer mapped
for reading and at read from it using commands or buffers.

With this we can keep the mapping (that exists against the
temporary item) and read with a kernel (from the item we have
just added to the pool) without problems.

Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
r600g/compute: Implement compute_memory_demote_item

This function will be used when we want to map an item
that it's already in the pool.

v2: Use temporary variables to avoid so many castings in functions,
    as suggested by Tom Stellard

Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
r600g/compute: Map only against intermediate buffers

With this we can assure that mapped buffers will never change
its position when relocating the pool.

This patch should finally solve the mapping bug.

v2: Use the new is_item_in_pool util function,
    as suggested by Tom Stellard

Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
r600g/compute: Use gallium util functions for double lists

Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
glx: Don't crash on swap event for a Window (non-GLXWindow)

Prior to GLX 1.3 there was the glxMakeCurrent() function that took a
single drawable handle. The Drawable could be either a bare XID for a
Window or an XID for a glxpixmap.

GLX 1.3 added glxMakeContextCurrent that takes 2 handles: one for
reading, one for writing. Nowadays the old glxMakeCurrent call is
implemented as a call to glxMakeContextCurrent with the single handle
duplicated.

Because of this it is allowed to use a plain-old Window ID as an
argument to glxMakeContextCurrent, although nobody really documents this
sort of thing. The manpage for the NEW call specifies the arguments as
GLXPixmaps, but the actual code accepts Window XIDs too, and handles
them correctly.

Similarly, the glxSelectEvents function can also take a bare Window XID.

The "piglit" tests all use GLXWindows and/or GLXPixmaps. You never
tested swap events with a bare Window XID. That is what my app was
doing.

The swap_events code worked with Window XIDs in mesa 7.x.y. The new code
added in versions 8, 9, and 10 assumes that all buffer swap events have
a GLXPixmap associated with them. Because of the historical quirks
above, this is not true. Swap events for bare Window XIDs do NOT have a
glxpixmap resulting in a segfault.

Any app that uses the old school glxMakeCurrent call with a Window XID
while trying to use swap_events will crash when the libs try to lookup
the nonexistent GLXPixmap associated with the incoming swap event.

I believe that the people who wrote the spec overlooked this, because
the "sbc" field comes from the OML_sync extension that is defined in
terms of glxpixmaps only.

v2 (idr): Formatting changes.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=54372
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Cc: "10.1 10.2" <mesa-stable@lists.freedesktop.org>
gallivm: Fix build after LLVM commit 211259

Signed-off-by: Aaron Watry <awatry@gmail.com>
Reviewed-by: Tom Stellard <thomas.stellard@amd.com>