summaryrefslogtreecommitdiffstats
path: root/src/mesa
Commit message (Collapse)AuthorAgeFilesLines
* i965/gen7_urb: Re-emit PUSH_CONSTANT_ALLOC on some gen9Nanley Chery2018-08-311-0/+28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | According to internal docs, some gen9 platforms have a pixel shader push constant synchronization issue. Although not listed among said platforms, this issue seems to be present on the GeminiLake 2x6's we've tested. We consider the available workarounds to be too detrimental on performance. Instead, we mitigate the issue by applying part of one of the workarounds. Re-emit PUSH_CONSTANT_ALLOC at the top of every batch (as suggested by Ken). Fixes ext_framebuffer_multisample-accuracy piglit test failures with the following options: * 6 depth_draw small depthstencil * 8 stencil_draw small depthstencil * 6 stencil_draw small depthstencil * 8 depth_resolve small * 6 stencil_resolve small depthstencil * 4 stencil_draw small depthstencil * 16 stencil_draw small depthstencil * 16 depth_draw small depthstencil * 2 stencil_resolve small depthstencil * 6 stencil_draw small * all_samples stencil_draw small * 2 depth_draw small depthstencil * all_samples depth_draw small depthstencil * all_samples stencil_resolve small * 4 depth_draw small depthstencil * all_samples depth_draw small * all_samples stencil_draw small depthstencil * 4 stencil_resolve small depthstencil * 4 depth_resolve small depthstencil * all_samples stencil_resolve small depthstencil v2: Include more platforms in WA (Ken). Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106865 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93355 Cc: <[email protected]> Tested-by: Mark Janes <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* mesa: ignore VAO IDs equal to 0 in glDeleteVertexArraysMarek Olšák2018-08-301-0/+4
| | | | | | | | This fixes a firefox crash. Fixes: 781a78914c798dc64005b37c6ca1224ce06803fc Reviewed-by: Ian Romanick <[email protected]>
* i965/screen: Allow modifiers on sRGB formatsJason Ekstrand2018-08-301-3/+11
| | | | | | | | | | | | | | | | | | | This effectively reverts a26693493570a9d0f0fba1be617e01ee7bfff4db which was a misguided attempt at protecting intel_query_dma_buf_modifiers from invalid formats. Unfortunately, in some internal EGL cases, we can get an SRGB format validly in this function. Rejecting such formats caused us to not allow CCS in some cases where we should have been allowing it. This regressed the performance of some SynMark tests as well as GfxBench ALU2, Tessellation and Manhattan 3.0 tests There's some question of whether or not we really should be using SRGB "fourcc" formats that aren't actually in drm_foucc.h but there's not much harm in allowing them through here. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107223 Fixes: a26693493570 "i965/screen: Return false for unsupported..." Tested-By: Eero Tamminen <[email protected]> Reviewed-by: Eric Engestrom <[email protected]>
* st/mesa, gallium: add a workaround for No Mans SkyTimothy Arceri2018-08-301-0/+3
| | | | | | | | The spec seems clear this is not allowed but the Nvidia binary forces apps to add layout qualifiers so this works around the issue for No Mans Sky until the CTS can be sorted out. Reviewed-by: Marek Olšák <[email protected]>
* glsl: add a mechanism to allow layout qualifiers on function paramsTimothy Arceri2018-08-301-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The spec is quite clear this is not allowed: From Section 4.4. (Layout Qualifiers) of the GLSL 4.60 spec: "Layout qualifiers can appear in several forms of declaration. They can appear as part of an interface block definition or block member, as shown in the grammar in the previous section. They can also appear with just an interface-qualifier to establish layouts of other declarations made with that qualifier: layout-qualifier interface-qualifier ; Or, they can appear with an individual variable declared with an interface qualifier: layout-qualifier interface-qualifier declaration ;" From Section 4.10 (Memory Qualifiers) of the GLSL 4.60 spec: "Layout qualifiers cannot be used on formal function parameters, and layout qualification is not included in parameter matching." However on the Nvidia binary driver they actually fail to compile if image function params don't have a layout qualifier. This results in applications such as No Mans Sky using layout qualifiers on params. I've submitted a CTS test to expose this problem in the Nvidia driver but until that is resolved this patch will help Mesa drivers work around the issue. Reviewed-by: Marek Olšák <[email protected]>
* mesa: enable ARB_direct_state_access in compat for GL3.1+Timothy Arceri2018-08-303-7/+17
| | | | | | | | We could enable it for lower versions of GL but this allows us to just use the existing version/extension checks that are already used by the core profile. Reviewed-by: Marek Olšák <[email protected]>
* intel/compiler: Remove surface_idx from brw_image_paramJason Ekstrand2018-08-292-12/+3
| | | | | | | Now that the drivers are lowering to surface indices themselves, we no longer need to push the surface index into the shader. Reviewed-by: Kenneth Graunke <[email protected]>
* anv,i965: Lower away image derefs in the driverJason Ekstrand2018-08-292-0/+131
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously, the back-end compiler turn image access into magic uniform reads and there was a complex contract between back-end compiler and driver about setting up and filling out those params. As of this commit, both drivers now lower image_deref_load_param_intel intrinsics to load_uniform intrinsics controlled by the driver and lower the other image_deref_* intrinsics to image_* intrinsics which take an actual binding table index. There are still "magic" uniforms but they are now added and controlled entirely by the driver and that contract no longer spans components. This also has the side-effect of making most image use compile-time binding table indices. Previously, all image access pulled the binding table index from a uniform. Part of the reason for this was that the magic uniforms made it difficult to decouple binding table indices from the uniforms and, since they are indexed completely differently (especially in Vulkan), it was hard to pull them apart. Now that the driver is handling both, it's trivial to decouple the two and provide actual binding table indices. Shader-db results on Kaby Lake: total instructions in shared programs: 15166872 -> 15164293 (-0.02%) instructions in affected programs: 115834 -> 113255 (-2.23%) helped: 191 HURT: 0 total cycles in shared programs: 571311495 -> 571196465 (-0.02%) cycles in affected programs: 4757115 -> 4642085 (-2.42%) helped: 73 HURT: 67 total spills in shared programs: 10951 -> 10926 (-0.23%) spills in affected programs: 742 -> 717 (-3.37%) helped: 7 HURT: 0 total fills in shared programs: 22226 -> 22201 (-0.11%) fills in affected programs: 1146 -> 1121 (-2.18%) helped: 7 HURT: 0 Reviewed-by: Kenneth Graunke <[email protected]>
* glsl/link,i965: Make ImageAccess four-stateJason Ekstrand2018-08-292-9/+12
| | | | | | | | | | | | | | | | | The GLSL spec allows you to set both the "readonly" and "writeonly" qualifiers on images to indicate that it can only be used with imageSize. However, we had no way of representing this int he linked shader and flagged it as GL_READ_ONLY. This is good from a "does it use this buffer?" perspective but not from a format and access lowering perspective. By using GL_NONE for if "readonly" and "writeonly" are both set, we can detect this case in the driver and handle it correctly. Nothing currently relies on the type of surface in the "readonly" + "writeonly" case but that's about to change. i965 is the only drier which uses the ImageAccess field and gl_bindless_image::access is currently unused. Reviewed-by: Kenneth Graunke <[email protected]>
* intel/compiler: Do image load/store lowering to NIRJason Ekstrand2018-08-291-0/+2
| | | | | | | | | | | | | | | | | | | | | | | This commit moves our storage image format conversion codegen into NIR instead of doing it in the back-end. This has the advantage of letting us run it through NIR's optimizer which is pretty effective at shrinking things down. In the common case of rgba8, the number of instructions emitted after NIR is done with it is half of what it was with the lowering happening in the back-end. On the downside, the back-end's lowering is able to directly use predicates and the NIR lowering has to use IFs. Shader-db results on Kaby Lake: total instructions in shared programs: 15166910 -> 15166872 (<.01%) instructions in affected programs: 5895 -> 5857 (-0.64%) helped: 15 HURT: 0 Clearly, we don't have that much image_load_store happening in the shaders in shader-db.... Reviewed-by: Kenneth Graunke <[email protected]>
* st/mesa: Disable blending for integer formats.Kenneth Graunke2018-08-291-0/+1
| | | | | | | | | Blending isn't valid for integer formats. Rather than having drivers worry about this, just disable blending in this case. This hopefully will increase hits in the CSO cache as well, by eliminating most of the meaningless fields in this case. Reviewed-by: Marek Olšák <[email protected]>
* mesa: allow GL_UNSIGNED_BYTE type for SNORM readsTapani Pälli2018-08-291-0/+9
| | | | | | | | | | | | | | | | | | OpenGL ES spec states: "For normalized fixed-point rendering surfaces, the combination format RGBA and type UNSIGNED_BYTE is accepted." This fixes following failing VK-GL-CTS tests: KHR-GLES3.packed_pixels.pbo_rectangle.rgba8_snorm KHR-GLES3.packed_pixels.rectangle.rgba8_snorm KHR-GLES3.packed_pixels.varied_rectangle.rgba8_snorm Signed-off-by: Tapani Pälli <[email protected]> https://bugs.freedesktop.org/show_bug.cgi?id=107658 Cc: [email protected] Reviewed-by: Marek Olšák <[email protected]> Tested-by: Andres Gomez <[email protected]>
* i965: enable AMD_depth_clamp_separateSagar Ghuge2018-08-281-0/+1
| | | | | Signed-off-by: Sagar Ghuge <[email protected]> Reviewed-by: Ian Romanick <[email protected]>
* i965: add functional changes for AMD_depth_clamp_separateSagar Ghuge2018-08-281-5/+15
| | | | | | | | | | | | | | Gen >= 9 have ability to control clamping of depth values separately at near and far plane. z_w is clamped to the range [min(n,f), 0] if clamping at near plane is enabled, [0, max(n,f)] if clamping at far plane is enabled and [min(n,f) max(n,f)] if clamping at both plane is enabled. v2: 1) Use better coding style (Ian Romanick) Signed-off-by: Sagar Ghuge <[email protected]> Reviewed-by: Ian Romanick <[email protected]>
* mesa: add EXTRA_EXT for AMD_depth_clamp_separateSagar Ghuge2018-08-282-0/+6
| | | | | | Signed-off-by: Sagar Ghuge <[email protected]> Reviewed-by: Ian Romanick <[email protected]> Reviewed-by: Marek Olšák <[email protected]>
* mesa: add support for GL_AMD_depth_clamp_separate tokensSagar Ghuge2018-08-281-0/+36
| | | | | | | | | | | _mesa_set_enable() and _mesa_IsEnabled() extended to accept new two tokens GL_DEPTH_CLAMP_NEAR_AMD and GL_DEPTH_CLAMP_FAR_AMD. v2: Remove unnecessary parentheses (Marek Olsak) Signed-off-by: Sagar Ghuge <[email protected]> Reviewed-by: Ian Romanick <[email protected]> Reviewed-by: Marek Olšák <[email protected]>
* mesa: Add support for AMD_depth_clamp_separateSagar Ghuge2018-08-2812-33/+111
| | | | | | | | | | | | | | | | | | | | | | | | | | | Enable _mesa_PushAttrib() and _mesa_PopAttrib() to handle GL_DEPTH_CLAMP_NEAR_AMD and GL_DEPTH_CLAMP_FAR_AMD tokens. Remove DepthClamp, because DepthClampNear + DepthClampFar replaces it, as suggested by Marek Olsak. Driver that enables AMD_depth_clamp_separate will only ever look at DepthClampNear and DepthClampFar, as suggested by Ian Romanick. v2: 1) Remove unnecessary parentheses (Marek Olsak) 2) if AMD_depth_clamp_separate is unsupported, TEST_AND_UPDATE GL_DEPTH_CLAMP only (Marek Olsak) 3) Clamp against near and far plane separately (Marek Olsak) 4) Clip point separately for near and far Z clipping plane (Marek Olsak) v3: Clamp raster position zw to the range [min(n,f), 0] for near plane and [0, max(n,f)] for far plane (Marek Olsak) v4: Use MIN2 and MAX2 instead of CLAMP (Marek Olsak) Signed-off-by: Sagar Ghuge <[email protected]> Reviewed-by: Ian Romanick <[email protected]> Reviewed-by: Marek Olšák <[email protected]>
* mesa: Add types for AMD_depth_clamp_separate.Sagar Ghuge2018-08-282-0/+4
| | | | | | | | | | | | Add some basic types and storage for the AMD_depth_clamp_separate extension. v2: 1) Drop unnecessary definition (Marek Olsak) 2) Expose extension in compatibility profile (Marek Olsak) Signed-off-by: Sagar Ghuge <[email protected]> Reviewed-by: Ian Romanick <[email protected]> Reviewed-by: Marek Olšák <[email protected]>
* i965: Add INTEL_fragment_shader_ordering support.Kevin Rogovin2018-08-281-0/+1
| | | | | | | | | | Adds suppport for INTEL_fragment_shader_ordering. We achieve the fragment ordering by using the same instruction as for beginInvocationInterlockARB() which is by issuing a memory fence via sendc. Signed-off-by: Kevin Rogovin <[email protected]> Reviewed-by: Plamena Manolova <[email protected]>
* mesa: Add GL/GLSL plumbing for INTEL_fragment_shader_orderingKevin Rogovin2018-08-282-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | This extension provides new GLSL built-in function beginFragmentShaderOrderingIntel() that guarantees (taking wording of GL_INTEL_fragment_shader_ordering extension) that any memory transactions issued by shader invocations from previous primitives mapped to same xy window coordinates (and same sample when per-sample shading is active), complete and are visible to the shader invocation that called beginFragmentShaderOrderingINTEL(). One advantage of INTEL_fragment_shader_ordering over ARB_fragment_shader_interlock is that it provides a function that operates as a memory barrie (instead of a defining a critcial section) that can be called under arbitary control flow from any function (in contrast the begin/end of ARB_fragment_shader_interlock may only be called once, from main(), under no control flow. Signed-off-by: Kevin Rogovin <[email protected]> Reviewed-by: Plamena Manolova <[email protected]>
* i965/gen6/xfb: handle case where transform feedback is not activeAndrii Simiklit2018-08-281-1/+1
| | | | | | | | | | | When the SVBI Payload Enable is false I guess the register R1.4 which contains the Maximum Streamed Vertex Buffer Index is filled by zero and GS stops to write transform feedback when the transform feedback is not active. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107579 Signed-off-by: Andrii Simiklit <[email protected]> Reviewed-by: Samuel Iglesias Gonsálvez <[email protected]>
* gallium: Split out PIPE_CAP_TEXTURE_MIRROR_CLAMP_TO_EDGE.Kenneth Graunke2018-08-241-1/+1
| | | | | | | | | | | | | Some hardware can do PIPE_TEX_WRAP_MIRROR_REPEAT but not PIPE_TEX_WRAP_MIRROR_CLAMP and PIPE_TEX_WRAP_MIRROR_CLAMP_TO_BORDER. Drivers for such hardware would like to advertise support for ARB_texture_mirror_clamp_to_edge but not EXT_texture_mirror_clamp. This commit adds a new PIPE_CAP_TEXTURE_MIRROR_CLAMP_TO_EDGE bit, changes the extension enable to be based on that, and enables it in all upstream drivers which supported PIPE_CAP_TEXTURE_MIRROR_CLAMP (so they continue supporting this mode).
* Revert "configure: allow building with python3"Emil Velikov2018-08-242-2/+2
| | | | | | | | | | | | | | This reverts commit ae7898dfdbe5c8dab7d11c71862353f1ae43feb0. Turns out the python scripts are _not_ fully python 3 compatible. As Ilia reported using get_xmlpool.py with LANG=C produces some weird output - see the link for details. Even though the issue was spotted with the autoconf build, it exposes a genuine problem with the script (and lack of lang handling of the meson build.) https://lists.freedesktop.org/archives/mesa-dev/2018-August/203508.html
* Revert "mesa: bump GL_MAX_ELEMENTS_INDICES and GL_MAX_ELEMENTS_VERTICES"Kenneth Graunke2018-08-242-5/+2
| | | | | | | | | | This reverts commit 095515e16ca3cb2c9f1813b6602ee57ae28325a8. This breaks KHR-GL46.map_buffer_alignment.functional on i965. This code was apparently not reviewed and I don't know why we would move from a driver configurable constant to a hardcoded value for all drivers. This really looks like an accidental hack push.
* Revert recent changes about not including compute in combined limits.Kenneth Graunke2018-08-243-27/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | As far as I can tell, no one reviewed these changes, they made i965 assert fail on driver load, and I am not certain they are correct. (Hopefully reverting these does not break radeonsi too badly...) The uniform related changes seem fine and reasonable, but the texture image units change is possibly incorrect. According to the OES_tessellation_shader spec issue 5: (5) How are aggregate shader limits computed? RESOLVED: Following the GL 4.4 model, but we restrict uniform buffer bindings to 12/stage instead of 14, this results in MAX_UNIFORM_BUFFER_BINDINGS = 72 This is 12 bindings/stage * 6 shader stages, allowing a static partitioning of the bindings even though at most 5 stages can appear in a program object). MAX_COMBINED_UNIFORM_BLOCKS = 60 This is 12 blocks/stage * 5 stages, since compute shaders can't be mixed with other stages. MAX_COMBINED_TEXTURE_IMAGE_UNITS = 96 This is 16 textures/stage * 6 stages. which definitely is including compute shaders in that last limit. Not including compute shaders breaks the following test: dEQP-GLES31.functional.state_query.integer.max_combined_texture_image_units_getinteger There was enough breakage that I figured we should just send this back to the drawing board. Revert "i965: don't include compute resources in "Combined" limits" Revert "st/mesa: don't include compute resources in "Combined" limits" Revert "mesa: don't include compute resources in MAX_COMBINED_* limits" This reverts commit b03dcb1e5f507c5950d0de053a6f76e6306ee71f. This reverts commit cff290df4c09547cd2cb3b129ec59bdebdadba90. This reverts commit 45f87a48f94148b484961f18a4f1ccf86f066b1c.
* st/mesa: expose KHR_texture_compression_astc_sliced_3dMarek Olšák2018-08-241-2/+4
| | | | | This is ASTC 2D LDR allowing texture arrays and 3D, compressing each slice as a separate 2D image. Tested by piglit. Trivial.
* st/mesa: expose EXT_disjoint_timer_queryMarek Olšák2018-08-241-0/+1
| | | | same cap as ARB_timer_query, no changes needed, tested by piglit
* mesa: expose EXT_vertex_attrib_64bitMarek Olšák2018-08-241-0/+1
| | | | | | | because the closed driver exposes it. It's the same as the ARB extension. Reviewed-by: Ian Romanick <[email protected]>
* mesa: expose AMD_query_buffer_objectMarek Olšák2018-08-241-0/+1
| | | | | | it's a subset of the ARB extension. Reviewed-by: Ian Romanick <[email protected]>
* mesa: expose AMD_multi_draw_indirectMarek Olšák2018-08-241-0/+1
| | | | | | | because the closed driver exposes it. This is equivalent to the ARB extension. Reviewed-by: Ian Romanick <[email protected]>
* mesa: expose AMD_gpu_shader_int64Marek Olšák2018-08-241-0/+1
| | | | | | | | | because the closed driver exposes it. It's equivalent to ARB_gpu_shader_int64. In this patch, I did everything the same as we do for ARB_gpu_shader_int64. Reviewed-by: Ian Romanick <[email protected]>
* mesa: expose ARB_post_depth_coverage in the Compatibility profileMarek Olšák2018-08-241-1/+1
| | | | | | It only contains GLSL changes. v2: allow the layout qualifier on GLSL <= 1.30
* i965: don't include compute resources in "Combined" limitsKenneth Graunke2018-08-231-11/+11
| | | | | | | | | | | The combined limits should only include shader stages that can be active at the same time. We don't need to include compute. See also cff290df4c09547cd2cb3b129ec59bdebdadba90 for st/mesa. Unbreaks i965 from assert failing on driver load since Marek's 45f87a48f94148b484961f18a4f1ccf86f066b1c, which dropped the core Mesa capabilities before adjusting driver limits down to match.
* gallium: add PIPE_CAP_MAX_SHADER_BUFFER_SIZEMarek Olšák2018-08-231-1/+2
| | | | Tested-by: Dieter Nützel <[email protected]>
* gallium: add PIPE_CAP_MAX_GS_INVOCATIONSMarek Olšák2018-08-231-0/+2
| | | | Tested-by: Dieter Nützel <[email protected]>
* st/mesa: fix up uniform limits to be able to expose large UBOsMarek Olšák2018-08-231-8/+23
| | | | Tested-by: Dieter Nützel <[email protected]>
* st/mesa: don't include compute resources in "Combined" limitsMarek Olšák2018-08-231-6/+3
| | | | | | | The combined limits should only include shader stages that can be active at the same time. Tested-by: Dieter Nützel <[email protected]>
* st/mesa: set ctx->Const.SubPixelBitsMarek Olšák2018-08-231-0/+1
| | | | Tested-by: Dieter Nützel <[email protected]>
* mesa: make MaxCombinedUniformComponents 64-bit to allow large UBOsMarek Olšák2018-08-232-7/+7
| | | | Tested-by: Dieter Nützel <[email protected]>
* mesa: add ctx->Const.MaxGeometryShaderInvocationsMarek Olšák2018-08-233-2/+4
| | | | | | | radeonsi wants to report a different value Reviewed-by: Ian Romanick <[email protected]> Tested-by: Dieter Nützel <[email protected]>
* mesa: don't include compute resources in MAX_COMBINED_* limitsMarek Olšák2018-08-231-9/+13
| | | | | | | | | | 5 is the maximum number of shader stages that can be used by 1 execution call at the same time (e.g. a draw call). The limit ensures that each stage can use all of its binding points. Compute is separate and doesn't need the 5x multiplier. Tested-by: Dieter Nützel <[email protected]>
* mesa: bump GL_MAX_ELEMENTS_INDICES and GL_MAX_ELEMENTS_VERTICESMarek Olšák2018-08-232-2/+5
| | | | | | | | same number as our closed GL driver v2: don't use MaxArrayLockSize Tested-by: Dieter Nützel <[email protected]>
* mesa: remove incorrect change for EXT_disjoint_timer_queryMarek Olšák2018-08-231-2/+1
| | | | | Reviewed-by: Tapani Pälli <[email protected]> Tested-by: Dieter Nützel <[email protected]>
* configure: allow building with python3Emil Velikov2018-08-232-2/+2
| | | | | | | | | | | | Pretty much all of the scripts are python2+3 compatible. Check and allow using python3, while adjusting the PYTHON2 refs. Note: - python3.4 is used as it's the earliest supported version - python3 chosen prior to python2 Signed-off-by: Emil Velikov <[email protected]> Acked-by: Eric Engestrom <[email protected]>
* meson: Run the install script with Python 3Mathieu Bridon2018-08-231-0/+1
| | | | | | | | The script was being run directly as an executable, and it has a Python 2 shebang. Reviewed-by: Eric Engestrom <[email protected]> Reviewed-by: Emil Velikov <[email protected]>
* i965: Enable INTEL_shader_atomic_float_minmax on Gen9+Ian Romanick2018-08-221-0/+1
| | | | | Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Caio Marcelo de Oliveira Filho <[email protected]>
* i965: Sort Gen9+ extension enablesIan Romanick2018-08-221-3/+3
| | | | | | | | | This is a strictly alphabetic sort, as is done in extensions_table.h There are other options. We should pick one and document it. Right now, this file is chaos. Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Caio Marcelo de Oliveira Filho <[email protected]>
* mesa: Extension boilerplate for INTEL_shader_atomic_float_minmaxIan Romanick2018-08-222-0/+2
| | | | | Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Caio Marcelo de Oliveira Filho <[email protected]>
* mesa: Extension boilerplate for NV_shader_atomic_floatIan Romanick2018-08-222-0/+2
| | | | | Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Caio Marcelo de Oliveira Filho <[email protected]>
* i965/miptree: Fix can_blit_slice()Nanley Chery2018-08-221-4/+3
| | | | | | | | | | | | | | | Check the destination's row pitch against the BLT engine's row pitch limitation as well. Fixes: 0288fe8d0417730bdd5b3477130dd1dc32bdbcd3 ("i965/miptree: Use the correct BLT pitch") v2: Fix the Fixes tag (Dylan). Check the destination row pitch (Chris). Reported-by: Dylan Baker <[email protected]> Cc: <[email protected]> Reviewed-by: Jason Ekstrand <[email protected]>
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-26 19:01:16 +0000