i965g: propogate map-buffer-range semantics down to winsys

i965g: make the winsys responsible for all buffer->offset handling

The winsys now inserts the presumed offset into referring buffers from
inside of bo_emit_reloc().  Remove the many locally coded places where
this was happening in the driver and eliminate the worry of getting it
wrong.

No longer need to expose offset values to the driver at all, so no need
to worry about what to do in the driver when they change.  Just use
zero values wherever we had offsets previously -- the relocations will
fix it all up for us.

i965g: remove duplicate viewport state in brw_context

i965g: correct sense of writedisable flags

brw: push more dumping into the winsys

i965g: correct size of surf_bo array

i965g: use Elements in loops over arrays

i965g: add const qualifiers

i965g: disassemble more than one instruction at a time

i965g: remove old dumping code

i965g: call dissassembler for appropriate data uploads

i965g: add lots of error checks and early returns

Any allocation that may fail should be checked, and propogate the
error upwards.  At the highest level we will flush batch and retry.

This is an alternate strategy to what the original DRI driver did of
attempting to flush batch from the lowest levels (eg inside
BEGIN_BATCH).  The trouble with that strategy was that flushes could
occur at unexpected times, and additionally there was a need for a
wierd notification mechanism to propogate the 'lost context' state
back up to higher levels.

Propogating the errors directly gives us a lot of flexibility how to
deal with these states, at the expense of a lot more checking in the
code.

Will add some sanity checks later to make sure that out-of-memory
conditions are properly escalated and not lost halfway up the stack.

i965g: Don't dump pads or dwords aliases.

i965g: hook up dumpers in dumping winsys

i965g: Dumper for i965 structures.

i965g: add data type tags to aid dumping/decoding

i965g: use pipe_error return value for brw_batchbuffer_require_space

trivial/tri runs without crashing (on debug winsys) but still produces
obviously incorrect command buffers.

i965g: fix compiler warning

i965g: Builds with scons

But there are some missing symbols, "nm -u i965_dri.so"
[SNIP]
                 U brw_surface_bo
                 U brw_surface_pitch
                 U brw_texture_blanket_winsys_buffer
                 U brw_texture_get_winsys_buffer
                 U brw_update_dirty_counts
[SNIP]

i965g: Fix debug check

i965g: Build with configure

i965g: Do not create a symlink for i965_dri.so

i915g: Do not create a symlink for i965_dri.so

i965g: enable line stipple packet emit

With this change, trivial/tri manages to build and emit
a fairly unconvincing command buffer (to the debug winsys),
and then crashes.

i965g: fix order of calculation of brw->wm.nr_surfaces

i965g: consolidate some includes

i965g: fix some asserts

i965g: remove redundant screen pointer in brw context struct

i965g: initialize winsys pointer in surface cache

i965g: init pointer to null, avoid segfault

i965g: clean up wm init_registers func

i965g: hook up some missing vertex shader code

i965g: hook up some vertex state funcs

ws/i965: allow NULL buffer in winsys::bo_unreference

Special case to avoid clutter in the driver

i965g: pull in a copy of intel_decode.c for now

With the stubbed out, non-hardware xlib winsys, trivial/clear runs and
prints a plausible command stream

i965g: hook up flush-frontbuffer

i965g: fix up batchbuffer confusion

i965g: plumb in some surface state

i965g: hook up pipe_clear functions

i965g: add constant buffer setter

i965g: add missing is_*_referenced callbacks

i965g: initialize surface refcount

i965g: add more missing pipe callbacks

i965g: add some missing texture creation code

i965g: stubs for brw_pipe_vertex.c

i965g: hook up pipe sampler callbacks

i965g: hook up more pipe_context functions

i965g: add missing buffer functions

ws/i965: add load-time driver registration

Otherwise xlib state-tracker doesn't know about us.

ws/i965: add butt-ugly linker hack

Need more linker magic to keep the glX symbols externally visible even
though they started off in a .a file.

i965g: hook up brw_screen.c

i965g: add standalone xlib debug winsys

Create a dummy winsys that just debug-prints on calls into the winsys
functions.  Will use this to get to the point where we are generating
sane-looking debug dumps and diassembly.

Also fix various warnings generated with the new compiler flags set in
this config.

i965g: convert read/write domain pairs into single usage value

Easier to understand what's going on in the driver sources, convert
stereotype usage values back to GEM read/write domain flags in the
winsys.

i965g: format RELOCs similarly

i965g: rename brw_constant_buffer to brw_curbe_buffer

Now that there are real constant buffers, try to reduce naming confusion.

i965g: driver and winsys compile

A milestone of sorts.  Still a long way from something working --
the old one compiled too, at least some of the time...

i965g: the whole drivers/i965 directory is compiling

That was a lot more work than I expected.  Still the winsys to go,
then the small matter of making it work and re-enabling the
missing functionality.

i965g: more files compiling

i965g: more files compiling

i965g: more files compiling

i965g: more files compiling

i965g: more work on compilation -- surface management

i965g: more work on compilation

i965g: non-glsl fragment shader path is compiling

Disabled glsl code for now, probably want to clean this up somehow.

i965g: wip on fragment shaders

i965g: work in progress on fragment shaders

i965g: still working on compilation

i965g: still working on compilation

i965g: still working on compilation

i965g: still working on compilation

i965g: start hooking up some to the gallium context interfaces

- create/bind/destroy blend and depth state
- framebuffer and viewport
- etc.

i965g: more compiling wip

i965g: more work on compiling, particularly the brw_draw files

i965g: more work on compiling

i965g: more files compiling

i965g: hook into build system

ws/i965: renames from i915, hook up makefiles

i965g: first compiling file

ws/i965: pull in the rest of the i915 winsys tree.

The intel_xorg file looks like it's got quite a bit of code that could
be lifted up into the xorg state tracker -- should really just have a
list of pci ids and a pointer to a screen create func.

ws/i965: clone the i915 winsys

I'll want to rework this, not sure trying to share this code is a very
good idea at least until the interfaces from the two drivers calm
down.

i965g: wip on removing GL stuff, trying to get a few files compiling

i965: ignore cliprect_mode

i965g: wip

i965g: re-starting from the dri driver

gallium: remove extended negate also, and also the ExtSwz token

Likewise, the extended negate functionality hasn't been
used since mesa switched to using tgsi_ureg to build programs,
and has been translating the SWZ opcode internally to a single MAD.

cell: typo from ExtSwizzle commit

gallium: remove the swizzling parts of ExtSwizzle

These haven't been used by the mesa state tracker since the
conversion to tgsi_ureg, and it seems that none of the
other state trackers are using it either.

This helps simplify one of the biggest suprises when starting off with
TGSI shaders.

gallium: remove noise opcodes

Provide a dummy implementation in the GL state tracker (move 0.5 to
the destination regs).

At some point, a motivated person could add a better
implementation of noise.  Currently not even the nvidia
binary drivers do anything more than this.  In any case, the
place to do this is in the GL state tracker, not the poor
driver.

progs/demos: add fps to multiarb

r300g: last changes's typo, miss a include file

r300g: add flush_frontbuffer function to display video surface

g3dvl: pass display and screen to g3dvl when creating video private context

r600: remove remains of old tnl pipeline

r600: fix render size prediction

r600: remove old tnl pipeline

r600: clean up context creation

Make it more consistent with other radeon drivers.

Revert "Store clipping distance for user clip planes as part of vertex processing"

This reverts commit f058b25881e08c9d89a33345e5c84e1357396932.

This change is completely wrong in so many ways.  When clip distances
are generated as part of vertex processing, they must be interpolated
to perform clipping.  Geometric clipping goes right out the window.

Merge branch 'mesa_7_6_branch'

docs: document 'useprog' debug option

mesa: fix up vbo comments