Re: [PATCH] tools/null_state_gen: generate null render state

[Damien Lespiau <damien.lespiau@intel.com>]

On Tue, May 06, 2014 at 04:39:01PM +0300, Mika Kuoppala wrote:
> diff --git a/tools/null_state_gen/intel_renderstate_gen8.c b/tools/null_state_gen/intel_renderstate_gen8.c
> new file mode 100644
> index 0000000..7e22b24
> --- /dev/null
> +++ b/tools/null_state_gen/intel_renderstate_gen8.c

[...]

> +static void
> +gen7_emit_urb(struct intel_batchbuffer *batch) {
> +	/* XXX: Min valid values from mesa */
> +	const int vs_entries = 64;
> +	const int vs_size = 2;
> +	const int vs_start = 2;
> +
> +	OUT_BATCH(GEN7_3DSTATE_URB_VS);
> +	OUT_BATCH(vs_entries | ((vs_size - 1) << 16) | (vs_start << 25));
> +	OUT_BATCH(GEN7_3DSTATE_URB_GS);
> +	OUT_BATCH(vs_start << 25);
> +	OUT_BATCH(GEN7_3DSTATE_URB_HS);
> +	OUT_BATCH(vs_start << 25);
> +	OUT_BATCH(GEN7_3DSTATE_URB_DS);
> +	OUT_BATCH(vs_start << 25);
> +}

It seems that for BDW GT3, the minimal start is documented as 4. Mesa
has actually been updated to do the right thing now (push contants take
32KB on GT3) and vs_start is 4 on GT3.

Same story for the other URB allocations. But as they are disabled, may
not matter much. We don't setup the PUSH_CONSTANT state, so it's
possible the VS is able to address the start of the URB. Meh?

I'd still put vs_start to 4 I guess.

I'm quite puzzled by why we need to do all that, but let's not go there
again.

-- 
Damien