This patch applies on top of my previous series to shuffle a bunch of
the compiler code around.
On Thu, Oct 15, 2015 at 12:05 PM, Jason Ekstrand <ja...@jlekstrand.net> wrote:
> ---
> src/mesa/drivers/dri/i965/brw_vec4.cpp | 34
> ++++++++++++++++++++++++++++++++++
> src/mesa/drivers/dri/i965/brw_vs.c | 34
> ----------------------------------
> 2 files changed, 34 insertions(+), 34 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_vec4.cpp
> b/src/mesa/drivers/dri/i965/brw_vec4.cpp
> index ca4d23a..00e2d63 100644
> --- a/src/mesa/drivers/dri/i965/brw_vec4.cpp
> +++ b/src/mesa/drivers/dri/i965/brw_vec4.cpp
> @@ -1933,6 +1933,40 @@ brw_compile_vs(const struct brw_compiler *compiler,
> void *log_data,
> {
> const unsigned *assembly = NULL;
>
> + unsigned nr_attributes = _mesa_bitcount_64(prog_data->inputs_read);
> +
> + /* gl_VertexID and gl_InstanceID are system values, but arrive via an
> + * incoming vertex attribute. So, add an extra slot.
> + */
> + if (shader->info.system_values_read &
> + (BITFIELD64_BIT(SYSTEM_VALUE_VERTEX_ID_ZERO_BASE) |
> + BITFIELD64_BIT(SYSTEM_VALUE_INSTANCE_ID))) {
> + nr_attributes++;
> + }
> +
> + /* The 3DSTATE_VS documentation lists the lower bound on "Vertex URB Entry
> + * Read Length" as 1 in vec4 mode, and 0 in SIMD8 mode. Empirically, in
> + * vec4 mode, the hardware appears to wedge unless we read something.
> + */
> + if (compiler->scalar_vs)
> + prog_data->base.urb_read_length = DIV_ROUND_UP(nr_attributes, 2);
> + else
> + prog_data->base.urb_read_length = DIV_ROUND_UP(MAX2(nr_attributes, 1),
> 2);
> +
> + prog_data->nr_attributes = nr_attributes;
> +
> + /* Since vertex shaders reuse the same VUE entry for inputs and outputs
> + * (overwriting the original contents), we need to make sure the size is
> + * the larger of the two.
> + */
> + const unsigned vue_entries =
> + MAX2(nr_attributes, (unsigned)prog_data->base.vue_map.num_slots);
> +
> + if (compiler->devinfo->gen == 6)
> + prog_data->base.urb_entry_size = DIV_ROUND_UP(vue_entries, 8);
> + else
> + prog_data->base.urb_entry_size = DIV_ROUND_UP(vue_entries, 4);
> +
> if (compiler->scalar_vs) {
> prog_data->base.dispatch_mode = DISPATCH_MODE_SIMD8;
>
> diff --git a/src/mesa/drivers/dri/i965/brw_vs.c
> b/src/mesa/drivers/dri/i965/brw_vs.c
> index 6c161d0..c9afc63 100644
> --- a/src/mesa/drivers/dri/i965/brw_vs.c
> +++ b/src/mesa/drivers/dri/i965/brw_vs.c
> @@ -160,40 +160,6 @@ brw_codegen_vs_prog(struct brw_context *brw,
> &prog_data.base.vue_map, outputs_written,
> prog ? prog->SeparateShader : false);
>
> - unsigned nr_attributes = _mesa_bitcount_64(prog_data.inputs_read);
> -
> - /* gl_VertexID and gl_InstanceID are system values, but arrive via an
> - * incoming vertex attribute. So, add an extra slot.
> - */
> - if (vp->program.Base.SystemValuesRead &
> - (BITFIELD64_BIT(SYSTEM_VALUE_VERTEX_ID_ZERO_BASE) |
> - BITFIELD64_BIT(SYSTEM_VALUE_INSTANCE_ID))) {
> - nr_attributes++;
> - }
> -
> - /* The 3DSTATE_VS documentation lists the lower bound on "Vertex URB Entry
> - * Read Length" as 1 in vec4 mode, and 0 in SIMD8 mode. Empirically, in
> - * vec4 mode, the hardware appears to wedge unless we read something.
> - */
> - if (brw->intelScreen->compiler->scalar_vs)
> - prog_data.base.urb_read_length = DIV_ROUND_UP(nr_attributes, 2);
> - else
> - prog_data.base.urb_read_length = DIV_ROUND_UP(MAX2(nr_attributes, 1),
> 2);
> -
> - prog_data.nr_attributes = nr_attributes;
> -
> - /* Since vertex shaders reuse the same VUE entry for inputs and outputs
> - * (overwriting the original contents), we need to make sure the size is
> - * the larger of the two.
> - */
> - const unsigned vue_entries =
> - MAX2(nr_attributes, prog_data.base.vue_map.num_slots);
> -
> - if (brw->gen == 6)
> - prog_data.base.urb_entry_size = DIV_ROUND_UP(vue_entries, 8);
> - else
> - prog_data.base.urb_entry_size = DIV_ROUND_UP(vue_entries, 4);
> -
> if (0) {
> _mesa_fprint_program_opt(stderr, &vp->program.Base, PROG_PRINT_DEBUG,
> true);
> --
> 2.5.0.400.gff86faf
>
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
