[Mesa-dev] [PATCH 06/17] i965/vs: split brw_vs_prog_data into generic and VS-specific parts.

[Paul Berry]

On 8 April 2013 09:28, Eric Anholt <eric at anholt.net> wrote:

> Paul Berry <stereotype441 at gmail.com> writes:
> > -/* Note: brw_vs_prog_data_compare() must be updated when adding fields
> to this
> > - * struct!
> > +
> > +/* Note: brw_vec4_prog_data_compare() must be updated when adding
> fields to
> > + * this struct!
> >   */
> > -struct brw_vs_prog_data {
> > +struct brw_vec4_prog_data {
> >     struct brw_vue_map vue_map;
> >
> >     GLuint curb_read_length;
> > -   GLuint urb_read_length;
> >     GLuint total_grf;
> >     GLuint nr_params;       /**< number of float params/constants */
> >     GLuint nr_pull_params; /**< number of dwords referenced by
> pull_param[] */
> >     GLuint total_scratch;
> >
> > +   int num_surfaces;
> > +
> > +   /* These pointers must appear last.  See
> brw_vec4_prog_data_compare(). */
> > +   const float **param;
> > +   const float **pull_param;
> > +};
> > +
> > +
> > +/* Note: brw_vs_prog_data_compare() must be updated when adding fields
> to this
> > + * struct!
> > + */
> > +struct brw_vs_prog_data {
> > +   struct brw_vec4_prog_data base;
> > +
> > +   GLuint urb_read_length;
>
> There's a URB read length in the GS state packet, so it seems like you'd
> want this field in the GS case as well as VS.  I'm confused.  I also
> would have expected urb_entry_size in GS.
>

You're right.  I don't know what I was thinking.  I'll fix both of those in
v2.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20130409/c9a316e3/attachment.html>