d3d1x: add new Direct3D 10/11 COM state tracker for Gallium

This is a new implementation of the Direct3D 11 COM API for Gallium.

Direct3D 10 and 10.1 implementations are also provided, which are
automatically generated with s/D3D11/D3D10/g plus a bunch of #ifs.

While this is an initial version, most of the code is there (limited
to what Gallium can express), and tri, gears and texturing demos
are working.

The primary goal is to realize Gallium's promise of multiple API
support, and provide an API that can be easily implemented with just
a very thin wrapper over Gallium, instead of the enormous amount of
complex code needed for OpenGL.

The secondary goal is to run Windows Direct3D 10/11 games on Linux
using Wine.
Wine dlls are currently not provided, but adding them should be
quite easy.

Fglrx and nvidia drivers can also be supported by writing a Gallium
driver that talks to them using OpenGL, which is a relatively easy
task.
Thanks to the great design of Direct3D 10/11 and closeness to Gallium,
this approach should not result in detectable overhead, and is the
most maintainable way to do it, providing a path to switch to the
open Gallium drivers once they are on par with the proprietary ones.

Currently Wine has a very limited Direct3D 10 implementation, and
completely lacks a Direct3D 11 implementation.

Note that Direct3D 10/11 are completely different from Direct3D 9
and earlier, and thus warrant a fully separate implementation.

The third goal is to provide a superior alternative to OpenGL for
graphics programming on non-Windows systems, particularly Linux
and other free and open systems.

Thanks to a very clean and well-though design done from scratch,
the Direct3D 10/11 APIs are vastly better than OpenGL and can be
supported with orders of magnitude less code and development time,
as you can see by comparing the lines of code of this commit and
those in the existing Mesa OpenGL implementation.

This would have been true for the Longs Peak proposal as well, but
unfortunately it was abandoned by Khronos, leaving the OpenGL
ecosystem without a graphics API with a modern design.

A binding of Direct3D 10/11 to EGL would solve this issue in the
most economical way possible, and this would be great to provide
in Mesa, since DXGI, the API used to bind Direct3D 10/11 to Windows,
is a bit suboptimal, especially on non-Windows platforms.

Finally, a mature Direct3D 10/11 implementation is intrinsically going
to be faster and more reliable than an OpenGL implementation, thanks
to the dramatically smaller API and the segregation of all nontrivial
work to object creation that the application must perform ahead of
time.

Currently, this commit contains:
- Independently created headers for Direct3D 10, 10.1, 11 and DXGI 1.1,
  partially based on the existing Wine headers for D3D10 and DXGI 1.0
- A parser for Direct3D 10/11 DXBC and TokenizedProgramFormat (TPF)
- A shader translator from TokenizedProgramFormat to TGSI
- Implementation of the Direct3D 11 core interfaces
- Automatically generated implementation of Direct3D 10 and 10.1
- Implementation of DXGI using the "native" framework of the EGL st
- Demos, usable either on Windows or on this implementation
  - d3d11tri, a clone of tri
  - d3d11tex, a (multi)texturing demo
  - d3d11gears, an improved version of glxgears
  - d3d11spikysphere, a D3D11 tessellation demo (currently Windows-only)
- A downloader for the Microsoft HLSL compiler, needed to recompile
  the shaders (compiled shader bytecode is also included)

To compile this, configure at least with these options:
--with-state-trackers=egl,d3d1x --with-egl-platforms=x11
plus some gallium drivers (such as softpipe with --enable-gallium-swrast)

The Wine headers (usually from a wine-dev or wine-devel package) must
be installed.
Only x86-32 has been tested.

You may need to run "make" in the subdirectories of src/gallium/winsys/sw
and you may need to manually run "sudo make install" in
src/gallium/targets/egl

To test it, run the demos in the "progs" directory.
Windows binaries are included to find out how demos should work, and to
test Wine integration when it will be done.

Enjoy, and let me know if you manage to compile and run this, or
which issues you are facing if not.

Using softpipe is recommended for now, and your mileage with hardware
drivers may vary.
However, getting this to work on hardware drivers is also obviously very
important.

Note that currently llvmpipe is buggy and causes all 3 gears to be
drawn with the same color.
Use export GALLIUM_DRIVER=softpipe to avoid this.

Thanks to all the Gallium contributors and especially the VMware
team, whose work made it possible to implement Direct3D 10/11 much
more easily than it would have been otherwise.

4 files changed, 131 insertions, 0 deletions

diff --git a/src/gallium/state_trackers/d3d1x/docs/Makefile b/src/gallium/state_trackers/d3d1x/docs/Makefile
new file mode 100644
index 00000000000..ca1e3ce05dd
--- /dev/null
+++ b/src/gallium/state_trackers/d3d1x/docs/Makefile
@@ -0,0 +1,4 @@
+all: module_dependencies.svg module_dependencies.pdf
+
+include ../Makefile.inc
+
diff --git a/src/gallium/state_trackers/d3d1x/docs/coding_style.txt b/src/gallium/state_trackers/d3d1x/docs/coding_style.txt
new file mode 100644
index 00000000000..a644a1323f3
--- /dev/null
+++ b/src/gallium/state_trackers/d3d1x/docs/coding_style.txt
@@ -0,0 +1,85 @@
+The goal of these guidelines is to allow as much freedom as possible, while keeping the code buildable and pleasant to read.
+
+* Formatting
+
+- Indent with a single tab character. This is the best choice, since anyone can use the visual indentation he prefers by adjust the tab width setting in his editor.
+- Align multiline statements with an additional extra tab before each continuation line 
+- Keep in mind that people can program with proportional fonts: hence, don't attempt to align anything not at the start of the line, since it's impossible
+- In general, there should never be two consecutive spaces in the source code
+- As a special exception, [in] and __in annotations are followed by two spaces to align them with [out] and __out if displayed with a fixed size font. This may be revisited.
+- There is no strict limit on line length, but try to not make lines too long, and insert a line break where it looks good
+
+* Language/platform features
+
+All language features of C++03 with TR1 and all the STL library may be used.
+Obviously, try to keep the code simple, readable and intuitive, code size small, and compilation time short where possible.
+Platform/compiler-specific extensions can be used if beneficial, protected by #ifs.
+
+C++0x is currently not used since it's unreleased and currently not well supported by clang.
+Once GCC, clang and Visual C++ all have very good or complete support, and ideally the standard is finalized, we can start taking advantage of it.
+Change this document once that happens.
+
+Boost is currently not used because it hasn't been necessary and it's best to keep things simple.
+If really necessary, add a dependency on it, but use it judiciously.
+
+C should be used only for old code, and preferably completely avoided.
+
+You can freely assume that char is 8-bit, short 16-bit and int 32-bit, that long and pointers are 32-bit or 64-bit, that long long is at least 64-bit, that float is 32-bit and that double is 64-bit.
+However, when you intend a specific size, int8_t, etc. are preferred.
+
+* Naming style
+
+ Code implementing public parts of Windows interfaces (and derived ones) should follow Windows naming conventions:
+ - Classes are like GalliumD3D11VertexShader
+ - Functions are like CreateVertexShader
+ - Variables are like ppVertexShader
+
+ Other code should follow Gallium/Linux/POSIX/STL/Boost naming conventions:
+ - Classes are like maybe_mutex_t
+ - Functions are like xs_create_shader
+ - Variables are like sampler_view
+ 
+ Template parameters are named accordingly to what looks best for the specific case.
+ Typically it will be FooBar for typename parameters and foo_bar for non-typename ones.
+ 
+ * Implementation style
+ 
+See the comments in d3d1xstutil.h for the COM implementation method.
+In particular, avoid multiple/virtual inheritance in favor of mixins where possible.
+ 
+Try to limit or avoid preprocessor magic and multiline macros and use templates instead where possible.
+Often, you can lessen the preprocessor magic by putting some of it in a template instantiated by the remaining magic.
+
+Forward declarations should not be used unless necessary.
+In particular C++ classes should be implemented "inline" and should you should almost never have a forward declaration of a class.
+To achieve this, you can opt to create an "interface class", which goes into an header or earlier in the C++ file, and an "implementation class" with goes in the C++ file.
+Alternatively, use global helpers with forward declaration. 
+
+Order definitions so that forward declarations are not necessary (e.g. put main at the end of the file).
+
+Choose between "struct" or "class" depending on whether the first declared member is public or private, to save the explicit specifier. 
+
+Try to use const appropriately, esp. as a qualifier for member functions.
+
+Try to avoid Microsoft-style TYPES like FLOAT, UINT, etc. in favor of the usual C types like float, unsigned.
+
+Where feasible, if a platform is missing a function/keyword, add a definition of it with the standard name, rather than inventing an "abstraction layer".
+
+Try to use typedefs for STL maps on which  you need to declare iterations, as well as function pointers or other "weird" C types.
+ 
+ To iterate, use the following idiom from LLVM, which is optimal, unless end() is trivial:
+ for(iterator_type i = begin(), e = end(); i != e; ++i)
+ {}
+ 
+ Otherwise, you risk the compiler evaluating end() for each loop iteration.
+ If end() is trivial, use this:
+ for(iterator_type i = begin(); i != end(); ++i)
+ {}
+ 
+ Note the "++i" instead of the "i++" to avoid creating an unnecessary copy (esp. with overloaded operators).
+ 
+ Declare variables just before they are  needed, and inside the for() header.
+ Usually, you should initialize variable in the declaration if that's the only assignment or if it is a default value, and as a separate assignment if not.
+
+Try to use C++ references (with const if appropriate) when the pointer must be non-null, and that type is not already customarily passed with a pointer.
+
diff --git a/src/gallium/state_trackers/d3d1x/docs/module_dependencies.dot b/src/gallium/state_trackers/d3d1x/docs/module_dependencies.dot
new file mode 100644
index 00000000000..3db6fb2167a
--- /dev/null
+++ b/src/gallium/state_trackers/d3d1x/docs/module_dependencies.dot
@@ -0,0 +1,25 @@
+digraph module_dependencies
+{
+	d3dapi -> w32api;
+	gd3dapi -> d3dapi;
+	progs -> d3dapi  [style="dotted"];
+	progs -> gd3dapi [style="dotted"];
+	progs -> microsoft_directx_sdk [style="dotted"];
+	d3d1xstutil -> gd3dapi
+	d3d1xshader -> d3dapi
+	gd3d1x -> d3d1xshader;
+	gd3d1x -> d3d1xstutil;
+	gd3d10 -> gd3d1x;
+	gd3d11 -> gd3d1x;
+	dxgi -> d3d1xstutil;
+	dxgi -> gd3dapi;
+	dxgid3d10 -> gd3dapi;
+	dxgid3d11 -> gd3dapi;
+	"d3d11.dll" -> gd3d11;
+	"d3d11.dll" -> dxgid3d11;
+	"d3d10.dll" -> gd3d10;
+	"d3d10.dll" -> dxgid3d10;
+	"dxgi.dll" -> dxgi; 
+	tools -> mstools
+	mstools -> microsoft_directx_sdk
+};
diff --git a/src/gallium/state_trackers/d3d1x/docs/source_layout.txt b/src/gallium/state_trackers/d3d1x/docs/source_layout.txt
new file mode 100644
index 00000000000..46e9f2d9832
--- /dev/null
+++ b/src/gallium/state_trackers/d3d1x/docs/source_layout.txt
@@ -0,0 +1,17 @@
+Source layout and architecture of the Gallium D3D state tracker
+
+w32api is a link to Wine's include files for the Windows API 
+d3dapi contains the headers for Direct3D 10.0, 10.1 and 11.0 (independently created, except d3d10 which is based on Wine)
+gd3dapi contains the Gallium COM state tracker API and extensions to the DXGI and Direct3D APIs, both for internal and external usage
+d3d1xshader is a standalone module with a parser, disassembler and utility routines for Direct3D 10/11 shaders using Shader Model 4/5 instructions encoded using Tokenized Program Format embedded in a DXBC chunked container (the data format produced by the HLSL compiler).
+mstools contains a downloader for the Microsoft HLSL compiler
+tools contains the shader compiler, currently wrapping the Microsoft HLSL compiler
+gd3d10 contains the implementation of Direct3D 10 and 10.1 with Gallium-specific entry points
+gd3d11 contains the implementation of Direct3D 11 with Gallium-specific entry points
+gd3d1x contains the shader translator and code not directly implementing Direct3D interfaces, but needed by those implementations
+dxgid3d10 contains the DXGI-based "official" entry points to Direct3D 10.0 and 10.1
+dxgid3d11 contains the DXGI-based "official" entry points to Direct3D 11
+dxgi contains the implementation of DXGI (currently over the EGL native interface)
+d3d1xstutil contains helper code shared among all the modules in the state tracker 
+programs contains the Gallium Direct3D 11 demos, runnable either on the Microsoft or Gallium implementations
+docs contains documentation