[Mesa-dev] [PATCH v2 14/16] i965: Add fs_visitor::run_vs() to generate scalar vertex shader code

[Kenneth Graunke]

On Monday, December 01, 2014 12:02:01 PM Kristian Høgsberg wrote:
> On Fri, Nov 14, 2014 at 4:21 PM, Kenneth Graunke <kenneth at whitecape.org> wrote:
> > On Thursday, November 13, 2014 04:28:20 PM Kristian Høgsberg wrote:
> >> This patch uses the previous refactoring to add a new run_vs() method
> >> that generates vertex shader code using the scalar visitor and
> >> optimizer.
> >>
> >> Signed-off-by: Kristian Høgsberg <krh at bitplanet.net>
> >> ---
> >>  src/mesa/drivers/dri/i965/brw_fs.cpp         |  99 ++++++++-
> >>  src/mesa/drivers/dri/i965/brw_fs.h           |  21 +-
> >>  src/mesa/drivers/dri/i965/brw_fs_visitor.cpp | 303
> > ++++++++++++++++++++++++++-
> >>  3 files changed, 412 insertions(+), 11 deletions(-)
> >>
> >> diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp
> > b/src/mesa/drivers/dri/i965/brw_fs.cpp
> >> index 4dce0a2..8007977 100644
> >> --- a/src/mesa/drivers/dri/i965/brw_fs.cpp
> >> +++ b/src/mesa/drivers/dri/i965/brw_fs.cpp
> >> @@ -1828,6 +1828,56 @@ fs_visitor::assign_urb_setup()
> >>        urb_start + prog_data->num_varying_inputs * 2;
> >>  }
> >>
> >> +void
> >> +fs_visitor::assign_vs_urb_setup()
> >> +{
> >> +   brw_vs_prog_data *vs_prog_data = (brw_vs_prog_data *) prog_data;
> >> +   int grf, count, slot, channel, attr;
> >> +
> >> +   assert(stage == MESA_SHADER_VERTEX);
> >> +   count = _mesa_bitcount_64(vs_prog_data->inputs_read);
> >> +   if (vs_prog_data->uses_vertexid || vs_prog_data->uses_instanceid)
> >> +      count++;
> >> +
> >> +   /* Each attribute is 4 regs. */
> >> +   this->first_non_payload_grf =
> >> +      payload.num_regs + prog_data->curb_read_length + count * 4;
> >> +
> >> +   unsigned vue_entries =
> >> +      MAX2(count, vs_prog_data->base.vue_map.num_slots);
> >> +
> >> +   vs_prog_data->base.urb_entry_size = ALIGN(vue_entries, 4) / 4;
> >> +   vs_prog_data->base.urb_read_length = (count + 1) / 2;
> >> +
> >> +   assert(vs_prog_data->base.urb_read_length <= 15);
> >
> > What enforces this assertion?  It obviously needs to be true, since
> > the "Vertex URB Entry Read Length" field in 3DSTATE_VS has a maximum
> > value of 15 in SIMD8 mode.
> >
> > But this looks like the exact same calculation done in
> > vec4_vs_visitor::setup_attributes, and the limit there is [1, 63].
> >
> > The documentation indicates that the API may allow more vertex attributes
> > than can practically be supported by pushing VUEs in as payload registers:
> >
> > "The EU limit of 128 GRFs imposes a maximum limit of 30 elements per vertex
> >  pushed into the payload, though the practical limit may be lower. If input
> >  vertices exceed the practical limit, software must decide between resorting
> >  to pulling elements during thread execution or dropping back to SIMD4x2
> >  dispatch."
> >
> > I don't see any code in this series for falling back, nor for pulling VUEs
> > out of the URB (and avoiding overwriting them before they're loaded), so
> > I expect this would simply assert fail on a vertex shader with too many
> > inputs.
> 
> We only advertise the spec required minimum of 16 vertex attributes
> right now.  The 3DSTATE_VS field counts pairs of vertex attributes
> which means we can handle up to 30 in scalar mode.
> 
> Kristian

You're right, and it looks like the linker enforces this, so we should never
see a program that violates these constraints.

Thanks!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20141201/ac36eb65/attachment.sig>