mesa/src/gallium
Robert Ellison afaa53040b CELL: changes to generate SPU code for stenciling
This set of code changes are for stencil code generation
support.  Both one-sided and two-sided stenciling are supported.
In addition to the raw code generation changes, these changes had
to be made elsewhere in the system:

- Added new "register set" feature to the SPE assembly generation.
  A "register set" is a way to allocate multiple registers and free
  them all at the same time, delegating register allocation management
  to the spe_function unit.  It's quite useful in complex register
  allocation schemes (like stenciling).

- Added and improved SPE macro calculations.
  These are operations between registers and unsigned integer
  immediates.  In many cases, the calculation can be performed
  with a single instruction; the macros will generate the
  single instruction if possible, or generate a register load
  and register-to-register operation if not.  These macro
  functions are: spe_load_uint() (which has new ways to
  load a value in a single instruction), spe_and_uint(),
  spe_xor_uint(), spe_compare_equal_uint(), and spe_compare_greater_uint().

- Added facing to fragment generation.  While rendering, the rasterizer
  needs to be able to determine front- and back-facing fragments, in order
  to correctly apply two-sided stencil.  That requires these changes:
  - Added front_winding field to the cell_command_render block, so that
    the state tracker could communicate to the rasterizer what it
    considered to be the front-facing direction.
  - Added fragment facing as an input to the fragment function.
  - Calculated facing is passed during emit_quad().
2008-10-03 18:05:14 -06:00
..
auxiliary CELL: changes to generate SPU code for stenciling 2008-10-03 18:05:14 -06:00
drivers CELL: changes to generate SPU code for stenciling 2008-10-03 18:05:14 -06:00
include/pipe cell: align instruction buffers to 8-byte, not 32-byte boundary 2008-09-26 10:15:35 -06:00
state_trackers python: Cleanup tri example. 2008-09-05 10:31:38 +09:00
winsys st: change from ** to * for st_unreference_framebuffer() 2008-09-26 14:20:15 +01:00
Makefile gallium: don't build winsys/ here 2008-09-12 07:56:43 -06:00
Makefile.template Remove src/mesa and src/mesa/main from gallium source include paths. 2008-02-19 15:07:53 +09:00
README.portability gallium: refactor/replace p_util.h with util/u_memory.h and util/u_math.h 2008-08-24 17:48:55 -06:00
SConscript python: New state tracker which exposes the pipe driver to python scripts. 2008-07-13 23:37:40 +09:00

	      CROSS-PLATFORM PORTABILITY GUIDELINES FOR GALLIUM3D 


= General Considerations =

The state tracker and winsys driver support a rather limited number of
platforms. However, the pipe drivers are meant to run in a wide number of
platforms. Hence the pipe drivers, the auxiliary modules, and all public
headers in general, should strictly follow these guidelines to ensure


= Compiler Support =

* Include the p_compiler.h.

* Don't use the 'inline' keyword, use the INLINE macro in p_compiler.h instead.

* Cast explicitly when converting to integer types of smaller sizes.

* Cast explicitly when converting between float, double and integral types.

* Don't use named struct initializers.

* Don't use variable number of macro arguments. Use static inline functions
instead.

* Don't use C99 features.

= Standard Library =

* Avoid including standard library headers. Most standard library functions are
not available in Windows Kernel Mode. Use the appropriate p_*.h include.

== Memory Allocation ==

* Use MALLOC, CALLOC, FREE instead of the malloc, calloc, free functions.

* Use align_pointer() function defined in u_memory.h for aligning pointers
 in a portable way.

== Debugging ==

* Use the functions/macros in p_debug.h.

* Don't include assert.h, call abort, printf, etc.


= Code Style =

== Inherantice in C ==

The main thing we do is mimic inheritance by structure containment.

Here's a silly made-up example:

/* base class */
struct buffer
{
  int size;
  void (*validate)(struct buffer *buf);
};

/* sub-class of bufffer */
struct texture_buffer
{
  struct buffer base;  /* the base class, MUST COME FIRST! */
  int format;
  int width, height;
};


Then, we'll typically have cast-wrapper functions to convert base-class 
pointers to sub-class pointers where needed:

static inline struct vertex_buffer *vertex_buffer(struct buffer *buf)
{
  return (struct vertex_buffer *) buf;
}


To create/init a sub-classed object:

struct buffer *create_texture_buffer(int w, int h, int format)
{
  struct texture_buffer *t = malloc(sizeof(*t));
  t->format = format;
  t->width = w;
  t->height = h;
  t->base.size = w * h;
  t->base.validate = tex_validate;
  return &t->base;
}

Example sub-class method:

void tex_validate(struct buffer *buf)
{
  struct texture_buffer *tb = texture_buffer(buf);
  assert(tb->format);
  assert(tb->width);
  assert(tb->height);
}


Note that we typically do not use typedefs to make "class names"; we use
'struct whatever' everywhere.

Gallium's pipe_context and the subclassed psb_context, etc are prime examples 
of this.  There's also many examples in Mesa and the Mesa state tracker.