On Mon, Nov 3, 2008 at 3:06 AM, Eric Anholt <[EMAIL PROTECTED]> wrote:
> It shouldn't offer anything new over what's in the docs (except for G4X 
> notes),
> but here it's all in one place.
> ---
>  src/mesa/drivers/dri/i965/brw_urb.c |   39 
> ++++++++++++++++++++++++++++++++++-
>  1 files changed, 38 insertions(+), 1 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_urb.c 
> b/src/mesa/drivers/dri/i965/brw_urb.c
> index 1a00417..5cc51ad 100644
> --- a/src/mesa/drivers/dri/i965/brw_urb.c
> +++ b/src/mesa/drivers/dri/i965/brw_urb.c
> @@ -42,7 +42,44 @@
>  #define SF 3
>  #define CS 4
>
> -/* XXX: Are the min_entry_size numbers useful?
> +/** @file brw_urb.c
> + *
> + * Manages the division of the URB space between the various fixed-function
> + * units.
> + *
> + * See the Thread Initiation Management section of the GEN4 B-Spec, and
> + * the individual *_STATE structures for restrictions on numbers of
> + * entries and threads.
> + */
> +
> +/*
> + * Generally, a unit requires a min_nr_entries based on how many entries
> + * it produces before the downstream unit gets unblocked and can use and
> + * dereference some of its handles.
> + *
> + * The SF unit preallocates a PUE at the start of thread dispatch, and only
> + * uses that one.  So it requires one entry per thread.
> + *
> + * For CLIP, the SF unit will hold the previous primitive while the
> + * next is getting assembled, meaning that linestrips require 3 CLIP VUEs
> + * (vertices) to ensure continued processing, trifans require 4, and 
> tristrips
> + * require 5.  There can be 1 or 2 threads, and each has the same 
> requirement.
> + *
> + * GS has the same requirement as CLIP, but it never handles tristrips,
> + * so we can lower the minimum to 4 for the POLYGONs (trifans) it produces.
> + * We only run it single-threaded.
> + *
> + * For VS, the number of entries may be 8, 12, 16, or 32 (or 64 on G4X).
> + * Each thread processes 2 preallocated VUEs (vertices) at a time, and they
> + * get streamed down as soon as threads processing earlier vertices get
> + * theirs accepted.
> + *
> + * Each unit will take the number of URB entries we give it (based on the
> + * entry size calculated in brw_vs_emit.c for VUEs, brw_sf_emit.c for PUEs,
> + * and brw_curbe.c for the CURBEs) and decide its maximum number of
> + * threads it can support based on that. in brw_*_state.c.
> + *

Eric,

It's been quite a few years, but everything here tallies with my
understanding of the pipeline.  Even if minor issues turn up, it looks
like you're thinking about things in the right way.

Keith

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Mesa3d-dev mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

Reply via email to