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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/intel-gfx




[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]
  Powered by Linux