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

mesa: added _mesa_dump_texture()

intel: flush old context before binding new context

Per the GLX spec, when changing rendering contexts, the old context
should first be flushed.

glx: don't destroy context immediately if it's currently bound

According to the GLXDestroyContext() man page, the context should not
immediately be destroyed if it's bound to some thread.  Wait until it's
unbound to really delete it.  The code for doing the later part is
already present in MakeContextCurrent() so no change was needed there.

mesa: code refactoring- new _mesa_finish(), _mesa_flush()

st/xorg: fix the makefile when used with new xextproto

progs/xdemos: fix command line flag typo

i965: fix hacked Fallback usage in brw_prepare_vertices()

Setting intel->Fallback = 1 clobbered any fallback state that was already
set.  Not sure where this hack originated (the git history is a little
convoluted).  Define and use a new BRW_FALLBACK_DRAW bit instead.  This
shouldn't break anything and could potentially fix some bugs (but no
specific ones are known).

intel: define INTEL_FALLBACK_DRIVER for drivers

intel: Fallback field is a bitmask, use GLbitfield

i965: remove unused brw_context::tmp_fallback field

i965: remove unused BRW_FALLBACK_TEXTURE bit

The value was probably wrong too.
It was the same as INTEL_FALLBACK_DRAW_BUFFER.

r300g: Enable more stuff in r300_screen, cleanup comments.

Also enable 24-bit depth buffers without stencil.

r300g: Cleanup PSC setup math a bit and stop using Draw formats.

nv50: handle PIPE_TEX_FILTER_ANISO case

Set the same bits as for linear filtering (in addition
to max anisotropy), and 2 unknown bits I've seen set.

nouveau: nv30: rewrite so we can render only in depth buffer

nouveau: nv30: use a8r8g8b8 as depth texture format for z24s8

Kill off trident.

Hm. I could have said "chew trident and spit it out," or perhaps
"spear trident," instead. Dohoho.

Nuke s3v.

As per FDO #17889.

r300g: Clean up duplicate code in r300_render.

r300g: Move render functions to r300_render.

Part of the fastpath cleanup.

scons: Hack LLVM support on Windows.

Doesn't quite work yet though, as small differences in the compilation flags
used when building LLVM and Mesa cause link failures for STL symbols.

llvmpipe: Avoid yet another variable size array.

llvmpipe: Define rdtsc for MSVC.

llvmpipe: Avoid variable size arrays.

Not really variable size, but MSVC still doesn't like them.