aboutsummaryrefslogtreecommitdiffstats
path: root/src/intel
Commit message (Collapse)AuthorAgeFilesLines
* intel/compiler: Discount NOPs from instruction countsMatt Turner2020-03-091-3/+9
| | | | | | | | | | Scheduler changes can cause changes in the number of instructions due to this workaround, so just don't include NOPs in the instruction counts to prevent shader-db noise. Reviewed-by: Ian Romanick <[email protected]> Tested-by: Marge Bot <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4093> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4093>
* intel/compiler: Pass shader_stats for each SIMD modeMatt Turner2020-03-097-24/+21
| | | | | | | | | | | | | | | | | | | | Passing shader_stats to the fs_generator constructor means that the SIMD8 shader stats from the visitor (such as the scheduler mode) will be reported out for the SIMD16/SIMD32 versions as well. As you can see, we are now passing 'shader_stats' and 'stats' to generate_code(), which is obviously odd looking. Ian rebased and committed an old patch of mine which added the shader_stats struct on July 30 in commit dabb5d4bee07 (i965/fs: Add a shader_stats struct.) and shortly after on August 12 Jason added the brw_compile_stats struct in commit 134607760ac2 (intel/compiler: Fill a compiler statistics struct). I'd like to combine the two, but I'm not sure how. shader_stats is an input to generate_code() while brw_compile_stats is an output and is only used by the Vulkan driver. Leave it as is for now... Reviewed-by: Ian Romanick <[email protected]> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4093>
* intel/compiler: Pass backend_shader * to cfg_t()Matt Turner2020-03-097-16/+20
| | | | | | | | As you can see, not having a pointer to the backend_shader from within the class makes for some weird looking code. Reviewed-by: Ian Romanick <[email protected]> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4093>
* intel/compiler: Mark visitor parameters to scheduler constMatt Turner2020-03-091-10/+10
| | | | | Reviewed-by: Ian Romanick <[email protected]> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4093>
* intel/compiler: Mark some methods and parameters constMatt Turner2020-03-098-27/+27
| | | | | Reviewed-by: Ian Romanick <[email protected]> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4093>
* intel/compiler: Make instructions_to_schedule a local variableMatt Turner2020-03-091-4/+2
| | | | | Reviewed-by: Ian Romanick <[email protected]> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4093>
* intel/compiler: Remove unnecessary local variablesMatt Turner2020-03-091-3/+0
| | | | | | | These are already provided in the fs_reg_alloc class. Reviewed-by: Ian Romanick <[email protected]> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4093>
* intel/vec4: Make implied_mrf_writes() a vec4_instruction methodMatt Turner2020-03-094-9/+8
| | | | | | | | Same as commit c20dc9b8363b (intel/fs: Make implied_mrf_writes() an fs_inst method.) Reviewed-by: Ian Romanick <[email protected]> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4093>
* anv: stop storing prog param data into shader blobsLionel Landwerlin2020-03-072-14/+5
| | | | | | | | | We have no use for this data in Anv. Signed-off-by: Lionel Landwerlin <[email protected]> Reviewed-by: Jason EKstrand <[email protected]> Tested-by: Marge Bot <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/3517> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/3517>
* anv: Bounds-check pushed UBOs when robustBufferAccess = trueJason Ekstrand2020-03-075-41/+267
| | | | | | | | | | | We also have to add nir_intrinsic_load_push_constant to the list of intrinsics which use push constants in brw_nir_analyze_ubo_ranges because we're moving the loop where we rewrite the intrinsics to after we've analyzed UBO loads. Reviewed-by: Lionel Landwerlin <[email protected]> Tested-by: Marge Bot <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/3777> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/3777>
* anv: Add an align_down_u32 helperJason Ekstrand2020-03-072-2/+9
| | | | | Reviewed-by: Lionel Landwerlin <[email protected]> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/3777>
* anv: Align UBO sizes to 32BJason Ekstrand2020-03-073-0/+13
| | | | | | | | This makes all of our bounds checking consistent with the block loads we do for constant offset UBO accesses. Reviewed-by: Lionel Landwerlin <[email protected]> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/3777>
* anv: Delete some pointless break statementsJason Ekstrand2020-03-071-2/+0
| | | | | | | They immediately follow returns. Reviewed-by: Lionel Landwerlin <[email protected]> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/3777>
* anv: Pass buffer addresses into emit_push_constant*Jason Ekstrand2020-03-071-26/+32
| | | | | | | | | While we're here, we add an assert that bind_map::push_ranges is tightly packed. If it isn't, it breaks assumptions in the emit_push_constant* functions. Reviewed-by: Lionel Landwerlin <[email protected]> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/3777>
* anv: Mark max_push_range UNUSED and simplify the codeJason Ekstrand2020-03-071-3/+2
| | | | | | | | | The compiler should be smart enough to figure out that it's unused on Gen11 and earlier and delete the code which calculates. Us adding an `if (GEN_GEN >= 12)` check is unnecessary and just dirties the code. Reviewed-by: Lionel Landwerlin <[email protected]> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/3777>
* anv: Parse VkPhysicalDeviceFeatures2 in CreateDeviceJason Ekstrand2020-03-071-10/+45
| | | | | | | | | | The client may enable robustBufferAccess2 via either pCreateInfo->pEnabledFeatures or via a chained-in VkPhysicalDeviceFeatures2 struct. We need to parse both. Fixes: 022e5c7e5a5 "anv: Implement VK_KHR_get_physical_device_properties2" Reviewed-by: Lionel Landwerlin <[email protected]> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/3777>
* anv: Flatten the logic add_aux_surface_if_supported (v3)Chad Versace2020-03-061-85/+101
| | | | | | | | | | | | | | | Reduces the function's max indentation level from 5 to 3 inside the big 'if' tree. And enables more comments to be attached to the condition they describe. v2: - Add missing DEBUG_NO_RBC check. v3: - Return early on DISABLE_AUX_BIT. - Restore original order of gen7 hiz check. Tested-by: Marge Bot <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4096> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4096>
* anv: Refactor creation of aux surfaces (v2)Chad Versace2020-03-061-86/+112
| | | | | | | | | | | | | make_surface() contained a giant if-tree for creation of aux surfaces. Move the if-tree into its own function, add_aux_surface_if_supported(). This will simplify future changes for VK_EXT_image_drm_format_modifier. This patch merely moves the code verbatim, then extracts duplicate assertions to the top. v2: Rename func to add_aux_surface_if_supported [for jekstrand]. Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4096>
* anv: Add anv_image_plane_needs_shadow_surface() (v2)Chad Versace2020-03-061-31/+58
| | | | | | | | | | | | | | | | | | | The function returns true if hardware limitations require the image plane to use a shadow surface. It replaces equivalent code in make_surface(). Refactor only. No intended change in behavior. Why extract this code out of vkCreateImage? If an image requires a shadow surface, then that may impact its support for DRM format modifiers, which must be evaluated during vkGetPhysicalDeviceImageFormatProperties2. v2: - Use early return. [for jekstrand] - Unexport function. Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4096>
* intel/compiler: Calculate num_instructions in O(1) during register pressure ↵Francisco Jerez2020-03-061-3/+2
| | | | | | | | | | calculation And mark the variable declaration as const. Reviewed-by: Matt Turner <[email protected]> Tested-by: Marge Bot <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4012> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4012>
* intel/compiler: Move register pressure calculation into IR analysis objectFrancisco Jerez2020-03-063-19/+47
| | | | | | | | | | This defines a new BRW_ANALYSIS object which wraps the register pressure computation code along with its result. For the rationale see the previous commits converting the liveness and dominance analysis passes to the IR analysis framework. Reviewed-by: Matt Turner <[email protected]> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4012>
* entel/compiler: Simplify new_idom reduction in dominance tree calculationFrancisco Jerez2020-03-061-5/+2
| | | | | | | Trivial, just use a few less tokens to do the same thing. Reviewed-by: Matt Turner <[email protected]> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4012>
* intel/compiler: Move dominance tree data structure into idom_tree objectFrancisco Jerez2020-03-062-26/+47
| | | | | | | | | | | | | | It makes sense to keep the result of analysis passes independent from the IR itself. Instead of representing the idom tree as a pointer in each basic block pointing to its immediate dominator, the whole dominator tree is represented separately from the IR as an array of pointers inside the idom_tree object. This has the advantage that it's no longer possible to use stale dominance results by accident without having called require() beforehand, which makes sure that the idom tree is recalculated if necessary. Reviewed-by: Matt Turner <[email protected]> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4012>
* intel/compiler: Move idom tree calculation and related logic into analysis ↵Francisco Jerez2020-03-065-32/+59
| | | | | | | | | | | | | object This only does half of the work. The actual representation of the idom tree is left untouched, but the computation algorithm is moved into a separate analysis result class wrapped in a BRW_ANALYSIS object, along with the intersect() and dump_domtree() auxiliary functions in order to keep things tidy. Reviewed-by: Matt Turner <[email protected]> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4012>
* intel/compiler: Drop invalidate_live_intervals()Francisco Jerez2020-03-066-21/+0
| | | | | Reviewed-by: Matt Turner <[email protected]> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4012>
* intel/compiler/vec4: Switch liveness analysis to IR analysis frameworkFrancisco Jerez2020-03-068-57/+29
| | | | | | | | | | | | This involves wrapping vec4_live_variables in a BRW_ANALYSIS object and hooking it up to invalidate_analysis() so it's properly invalidated. Seems like a lot of churn but it's fairly straightforward. The vec4_visitor invalidate_ and calculate_live_intervals() methods are no longer necessary after this change. Reviewed-by: Matt Turner <[email protected]> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4012>
* intel/compiler/fs: Switch liveness analysis to IR analysis frameworkFrancisco Jerez2020-03-0612-97/+84
| | | | | | | | | | | This involves wrapping fs_live_variables in a BRW_ANALYSIS object and hooking it up to invalidate_analysis() so it's properly invalidated. Seems like a lot of churn but it's fairly straightforward. The fs_visitor invalidate_ and calculate_live_intervals() methods are no longer necessary after this change. Reviewed-by: Matt Turner <[email protected]> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4012>
* intel/compiler/vec4: Add live interval validation passFrancisco Jerez2020-03-062-0/+46
| | | | | | | | | | | | This could be improved somewhat with additional validation of the calculated live in/out sets and by checking that the calculated live intervals are minimal (which isn't strictly necessary to guarantee the correctness of the program). This should be good enough though to catch accidental use of stale liveness results due to missing or incorrect analysis invalidation. Reviewed-by: Matt Turner <[email protected]> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4012>
* intel/compiler/fs: Add live interval validation passFrancisco Jerez2020-03-062-0/+43
| | | | | | | | | | | | This could be improved somewhat with additional validation of the calculated live in/out sets and by checking that the calculated live intervals are minimal (which isn't strictly necessary to guarantee the correctness of the program). This should be good enough though to catch accidental use of stale liveness results due to missing or incorrect analysis invalidation. Reviewed-by: Matt Turner <[email protected]> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4012>
* intel/compiler: Pass single backend_shader argument to the ↵Francisco Jerez2020-03-062-5/+6
| | | | | | | | | | vec4_live_variables constructor The IR analysis framework requires the analysis result to be constructible with a single argument. Reviewed-by: Matt Turner <[email protected]> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4012>
* intel/compiler: Pass single backend_shader argument to the fs_live_variables ↵Francisco Jerez2020-03-062-11/+10
| | | | | | | | | | | constructor This removes the dependency of fs_live_variables on fs_visitor. The IR analysis framework requires the analysis result to be constructible with a single argument -- The second argument was redundant anyway. Reviewed-by: Matt Turner <[email protected]> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4012>
* intel/compiler: Restructure live intervals computation codeFrancisco Jerez2020-03-062-78/+54
| | | | | | | | | | | | This makes the structure of the vec4 live intervals calculation more similar to the FS back-end liveness analysis code. The non-CF-aware start/end computation is moved into the same pass that calculates the block-local def/use sets, which saves quite a bit of code, while the CF-aware start/end computation is moved into a separate compute_start_end() function as is done in the FS back-end. Reviewed-by: Matt Turner <[email protected]> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4012>
* intel/compiler: Move all live interval analysis results into vec4_live_variablesFrancisco Jerez2020-03-067-25/+36
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | This moves the following methods that are currently defined in vec4_visitor (even though they are side products of the liveness analysis computation) and are already implemented in brw_vec4_live_variables.cpp: > int var_range_start(unsigned v, unsigned n) const; > int var_range_end(unsigned v, unsigned n) const; > bool virtual_grf_interferes(int a, int b) const; > int *virtual_grf_start; > int *virtual_grf_end; It makes sense for them to be part of the vec4_live_variables object, because they have the same lifetime as other liveness analysis results and because this will allow some extra validation to happen wherever they are accessed in order to make sure that we only ever use up-to-date liveness analysis results. The naming of the virtual_grf_start/end arrays was rather misleading, they were indexed by variable rather than by vgrf, this renames them start/end to match the FS liveness analysis pass. The churn in the definition of var_range_start/end is just in order to avoid a collision between the start/end arrays and local variables declared with the same name. Reviewed-by: Matt Turner <[email protected]> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4012>
* intel/compiler: Move all live interval analysis results into fs_live_variablesFrancisco Jerez2020-03-069-42/+43
| | | | | | | | | | | | | | | | | | | | | | | | This moves the following methods that are currently defined in fs_visitor (even though they are side products of the liveness analysis computation) and are already implemented in brw_fs_live_variables.cpp: > bool virtual_grf_interferes(int a, int b) const; > int *virtual_grf_start; > int *virtual_grf_end; It makes sense for them to be part of the fs_live_variables object, because they have the same lifetime as other liveness analysis results and because this will allow some extra validation to happen wherever they are accessed in order to make sure that we only ever use up-to-date liveness analysis results. This shortens the virtual_grf prefix in order to compensate for the slightly increased lexical overhead from the live_intervals pointer dereference. Reviewed-by: Matt Turner <[email protected]> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4012>
* intel/compiler: Mark virtual_grf_interferes and vars_interfere as constFrancisco Jerez2020-03-065-6/+6
| | | | | Reviewed-by: Matt Turner <[email protected]> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4012>
* intel/compiler: Pass detailed dependency classes to invalidate_analysis()Francisco Jerez2020-03-0620-54/+61
| | | | | | | | | | | Have fun reading through the whole back-end optimizer to verify whether I've missed any dependency flags -- Or alternatively, just trust that any mistake here will trigger an assertion failure during analysis pass validation if it ever poses a problem for the consistency of any of the analysis passes managed by the framework. Reviewed-by: Matt Turner <[email protected]> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4012>
* intel/compiler: Define more detailed analysis dependency classesFrancisco Jerez2020-03-061-0/+46
| | | | | | | | | | | | | | | | | | | | | | | | | | | | I've deliberately separated this from the general analysis pass infrastructure in order to discuss it independently. The dependency classes defined here refer to state changes of several objects of the program IR, and are fully orthogonal and expected to change less often than the set of analysis passes present in the compiler back-end. The objective is to avoid unnecessary coupling between optimization and analysis passes in the back-end. By doing things in this way the set of flags to be passed to invalidate_analysis() can be determined from knowledge of a single optimization pass and a small set of well specified dependency classes alone -- IOW there is no need to audit all analysis passes to find out which ones might be affected by certain kind of program transformation performed by an optimization pass, as well as the converse, there is no need to audit all optimization passes when writing a new analysis pass to find out which ones can potentially invalidate the result of the analysis. The set of dependency classes defined here is rather conservative and mainly based on the requirements of the few analysis passes already part of the back-end. I've also used them without difficulty with a few additional analysis passes I've written but haven't yet sent for review. Reviewed-by: Matt Turner <[email protected]> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4012>
* intel/compiler: Introduce backend_shader method to propagate IR changes to ↵Francisco Jerez2020-03-0624-52/+93
| | | | | | | | | | | | | | | | | analysis passes The invalidate_analysis() method knows what analysis passes there are in the back-end and calls their invalidate() method to report changes in the IR. For the moment it just calls invalidate_live_intervals() (which will eventually be fully replaced by this function) if anything changed. This makes all optimization passes invalidate DEPENDENCY_EVERYTHING, which is clearly far from ideal -- The dependency classes passed to invalidate_analysis() will be refined in a future commit. Reviewed-by: Matt Turner <[email protected]> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4012>
* intel/compiler: Introduce simple IR analysis pass frameworkFrancisco Jerez2020-03-062-0/+147
| | | | | | | | | | | | Motivated in detail in the source code. The only piece missing here from the analysis pass infrastructure is some sort of mechanism to broadcast changes in the IR to all existing analysis passes, which will be addressed by a future commit. The analysis_dependency_class enum might seem a bit silly at this point, more interesting dependency categories will be defined later on. Reviewed-by: Matt Turner <[email protected]> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4012>
* intel/compiler: Reverse inclusion dependency between ↵Francisco Jerez2020-03-064-6/+3
| | | | | | | | | | | | | brw_vec4_live_variables.h and brw_vec4.h brw_vec4.h (in particular vec4_visitor) is logically a user of the live variables analysis pass, not the other way around. brw_vec4_live_variables.h requires the definition of some VEC4 IR data structures to compile, but those can be obtained directly from brw_ir_vec4.h without including brw_vec4.h. Reviewed-by: Matt Turner <[email protected]> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4012>
* intel/compiler: Reverse inclusion dependency between brw_fs_live_variables.h ↵Francisco Jerez2020-03-063-3/+4
| | | | | | | | | | | | | | | | and brw_fs.h brw_fs.h (in particular fs_visitor) is logically a user of the live variables analysis pass, not the other way around. brw_fs_live_variables.h requires the definition of some FS IR data structures to compile, but those can be obtained directly from brw_ir_fs.h without including brw_fs.h. The dependency of fs_live_variables on fs_visitor is rather accidental and will be removed in a future commit, a forward declaration is enough for the moment. Reviewed-by: Matt Turner <[email protected]> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4012>
* intel/compiler: Nest definition of live variables block_data structuresFrancisco Jerez2020-03-064-82/+83
| | | | | | | | | | | | | | | | When this commit was originally written, these two structures had the exact same name. Subsequently in commit 12a8f2616a2f (intel/compiler: Fix C++ one definition rule violations) they were renamed. Original commit message: > These two structures have exactly the same name which prevents the two > files from being included at the same time and could cause serious > trouble in the future if it ever leads to a (silent) violation of the > C++ one definition rule. Reviewed-by: Matt Turner <[email protected]> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4012>
* intel/compiler: Reverse inclusion dependency between brw_cfg.h and brw_shader.hFrancisco Jerez2020-03-064-6/+6
| | | | | | | | | This reflects the natural dependency relationship between brw_cfg.h and brw_shader.h. brw_cfg.h only requires the base IR definitions which are now part of a separate header. Reviewed-by: Matt Turner <[email protected]> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4012>
* intel/compiler: Move base IR definitions into a separate header fileFrancisco Jerez2020-03-063-157/+184
| | | | | | | | | | | | | | | | | | | | | This pulls out the i965 IR definitions into a separate file and leaves the top-level backend_shader structure and back-end compiler entry points in brw_shader.h. The purpose is to keep things tidy and prevent a nasty circular dependency between brw_cfg.h and brw_shader.h. The logical dependency between these data structures looks like: backend_shader (brw_shader.h) -> cfg_t (brw_cfg.h) -> bblock_t (brw_cfg.h) -> backend_instruction (brw_shader.h) This circular header dependency is currently resolved by using forward declarations of cfg_t/bblock_t in brw_shader.h and having brw_cfg.h include brw_shader.h, which seems backwards and won't work at all when the forward declarations of cfg_t/bblock_t are no longer sufficient in a future commit. Reviewed-by: Matt Turner <[email protected]> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4012>
* anv: Enable HiZ for VK_IMAGE_LAYOUT_TRANSFER_DST_OPTIMALJason Ekstrand2020-03-051-8/+19
| | | | | Reviewed-by: Nanley Chery <[email protected]> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/3717>
* blorp: Write to depth/stencil images as depth/stencil when possibleJason Ekstrand2020-03-053-18/+77
| | | | | | | | | | | | | | | On Gen4 and G45 and earlier, we have to handle weird offsetting to write to depth and stencil due to a lack of proper depth mipmapping support in hardware. On Gen6, we have to deal with strange HiZ and stencil layouts. Prior to Gen9, we also had to do crazy things for stencil writes because we didn't support GL_ARB_shader_stencil_export and friends in hardware. However, starting with Gen7 for depth and Gen9 for stencil, we can easily write out with the "right" hardware. This allows us to leave HiZ and other compression enabled for blorp_blit() and blorp_copy() operations. Reviewed-by: Nanley Chery <[email protected]> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/3717>
* isl: Set 3DSTATE_DEPTH_BUFFER::Depth correctly for 3D surfacesJason Ekstrand2020-03-051-1/+19
| | | | | | Cc: [email protected] Reviewed-by: Nanley Chery <[email protected]> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/3717>
* intel/gen12+: Disable mid thread preemption.Rafael Antognolli2020-03-032-0/+13
| | | | | | | | | | | | | Fixes a GPU hang in Car Chase. Cc: [email protected] v2: Add comment explaining why (Jason). Reviewed-by: Jason Ekstrand <[email protected]> Reviewed-by: Lionel Landwerlin <[email protected]> Tested-by: Marge Bot <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4035> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4035>
* intel/isl: Implement D16_UNORM workarounds.Rafael Antognolli2020-03-034-2/+75
| | | | | | | | | | | | | | | | | | | | | | | | GEN:BUG:14010455700 (lineage 1808121037): "To avoid sporadic corruptions “Set 0x7010[9] when Depth Buffer Surface Format is D16_UNORM , surface type is not NULL & 1X_MSAA" Required for fixing ttps://gitlab.freedesktop.org/mesa/mesa/issues/2501. GEN:BUG:1806527549: "Set HIZ_CHICKEN (7018h) bit 13 = 1 when depth buffer is D16_UNORM." This one could fix a GPU hang in some workloads. v2: Implement WA in isl and add another similar WA (Jason). v3: Add flushes before changing chicken registers (Jason) v4: Depth flush and stall + end of pipe sync when changing registers (Jason). Reviewed-by: Jason Ekstrand <[email protected]> Tested-by: Marge Bot <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/3801> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/3801>
* anv: multiply the scratch space by 4 on gen9-10 like iris and i965Paulo Zanoni2020-03-031-2/+16
| | | | | | | | | | | | | | | | | | | My understanding is that there's no reason for the scratch space allocation to be different between iris, i965 and anv. Let's make all the functions behave the same. I don't know if this fixes any specific gen9 bugs, it it might since it increases the scratch space. v2: Rebase. v3: Rebase. v4: Remove redundant gen 11 check (Jason). Reviewed-by: Jason Ekstrand <[email protected]> Reviewed-by: Lionel Landwerlin <[email protected]> Signed-off-by: Paulo Zanoni <[email protected]> Tested-by: Marge Bot <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4006> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4006>
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-11 14:26:57 +0000