i965g: tgsi outputs cannot be used as source regs

i965g: use curr.vertex_element state directly

trivial: add vbo-tri, an even simpler version of tri.c

i965g: don't emit line stipple packet if stipple disabled

i965g: populate brw_context chipset id

i965g: make sure blend color packet header is initialized

We will emit this packet at startup (dirty == ~0), even if we haven't
had the state tracker call into brw_set_blend_color() yet.

This way is a little more efficient also.

i965g: remove/disable inactive state atoms

i965g: populate wm reloc array earlier

Still have to calculate the reloc background in two places.

i965g: point_rast_rule comment no longer applies

Not sure exactly what state we want here now, will need to experiment.

i965g: scissor off by one

i965g: restore code to populate the relocation background

I'm emitting this in two places now, to the data presented
for upload and also in the delta field of the reloc struct.
Probably want to remove the delta field and just pull the
background from the key.

i965g: clean up winsys dumping code a little

i965g: pass relocation information in an array with bo_subdata

Makes it easier to dump as we get all of the information
about the upload in a single hit.

Opens the window to simplification in the driver if these
relocation arrays can be maintained statically rather than
being recreated whenever we check for a new upload.

Still needs some cleanup to avoid uglyness introduced with the
delta values.

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.