summaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorJason Ekstrand <[email protected]>2017-01-13 09:30:13 -0800
committerJason Ekstrand <[email protected]>2017-01-13 16:31:17 -0800
commit3b804819650cc943fcd4cccedd140e4b27fbf993 (patch)
treeaf1860df4039d30325483c441ece9a367c29a2de
parent99d497c5b6912c5a8b2fec48084e3e00c7c80395 (diff)
anv: Default PointSize to 1.0 if not written by the shader
The Vulkan rules for point size are a bit whacky. If you only have a vertex shader and you use points, then you must write PointSize in your vertex shader. If you have a geometry or tessellation shader, then it's dependent on the shaderTessellationAndGeometryPointSize device feature. From the Vulkan 1.0.38 specification: "shaderTessellationAndGeometryPointSize indicates whether the PointSize built-in decoration is available in the tessellation control, tessellation evaluation, and geometry shader stages. If this feature is not enabled, members decorated with the PointSize built-in decoration must not be read from or written to and all points written from a tessellation or geometry shader will have a size of 1.0. This also indicates whether shader modules can declare the TessellationPointSize capability for tessellation control and evaluation shaders, or if the shader modules can declare the GeometryPointSize capability for geometry shaders. An implementation supporting this feature must also support one or both of the tessellationShader or geometryShader features." In other words, if the feature is disbled (the client can disable features!) then they don't write PointSize and we provide a 1.0 default but if the feature is enabled, they do write PointSize and we use the one they wrote in the shader. There are at least two valid ways we can implement this: 1) Track whether or not shaderTessellationAndGeometryPointSize is enabled and set the 3DSTATE_SF bits based on that and what stages are enabled, ignoring the shader source. 2) Just look at the last geometry stage VUE map and see if they wrote PointSize and set the 3DSTATE_SF accordingly. The second solution is the easiest and the most robust against invalid usage of the Vulkan API, so we choose to go with that one. This fixes all of the dEQP-VK.tessellation.primitive_discard.*point_mode tests. The tests are also broken because they unconditionally enable shaderTessellationAndGeometryPointSize if it's supported by the implementation and then don't write PointSize in the evaluation shader. However, since this is the "robust against invalid API usage" solution, the tests happily pass. :-) Reviewed-by: Kenneth Graunke <[email protected]>
-rw-r--r--src/intel/vulkan/genX_pipeline.c12
1 files changed, 10 insertions, 2 deletions
diff --git a/src/intel/vulkan/genX_pipeline.c b/src/intel/vulkan/genX_pipeline.c
index 7fa68c004eb..a537a40905c 100644
--- a/src/intel/vulkan/genX_pipeline.c
+++ b/src/intel/vulkan/genX_pipeline.c
@@ -420,8 +420,16 @@ emit_rs_state(struct anv_pipeline *pipeline,
sf.TriangleStripListProvokingVertexSelect = 0;
sf.LineStripListProvokingVertexSelect = 0;
sf.TriangleFanProvokingVertexSelect = 1;
- sf.PointWidthSource = Vertex;
- sf.PointWidth = 1.0;
+
+ const struct brw_vue_prog_data *last_vue_prog_data =
+ anv_pipeline_get_last_vue_prog_data(pipeline);
+
+ if (last_vue_prog_data->vue_map.slots_valid & VARYING_BIT_PSIZ) {
+ sf.PointWidthSource = Vertex;
+ } else {
+ sf.PointWidthSource = State;
+ sf.PointWidth = 1.0;
+ }
#if GEN_GEN >= 8
struct GENX(3DSTATE_RASTER) raster = {