<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jun 16, 2016 at 11:43 AM, Ian Romanick <span dir="ltr"><<a href="mailto:idr@freedesktop.org" target="_blank">idr@freedesktop.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 06/11/2016 09:02 AM, Jason Ekstrand wrote:<br>
> The RenderTargetViewExtent field of RENDER_SURFACE_STATE is supposed to be<br>
> set to the depth of a 3-D texture when rendering.  Unfortunatley, that<br>
</span>                                                     Unfortunately<br>
<span class=""><br>
> field is only 9 bits on Sandy Bridge and prior so we can't actually bind<br>
> a 3-D texturing for rendering if it has depth > 512.  On Ivy Bridge, this<br>
> field was bumpped to 11 bits so we can go all the way up to 2048.<br>
</span>            bumped<br>
<span class=""><br>
> Cc: "11.1 11.2 12.0" <<a href="mailto:mesa-stable@lists.freedesktop.org">mesa-stable@lists.freedesktop.org</a>><br>
> ---<br>
>  src/mesa/drivers/dri/i965/brw_context.c | 5 ++++-<br>
>  1 file changed, 4 insertions(+), 1 deletion(-)<br>
><br>
> diff --git a/src/mesa/drivers/dri/i965/brw_context.c b/src/mesa/drivers/dri/i965/brw_context.c<br>
> index 7bbc128..3b11bef 100644<br>
> --- a/src/mesa/drivers/dri/i965/brw_context.c<br>
> +++ b/src/mesa/drivers/dri/i965/brw_context.c<br>
> @@ -467,7 +467,10 @@ brw_initialize_context_constants(struct brw_context *brw)<br>
>     ctx->Const.MaxImageUnits = MAX_IMAGE_UNITS;<br>
>     ctx->Const.MaxRenderbufferSize = 8192;<br>
>     ctx->Const.MaxTextureLevels = MIN2(14 /* 8192 */, MAX_TEXTURE_LEVELS);<br>
> -   ctx->Const.Max3DTextureLevels = 12; /* 2048 */<br>
> +   if (brw->gen >= 7)<br>
> +      ctx->Const.Max3DTextureLevels = 12; /* 2048 */<br>
> +   else<br>
> +      ctx->Const.Max3DTextureLevels = 10; /* 512 */<br>
<br>
</span>This should use ?: like MaxArrayTextureLayers below.<br>
<br>
This was increased from 512 to 2048 in 2014 in commit 06b047eb.  There<br>
was some assertion in the commit message that the Windows driver was<br>
already advertising 2048.  There is no mention, however, of which<br>
hardware the Windows driver was checked on.  In the related bug report<br>
(<a href="https://bugs.freedesktop.org/show_bug.cgi?id=74130" rel="noreferrer" target="_blank">https://bugs.freedesktop.org/show_bug.cgi?id=74130</a>), Ken says, "All<br>
Gen4+ systems support 2048x2048 3D textures, so we could just bump the<br>
limit."<br>
<br>
It sounds like this may be a temporary fix, and we need a work around<br>
for rendering to slices > 9? <br></blockquote><div><br></div><div>It's a bit more subtle than that, I'm afraid.  The current gen4 render target setup code (which isn't used on SNB) can handle rendering to any layer of a 3-D texture regardless of size and SNB could be fixed up to do the same.  The problem is when you use layered rendering.  When doing layered rendering, we can only access at most 512 layers.  This means that we need to either limit the texture size or we need to give the user an incomplete framebuffer if they try and do layered rendering on a 3-D texture with more than 512 slices.  That's kind-of a nasty edge for applications to hit.<br><br></div><div>--Jason<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5"><br>
>     ctx->Const.MaxCubeTextureLevels = 14; /* 8192 */<br>
>     ctx->Const.MaxArrayTextureLayers = brw->gen >= 7 ? 2048 : 512;<br>
>     ctx->Const.MaxTextureMbytes = 1536;<br>
><br>
<br>
</div></div></blockquote></div><br></div></div>