On 08/31/2012 12:19 PM, Eric Anholt wrote:
> As far as I can see, the intention of the requirement that we do so is to
> prevent instruction prefetch from wandering out into either unmapped memory or
> memory with a different caching type, and hanging the chip.  The kernel makes
> sure that the page after your BO has a valid page of the same caching type,
> which meets this requirement, so there's no need to waste space between our
> programs (and in instruction cache) on this.
> 
> Saves another 9kb instructions in l4d2 shaders.

That makes sense.  The kernel needs to protect us against this for the
sake of robustness against lame userspace anyway.  We may as well take
advantage of it and not waste the space.

Acked-by: Kenneth Graunke <kenn...@whitecape.org>

> ---
>  src/mesa/drivers/dri/i965/brw_eu.c |    8 --------
>  1 file changed, 8 deletions(-)
> 
> diff --git a/src/mesa/drivers/dri/i965/brw_eu.c 
> b/src/mesa/drivers/dri/i965/brw_eu.c
> index 130d801..c60b16c 100644
> --- a/src/mesa/drivers/dri/i965/brw_eu.c
> +++ b/src/mesa/drivers/dri/i965/brw_eu.c
> @@ -214,16 +214,8 @@ brw_init_compile(struct brw_context *brw, struct 
> brw_compile *p, void *mem_ctx)
>  const GLuint *brw_get_program( struct brw_compile *p,
>                              GLuint *sz )
>  {
> -   GLuint i;
> -
>     brw_compact_instructions(p);
>  
> -   /* We emit a cacheline (8 instructions) of NOPs at the end of the program 
> to
> -    * make sure that instruction prefetch doesn't wander off into some other 
> BO.
> -    */
> -   for (i = 0; i < 8; i++)
> -      brw_NOP(p);
> -
>     *sz = p->next_insn_offset;
>     return (const GLuint *)p->store;
>  }
> 

_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Reply via email to