mesa/src/gallium
Robert Ellison 11fc390f64 CELL: use variant-length fragment ops programs
This is a set of changes that optimizes the memory use of fragment
operation programs (by using and transmitting only as much memory as is
needed for the fragment ops programs, instead of maximal sizes), as well
as eliminate the dependency on hard-coded maximal program sizes.  State
that is not dependent on fragment facing (i.e. that isn't using
two-sided stenciling) will only save and transmit a single
fragment operation program, instead of two identical programs.

- Added the ability to emit a LNOP (No Operation (Load)) instruction.
  This is used to pad the generated fragment operations programs to
  a multiple of 8 bytes, which is necessary for proper operation of
  the dual instruction pipeline, and also required for proper SPU-side
  decoding.

- Added the ability to allocate and manage a variant-length
  struct cell_command_fragment_ops.  This structure now puts the
  generated function field at the end, where it can be as large
  as necessary.

- On the PPU side, we now combine the generated front-facing and
  back-facing code into a single variant-length buffer (and only use one
  if the two sets of code are identical) for transmission to the SPU.

- On the SPU side, we pull the correct sizes out of the buffer,
  allocate a new code buffer if the one we have isn't large enough,
  and save the code to that buffer.  The buffer is deallocated when
  the SPU exits.

- Commented out the emit_fetch() static function, which was not being used.
2008-11-21 11:42:35 -07:00
..
auxiliary CELL: use variant-length fragment ops programs 2008-11-21 11:42:35 -07:00
drivers CELL: use variant-length fragment ops programs 2008-11-21 11:42:35 -07:00
include/pipe Merge commit 'origin/gallium-0.1' into gallium-0.2 2008-11-05 15:58:09 -07:00
state_trackers Merge commit 'origin/gallium-0.1' into gallium-0.2 2008-11-19 16:04:18 +00:00
winsys gdi: Reimplement using the WGL statetracker. 2008-11-21 10:44:31 +09: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.