[Mesa-dev] [PATCH v2 00/13] Enable GL_AMD_vertex_shader_layer extension
Paul Berry
stereotype441 at gmail.com
Mon Jul 29 10:21:57 PDT 2013
On 19 July 2013 17:32, Jordan Justen <jordan.l.justen at intel.com> wrote:
> git://people.freedesktop.org/~jljusten/mesa ivb-full-depth-buffer-v2
>
> This series converts DEPTH_BUFFER to use the LOD and
> minimum array element fields and always points the
> depth, hiz and stencil buffers at the top of the
> miptree surface.
>
> This should allows us to support layered rendering,
> although testing of this is not completed. Layered
> rendering will be required for GL 3.2 / GLSL 1.50
> support, but it can also be exposed via the
> GL_AMD_vertex_shader_layer extension.
>
> v2:
> * New patch 8
> "gen7 fbo: make unmatched depth/stencil configs return unsupported"
> * Patch 11 is re-written based on code review
> "i965 gen7: don't set FORCE_ZERO_RTAINDEX for layered rendering"
> * New patch 12
> "intel_mipmap_tree: all layers need hiz resolves with layered rendering"
> * Note: all other patches have been reviewed-by Paul
>
I sent comments on patches 8 and 12. Patch 11 is:
Reviewed-by: Paul Berry <stereotype441 at gmail.com>
There are two other things that I think need to happen which haven't been
addressed yet:
- The HiZ allocation code needs to be changed to follow the formulas in
Graphics BSpec: 3D-Media-GPGPU Engine > 3D Pipeline > Pixel > Depth and
Stencil > Hierarchical Depth Buffer now, since the hardware is now in
charge of the layout of the miptree in the HiZ buffer, and the layout it
uses may not be the same as the layout that was assumed by our HiZ
allocation functions before.
- When glClear() is applied to a layered framebuffer, all layers must be
cleared. I don't think we've got any code to do that yet. Note that there
are a number of different clear paths that may need to be addressed
(brw_blorp_clear_color(), brw_fast_clear_depth(), _mesa_meta_Clear(),
_mesa_meta_glsl_Clear(), and _swrast_Clear(), I think). The starting point
for all these functions is brw_clear().
Finally, there are two other rules about layered rendering that I believe
we implement correctly, but it would be nice to have some piglit tests: 1.
glReadBuffer() applied to a layered framebuffer always reads from layer 0.
2. glBlitFramebuffer() using a layered framebuffer as a source always reads
from layer 0 (even when the destination buffer is also layered).
>
> Testing on IVB and HSW:
> * Piglit: Fixes array-depth-roundtrip
>
> Testing on IVB:
> * AMD_vertex_shader_layer piglit tests on list
> * Basic visual inspection of Unigine Tropics
> * Brief testing with Portal & DOTA2
>
> Jordan Justen (13):
> i965: init global state first in
> brw_workaround_depthstencil_alignment
> gen7 depth surface: calculate more specific surface type
> gen7 depth surface: calculate depth (array size) for depth surface
> gen7 depth surface: calculate LOD being rendered to
> gen7 depth surface: calculate minimum array element being rendered
> gen7 blorp depth: calculate base surface width/height
> hsw hiz: Add new size restrictions for miplevels > 0
> gen7 fbo: make unmatched depth/stencil configs return unsupported
> gen7 depth surface: program 3DSTATE_DEPTH_BUFFER to top of surface
> hsw hiz: Remove x/y offset restriction for hiz
> i965 gen7: don't set FORCE_ZERO_RTAINDEX for layered rendering
> intel_mipmap_tree: all layers need hiz resolves with layered
> rendering
> intel: enable GL_AMD_vertex_shader_layer extension for gen7+
>
> src/mesa/drivers/dri/i965/brw_misc_state.c | 25 +++++--
> src/mesa/drivers/dri/i965/brw_tex_layout.c | 10 +--
> src/mesa/drivers/dri/i965/gen7_blorp.cpp | 100
> +++++++++++++------------
> src/mesa/drivers/dri/i965/gen7_clip_state.c | 2 +-
> src/mesa/drivers/dri/i965/gen7_misc_state.c | 83 ++++++++++++++++++--
> src/mesa/drivers/dri/i965/intel_extensions.c | 4 +
> src/mesa/drivers/dri/i965/intel_fbo.c | 16 ++++
> src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 61 ++++++++-------
> 8 files changed, 203 insertions(+), 98 deletions(-)
>
> --
> 1.7.10.4
>
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20130729/944d447d/attachment.html>
More information about the mesa-dev
mailing list