summaryrefslogtreecommitdiffstats
path: root/src/intel/vulkan/genX_pipeline.c
Commit message (Collapse)AuthorAgeFilesLines
* anv/pipeline: Properly handle unset gl_Layer and gl_ViewportIndexJason Ekstrand2017-04-041-3/+24
| | | | | | | | | | When the shader does not set one of these values, they are supposed to get a default value of 0. We have hardware bits in 3DSTATE_CLIP for this but haven't been setting them. This fixes the intermittent failure of dEQP-VK.geometry.layered.3d.render_to_default_layer. Reviewed-by: Kenneth Graunke <[email protected]> Cc: "13.0 17.0" <[email protected]>
* anv/genX: Solve the vkCreateGraphicsPipelines crashXu,Randy2017-03-201-2/+2
| | | | | | | | | | | | The crash is due to NULL pColorBlendState, which is legal if the pipeline has rasterization disabled or if the subpass of the render pass the pipeline is created against does not use any color attachments. Test: Sample subpasses from LunarG can run without crash Signed-off-by: Xu,Randy <[email protected]> Reviewed-by: Jason Ekstrand <[email protected]> Cc: "17.0 13.0" <[email protected]>
* anv: Disable VF statistics for blorp and SOL memcpyJason Ekstrand2017-03-171-0/+9
| | | | | | | | | | | | | | | | | | | In order to get accurate statistics, we need to disable statistics for blits, clears, and the surface state memcpy at the top of each secondary command buffer. There are two possible approaches to this: 1) Disable before the blit/memcpy and re-enable afterwards 2) Move emitting 3DSTATE_VF_STATISTICS from initialization and make it part of pipeline state and then just disabale statistics before blits and memcpy operations. Emitting 3DSTATE_VF_STATISTICS should be fairly cheap so it doesn't really matter which path we take. We choose the second option as it's more consistent with the way the rest of the statistics are enabled and disabled. Reviewed-by: Lionel Landwerlin <[email protected]>
* anv/pipeline: Enable clipper statisticsJason Ekstrand2017-03-171-0/+1
| | | | Reviewed-by: Lionel Landwerlin <[email protected]>
* anv: improve error reporting when creating pipelinesIago Toral Quiroga2017-03-161-2/+3
| | | | | | | Specifically, report 'out of memory' errors that might have happened while emitting the pipeline's batch. Reviewed-by: Topi Pohjolainen <[email protected]>
* anv: avoid crashes when failing to allocate batchesIago Toral Quiroga2017-03-161-0/+6
| | | | | | | | | | | | | | | | | | | | | | Most of the time we use macros that handle this situation transparently, but there are some cases were we need to handle this explicitly. This patch makes sure we don't crash, notice that error handling takes place in the function that actually failed the allocation, anv_batch_emit_dwords(), which will set the status field of the batch so it can be used at a later moment to report the error to the user. v2: - Not crashing is not good enough, we need to keep track of the error (Topi, Jason). Iago: now that we track errors in the batch, this is being handled. - Added guards in a few more places that needed it (Iago) v3: - Check result of anv_batch_emitn() for NULL before calling memset() in emit_vertex_input() (Topi) Reviewed-by: Topi Pohjolainen <[email protected]>
* anv: Store the user's VkAttachmentReferenceNanley Chery2017-03-021-4/+4
| | | | | | | | We will be using the image layout. Store the full struct directly from the user. Signed-off-by: Nanley Chery <[email protected]> Reviewed-by: Jason Ekstrand <[email protected]>
* anv: Take a device parameter in anv_state_flushJason Ekstrand2017-02-211-2/+1
| | | | | | | This allows the helper to check for llc instead of having to do it manually at all the call sites. Reviewed-by: Lionel Landwerlin <[email protected]>
* anv: Rename clflush_range and state_clflushJason Ekstrand2017-02-211-1/+1
| | | | | | | | It's a bit shorter and easier to work with. Also, we're about to add a helper called clflush which does the clflush but without any memory fencing. Reviewed-by: Lionel Landwerlin <[email protected]>
* anv: Implement the Skylake stencil PMA optimizationJason Ekstrand2017-02-141-2/+4
| | | | | | | | | | Unfortunately, this doesn't substantially improve the performance of any known apps. With Dota 2 on my Sky Lake gt4, it seems help by somewhere between 0% and 1% but there's enough noise that it's hard to get a clear picture. Reviewed-by: Lionel Landwerlin <[email protected]> Reviewed-by: Nanley Chery <[email protected]>
* anv/pipeline: Be smarter about depth/stencil stateJason Ekstrand2017-02-141-34/+141
| | | | | | | | | It's a bit hard to measure because it almost gets lost in the noise, but this seemed to help Dota 2 by a percent or two on my Broadwell GT3e desktop. Reviewed-by: Lionel Landwerlin <[email protected]> Reviewed-by: Nanley Chery <[email protected]>
* anv/pipeline: Make a copy of VkPipelineDepthStencilStateCreateinfoJason Ekstrand2017-02-141-16/+18
| | | | | Reviewed-by: Lionel Landwerlin <[email protected]> Reviewed-by: Nanley Chery <[email protected]>
* anv: Add support for the PMA fix on BroadwellJason Ekstrand2017-02-141-0/+42
| | | | | | | | | | This helps Dota 2 on Broadwell by 8-9%. I also hacked up the driver and used the Sascha "shadowmapping" demo to get some results. Setting uses_kill to true dropped the framerate on the demo by 25-30%. Enabling the PMA fix brought it back up to around 90% of the original framerate. Reviewed-by: Lionel Landwerlin <[email protected]> Reviewed-by: Nanley Chery <[email protected]>
* anv: Disable stencil writes when both write masks are zeroJason Ekstrand2017-02-141-2/+4
| | | | | | | | | | | | Vulkan doesn't have a stencilWriteEnable bit like it does for depth. Instead, you have a stencil mask. Since the stencil mask is handled as dynamic state, we have to handle it later during command buffer construction. This, combined with a later commit, seems to help Dota2 on my Broadwell GT3e desktop by a couple percent because it allows the hardware to move the depth and stencil writes to early in more cases. Reviewed-by: Lionel Landwerlin <[email protected]> Reviewed-by: Nanley Chery <[email protected]>
* anv/pipeline: set ThreadDispatchEnable conditionallyJuan A. Suarez Romero2017-02-061-23/+26
| | | | | | | | Set 3DSTATE_WM/ThreadDispatchEnable bit on/off based on the same conditions as used in the GL version. Signed-off-by: Juan A. Suarez Romero <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* anv: emit DrawID if neededLionel Landwerlin2017-02-021-1/+24
| | | | | | | | v2: use define for buffer ID (Jason) Signed-off-by: Lionel Landwerlin <[email protected]> Reviewed-by: Anuj Phogat <[email protected]> Reviewed-by: Jason Ekstrand <[email protected]>
* anv: always allocate a vertex element with vertexid or instanceidLionel Landwerlin2017-02-021-12/+0
| | | | | | | | | | | | | | | | | | | | | | | | | Up to now on Gen8+ we only allocated a vertex element for gl_InstanceIndex or gl_VertexIndex when a vertex shader uses gl_BaseInstanceARB or gl_BaseVertexARB. This is because we would configure the VF_SGVS packet to make the VF unit write the gl_InstanceIndex & gl_VertexIndex values right behind the values computed from the vertex buffers. In the next commit we will also write the gl_DrawIDARB value. Our backend expects to pull the gl_DrawIDARB value from the element following the element containing gl_InstanceIndex, gl_VertexIndex, gl_BaseInstanceARB and gl_BaseVertexARB (see vec4_vs_visitor::setup_attributes). Therefore we need to allocate an element for the SGVS elements as long as at least one of the SGVS element is read by the shader. Otherwise our shader will use a gl_DrawIDARB value pulled from the URB one element too far (most likely garbage). v2: Fix my english (Lionel) Signed-off-by: Lionel Landwerlin <[email protected]> Reviewed-by: Anuj Phogat <[email protected]> Reviewed-by: Jason Ekstrand <[email protected]>
* anv: move BaseVertexID/BaseInstanceID vertex buffer index to 31Lionel Landwerlin2017-02-021-1/+1
| | | | | | | | v2: use define for buffer ID (Jason) Signed-off-by: Lionel Landwerlin <[email protected]> Reviewed-by: Anuj Phogat <[email protected]> Reviewed-by: Jason Ekstrand <[email protected]>
* anv: limit vertex buffers to 31Lionel Landwerlin2017-02-021-1/+1
| | | | | | Signed-off-by: Lionel Landwerlin <[email protected]> Reviewed-by: Anuj Phogat <[email protected]> Reviewed-by: Jason Ekstrand <[email protected]>
* anv: set UAV coherence required bit when neededIago Toral Quiroga2017-01-171-0/+51
| | | | | | | | | | | | | | | | The same we do in the OpenGL driver (comment copied from there). This is required to ensure that we execute the fragment shader stage when side-effects (such as image or ssbo stores) are present but there are no color writes. I found this while writing a test to check rendering to a framebuffer without attachments where the fragment shader does not produce any color outputs but writes to an image via imageStore(). Without this patch the fragment shader does not execute and the image is not written, which is not correct. Reviewed-by: Jason Ekstrand <[email protected]>
* anv: Default PointSize to 1.0 if not written by the shaderJason Ekstrand2017-01-131-2/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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]>
* anv/pipeline: Replace get_fs_input_map with get_last_vue_prog_dataJason Ekstrand2017-01-131-16/+4
| | | | | | This lets us delete a helper from genX_pipeline.c Reviewed-by: Lionel Landwerlin <[email protected]>
* anv: Emit 3DSTATE_HS/TE/DS packets.Kenneth Graunke2017-01-101-0/+89
| | | | | Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Jason Ekstrand <[email protected]>
* anv: add helper to get vue map for fragment shaderLionel Landwerlin2017-01-101-6/+1
| | | | | Signed-off-by: Lionel Landwerlin <[email protected]> Reviewed-by: Jason Ekstrand <[email protected]>
* anv: don't skip the VUE header if we are reading gl_Layer in a fragment shaderIago Toral Quiroga2017-01-091-4/+16
| | | | | | | This is the same we do in the GL driver: the hardware provides gl_Layer in the VUE header, so when the fragment shader reads it we can't skip it. Reviewed-by: Jason Ekstrand <[email protected]>
* nir/i965: use two slots from inputs_read for dvec3/dvec4 vertex input attributesJuan A. Suarez Romero2017-01-091-6/+40
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | So far, input_reads was a bitmap tracking which vertex input locations were being used. In OpenGL, an attribute bigger than a vec4 (like a dvec3 or dvec4) consumes just one location, any other small attribute. So we mark the proper bit in inputs_read, and also the same bit in double_inputs_read if the attribute is a dvec3/dvec4. But in Vulkan, this is slightly different: a dvec3/dvec4 attribute consumes two locations, not just one. And hence two bits would be marked in inputs_read for the same vertex input attribute. To avoid handling two different situations in NIR, we just choose the latest one: in OpenGL, when creating NIR from GLSL/IR, any dvec3/dvec4 vertex input attribute is marked with two bits in the inputs_read bitmap (and also in the double_inputs_read), and following attributes are adjusted accordingly. As example, if in our GLSL/IR shader we have three attributes: layout(location = 0) vec3 attr0; layout(location = 1) dvec4 attr1; layout(location = 2) dvec3 attr2; then in our NIR shader we put attr0 in location 0, attr1 in locations 1 and 2, and attr2 in location 3 and 4. Checking carefully, basically we are using slots rather than locations in NIR. When emitting the vertices, we do a inverse map to know the corresponding location for each slot. v2 (Jason): - use two slots from inputs_read for dvec3/dvec4 NIR from GLSL/IR. v3 (Jason): - Fix commit log error. - Use ladder ifs and fix braces. - elements_double is divisible by 2, don't need DIV_ROUND_UP(). - Use if ladder instead of a switch. - Add comment about hardware restriction in 64bit vertex attributes. Reviewed-by: Jason Ekstrand <[email protected]>
* anv: fix multiple creation with internal failureLionel Landwerlin2017-01-051-18/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | The specification section 9.4 says : When an application attempts to create many pipelines in a single command, it is possible that some subset may fail creation. In that case, the corresponding entries in the pPipelines output array will be filled with VK_NULL_HANDLE values. If any pipeline fails creation (for example, due to out of memory errors), the vkCreate*Pipelines commands will return an error code. The implementation will attempt to create all pipelines, and only return VK_NULL_HANDLE values for those that actually failed. Fixes : dEQP-VK.api.object_management.alloc_callback_fail_multiple.graphics_pipeline dEQP-VK.api.object_management.alloc_callback_fail_multiple.compute_pipeline v2: C is hard let's go shopping (Lionel) v3: Remove unnecessary condition in for loops (Lionel) v4: Document why we return on first failure (Eduardo) Move i declaration inside for() (Eduardo) v5: Move array cleanup out of loop (Jason) Signed-off-by: Lionel Landwerlin <[email protected]>
* anv/pipeline: Make is_dual_src_blend_factor inlineJason Ekstrand2016-11-261-1/+1
| | | | | | It's not used on gen8+ so it causes unused function warnings. Reviewed-by: Ilia Mirkin <[email protected]>
* anv/pipeline: Make the temp blend attachment state pointer constJason Ekstrand2016-11-261-1/+3
| | | | | | This fixes a "discards const" warning since blend is const. Reviewed-by: Ilia Mirkin <[email protected]>
* anv/gen7: only enable dual-source blending when there are dual-source factorsIlia Mirkin2016-11-231-3/+33
| | | | | | | | Apparently the hw wedges otherwise, as mentioned in i965 comments. Reported-by: Emmanuel Gil Peyrot <[email protected]> Signed-off-by: Ilia Mirkin <[email protected]> Reviewed-by: Jason Ekstrand <[email protected]>
* anv/pipeline: Handle depth/stencil self-dependenciesJason Ekstrand2016-11-221-6/+24
| | | | Reviewed-by: Jordan Justen <[email protected]>
* anv: Set clip/cull distances fields in packets.Kenneth Graunke2016-11-221-6/+26
| | | | | Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Jason Ekstrand <[email protected]>
* intel: Share URB configuration code between GL and Vulkan.Kenneth Graunke2016-11-191-150/+34
| | | | | | | | | This code is far too complicated to cut and paste. v2: Update the newly added genX_gpu_memcpy.c; const a few things. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Topi Pohjolainen <[email protected]>
* intel: Convert devinfo->urb.min_*_entries into an array.Kenneth Graunke2016-11-191-3/+3
| | | | | Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Topi Pohjolainen <[email protected]>
* intel: Convert devinfo->urb.max_*_entries into an array.Kenneth Graunke2016-11-191-4/+8
| | | | | Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Topi Pohjolainen <[email protected]>
* anv/pipeline: Use get_scratch_space/address for compute shadersJason Ekstrand2016-11-161-9/+7
| | | | | Reviewed-by: Kristian H. Kristensen <[email protected]> Reviewed-by: Timothy Arceri <[email protected]>
* anv: Move INTERFACE_DESCRIPTOR_DATA setup to the pipelineJason Ekstrand2016-11-161-0/+26
| | | | | | | | | | There are a few dynamic bits, namely binding table and sampler addresses, but most of it is static and really belongs in the pipeline. It certainly doesn't belong in flush_compute_descriptor_set. We'll use the same state merging trick we use for gen7 DEPTH_STENCIL. Reviewed-by: Kristian H. Kristensen <[email protected]> Reviewed-by: Timothy Arceri <[email protected]>
* anv/pipeline: Roll genX_pipeline_util.h into genX_pipeline.cJason Ekstrand2016-11-161-1/+1266
| | | | | Reviewed-by: Kristian H. Kristensen <[email protected]> Reviewed-by: Timothy Arceri <[email protected]>
* anv/pipeline: Unify graphics_pipeline_createJason Ekstrand2016-11-161-0/+80
| | | | | Reviewed-by: Kristian H. Kristensen <[email protected]> Reviewed-by: Timothy Arceri <[email protected]>
* anv/pipeline: Get rid of the kernel pointer fieldsJason Ekstrand2016-11-161-4/+0
| | | | | | | | | | Now that we have anv_shader_bin, they're completely redundant with other information we have in the pipeline. For vertex shaders, we also go through way too much work to put the offset in one or the other field and then look at which one we put it in later. Reviewed-by: Timothy Arceri <[email protected]> Reviewed-by: Kristian H. Kristensen <[email protected]>
* anv: move to using vk_alloc helpers.Dave Airlie2016-10-191-3/+3
| | | | | | | This moves all the alloc/free in anv to the generic helpers. Acked-by: Jason Ekstrand <[email protected]> Signed-off-by: Dave Airlie <[email protected]>
* anv: Move Create*Pipelines into genX_cmd_buffer.cJason Ekstrand2016-10-141-2/+61
| | | | | | | | Now that we don't have meta, we have no need for a gen-agnostic pipeline create path. We can, instead, just generate one Create*Pipelines function per gen and be done with it. Signed-off-by: Jason Ekstrand <[email protected]>
* anv: Get rid of graphics_pipeline_create_info_extraJason Ekstrand2016-10-141-2/+0
| | | | | | | | | Now that we no longer have meta, all pipelines get created via the normal Vulkan pipeline creation mechanics. There is no more need for this bit of extra magic data that we've been passing around. Signed-off-by: Jason Ekstrand <[email protected]> Reviewed-by: Topi Pohjolainen <[email protected]>
* anv: get rid of duplicated values from gen_device_infoLionel Landwerlin2016-09-231-2/+3
| | | | | Signed-off-by: Lionel Landwerlin <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* anv: pipeline: use correct number of thread for computeLionel Landwerlin2016-09-211-1/+4
| | | | | | | | | | | | | Reproduces this commit : commit 0fb85ac08d61d365e67c8f79d6955e9f89543560 Author: Kenneth Graunke <[email protected]> Date: Mon Jun 6 21:37:34 2016 -0700 i965: Use the correct number of threads for compute shaders. Signed-off-by: Lionel Landwerlin <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* anv: device: calculate compute thread numbers using subslices numbersLionel Landwerlin2016-09-211-1/+3
| | | | | Signed-off-by: Lionel Landwerlin <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* anv: Refactor pipeline l3 config setupJason Ekstrand2016-09-031-2/+2
| | | | | | | | | Now that we're using gen_l3_config.c, we no longer have one set of l3 config functions per gen and we can simplify a bit. Also, we know that only compute uses SLM so we don't need to look for it in all of the stages. Signed-off-by: Jason Ekstrand <[email protected]> Reviewed-by: Jordan Justen <[email protected]>
* anv: Rework pipeline cachingJason Ekstrand2016-08-301-2/+1
| | | | | | | | | | | | | | | | | | | The original pipeline cache the Kristian wrote was based on a now-false premise that the shaders can be stored in the pipeline cache. The Vulkan 1.0 spec explicitly states that the pipeline cache object is transiant and you are allowed to delete it after using it to create a pipeline with no ill effects. As nice as Kristian's design was, it doesn't jive with the expectation provided by the Vulkan spec. The new pipeline cache uses reference-counted anv_shader_bin objects that are backed by a large state pool. The cache itself is just a hash table mapping keys hashes to anv_shader_bin objects. This has the added advantage of removing one more hand-rolled hash table from mesa. Signed-off-by: Jason Ekstrand <[email protected]> Cc: "12.0" <[email protected]> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97476 Acked-by: Kristian Høgsberg Kristensen <[email protected]>
* anv/pipeline: Properly handle OOM during shader compilationJason Ekstrand2016-08-301-3/+7
| | | | | Signed-off-by: Jason Ekstrand <[email protected]> Cc: "12.0" <[email protected]>
* anv: Use different BOs for different scratch sizes and stagesJason Ekstrand2016-06-221-4/+4
| | | | | | | | | This solves a race condition where we can end up having different stages stomp on each other because they're all trying to scratch in the same BO but they have different views of its layout. Signed-off-by: Jason Ekstrand <[email protected]> Cc: "12.0" <[email protected]>
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-25 00:12:01 +0000