llvmpipe,i915: add back NEW_RASTERIZER dependency when computing vertex info
authorRoland Scheidegger <sroland@vmware.com>
Wed, 20 Jan 2016 23:04:56 +0000 (00:04 +0100)
committerRoland Scheidegger <sroland@vmware.com>
Wed, 20 Jan 2016 23:09:55 +0000 (00:09 +0100)
I removed this mistakenly in 2dbc20e45689e09766552517a74e2270e49817b5. I
actually thought it should not be necessary and a piglit run didn't show
any differences, but this shouldn't have been in there.
draw_prepare_shader_outputs() is in fact dependent on NEW_RASTERIZER.
The new polygon-mode-facing test indeed shows why this is necessary, there's
lots of invalid reads and writes with valgrind (also crashes without
valgrind), because the pre-pipeline vertex size doesn't match the
post-pipeline vertex size (note this won't help much with stages which don't
have the prepare hook which can grow the vertex size, in particular the wide
point stage, but this isn't used by llvmpipe). The test still won't pass, of
course, but it is only usage of uninitialized values now, which is much
less dangerous...
(Albeit I'm pretty sure for i915 it really is not needed anymore as it
doesn't care about the extra outputs and doesn't call
draw_prepare_shader_outputs().)

Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
src/gallium/auxiliary/draw/draw_llvm.c
src/gallium/drivers/i915/i915_state_derived.c
src/gallium/drivers/llvmpipe/lp_state_derived.c

index 142d78ae49ddc01bec10d97837314cf91a6bccbd..b48bdcc779ea2c707b3692cacacb71609411b886 100644 (file)
@@ -1618,6 +1618,12 @@ draw_llvm_generate(struct draw_llvm *llvm, struct draw_llvm_variant *variant,
    context_ptr               = LLVMGetParam(variant_func, 0);
    io_ptr                    = LLVMGetParam(variant_func, 1);
    vbuffers_ptr              = LLVMGetParam(variant_func, 2);
+   /*
+    * XXX: stride is actually unused. The stride we use is strictly calculated
+    * from the number of outputs (including the draw_extra outputs).
+    * Should probably fix some day (we need a new vs just because of extra
+    * outputs which the generated vs won't touch).
+    */
    stride                    = LLVMGetParam(variant_func, 5 + (elts ? 1 : 0));
    vb_ptr                    = LLVMGetParam(variant_func, 6 + (elts ? 1 : 0));
    system_values.instance_id = LLVMGetParam(variant_func, 7 + (elts ? 1 : 0));
index bd0f448f645bd6ee36afeb9cad12bce859648338..177b85459855eaddd0ab8f9518e73e8a44fe1ce6 100644 (file)
@@ -184,7 +184,7 @@ static void calculate_vertex_layout(struct i915_context *i915)
 struct i915_tracked_state i915_update_vertex_layout = {
    "vertex_layout",
    calculate_vertex_layout,
-   I915_NEW_FS | I915_NEW_VS
+   I915_NEW_RASTERIZER | I915_NEW_FS | I915_NEW_VS
 };
 
 
index 34961cbbac50e6fef4f9dadabe5ec695f9bca6ea..c90f2f270fe2a8ac6f50ffafb1f55b61c6800465 100644 (file)
@@ -190,8 +190,10 @@ void llvmpipe_update_derived( struct llvmpipe_context *llvmpipe )
       llvmpipe->tex_timestamp = lp_screen->timestamp;
       llvmpipe->dirty |= LP_NEW_SAMPLER_VIEW;
    }
-      
-   if (llvmpipe->dirty & (LP_NEW_FS |
+
+   /* This needs LP_NEW_RASTERIZER because of draw_prepare_shader_outputs(). */
+   if (llvmpipe->dirty & (LP_NEW_RASTERIZER |
+                          LP_NEW_FS |
                           LP_NEW_VS))
       compute_vertex_info(llvmpipe);