- Jan 26, 2017
-
-
Emma Anholt authored
Improves 1024x1024 TexSubImage2D by 41.2371% +/- 3.52799% (n=10).
-
Emma Anholt authored
We had a lot of memcpy call overhead because gpu_stride wasn't being inlined. But if you split out the stride==8 and stride==16 cases like this code does while still using memcpy, you'd no longer have glibc's NEON memcpy applied at which point we'd be doing 16 uncached reads instead of 64/(NEON memcpy granularity), for about a 30% performance hit. By hand writing the assembly, we can get a whole cacheline loaded at a time. Unfortunately, NEON intrinsics turned out to be unusable -- they didn't have the vldm instruction available. Note that, for now, the NEON code is only enabled when building for ARMv7 (Pi 2+). We may want to do runtime detection for the Raspbian case, in the future. Improves 1024x1024 GetTexImage by 208.256% +/- 7.07029% (n=10).
-
Emma Anholt authored
This paves the way for building it twice, with NEON assembly or not.
-
Emma Anholt authored
-
Samuel Pitoiset authored
This new query returns the current visible usage of VRAM accessed by the CPU. It will return 0 on radeon because it's unimplemented. Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com> Tested-by: Edmondo Tommasina <edmondo.tommasina@gmail.com> Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com> Reviewed-by: Marek Olšák <marek.olsak@amd.com>
-
Samuel Pitoiset authored
R600_DEBUG="info" can be used to display that size, as well as the total amount of VRAM/GTT. Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com> Tested-by: Edmondo Tommasina <edmondo.tommasina@gmail.com> Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com> Reviewed-by: Marek Olšák <marek.olsak@amd.com>
-
Ian Romanick authored
Saves a measly 20 bytes on IA32 and nothing on x64. Depending on exactly when this is applied, a lot of variation is possible due to function alignment. text data bss dec hex filename 6670131 228340 22552 6921023 699b3f lib/i965_dri.so before 6670111 228340 22552 6921003 699b2b lib/i965_dri.so after 6342932 293872 29880 6666684 65b9bc lib64/i965_dri.so before 6342932 293872 29880 6666684 65b9bc lib64/i965_dri.so after Signed-off-by: Ian Romanick <ian.d.romanick@intel.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
-
Ian Romanick authored
By putting the parameters first that match the parameters to the call site, 4 (of 14) instructions are saved at _mesa_Uniform4fv on x64. On IA32, the details of the instructions change, but it is the same count and mix of instructions. Before: 0000000000000830 <_mesa_Uniform4fv>: 830: 48 83 ec 10 sub $0x10,%rsp 834: 49 89 d0 mov %rdx,%r8 837: 48 8b 15 00 00 00 00 mov 0x0(%rip),%rdx # 83e <_mesa_Uniform4fv+0xe> 83e: 89 f8 mov %edi,%eax 840: 89 f1 mov %esi,%ecx 842: 41 b9 02 00 00 00 mov $0x2,%r9d 848: 64 48 8b 3a mov %fs:(%rdx),%rdi 84c: 48 8b 97 c8 01 02 00 mov 0x201c8(%rdi),%rdx 853: 48 8b 72 70 mov 0x70(%rdx),%rsi 857: 6a 04 pushq $0x4 859: 89 c2 mov %eax,%edx 85b: e8 00 00 00 00 callq 860 <_mesa_Uniform4fv+0x30> 860: 48 83 c4 18 add $0x18,%rsp 864: c3 retq After: 00000000000007f0 <_mesa_Uniform4fv>: 7f0: 48 83 ec 10 sub $0x10,%rsp 7f4: 48 8b 05 00 00 00 00 mov 0x0(%rip),%rax # 7fb <_mesa_Uniform4fv+0xb> 7fb: 41 b9 02 00 00 00 mov $0x2,%r9d 801: 64 48 8b 08 mov %fs:(%rax),%rcx 805: 48 8b 81 c8 01 02 00 mov 0x201c8(%rcx),%rax 80c: 6a 04 pushq $0x4 80e: 4c 8b 40 70 mov 0x70(%rax),%r8 812: e8 00 00 00 00 callq 817 <_mesa_Uniform4fv+0x27> 817: 48 83 c4 18 add $0x18,%rsp 81b: c3 retq Saves a measly 416 bytes of text on x64. Depending on exactly when this is applied, a lot of variation is possible due to function alignment. text data bss dec hex filename 6670131 228340 22552 6921023 699b3f lib/i965_dri.so before 6670131 228340 22552 6921023 699b3f lib/i965_dri.so after 6343348 293872 29880 6667100 65bb5c lib64/i965_dri.so before 6342932 293872 29880 6666684 65b9bc lib64/i965_dri.so after There is likely to be no performance change with just this patch. _mesa_uniform immediately calls validate_uniform_parameters with parameters in the "wrong" (different from the call site) order. v2: Rebase on GL_ARB_gpu_shader_fp64. v3: Rebase on GL_ARB_gpu_shader_int64. Signed-off-by: Ian Romanick <ian.d.romanick@intel.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
-
Ian Romanick authored
By putting the parameters first that match the parameters to the call site, 4 (of 16) instructions are saved at _mesa_UniformMatrix4fv on x64. On IA32, the details of the instructions change, but it is the same count and mix of instructions. Before: 0000000000001380 <_mesa_UniformMatrix4fv>: 1380: 48 83 ec 10 sub $0x10,%rsp 1384: 48 8b 05 00 00 00 00 mov 0x0(%rip),%rax # 138b <_mesa_UniformMatrix4fv+0xb> 138b: 41 89 f8 mov %edi,%r8d 138e: 41 89 f1 mov %esi,%r9d 1391: 0f b6 d2 movzbl %dl,%edx 1394: 64 48 8b 38 mov %fs:(%rax),%rdi 1398: 48 8b b7 c8 01 02 00 mov 0x201c8(%rdi),%rsi 139f: 48 8b 76 70 mov 0x70(%rsi),%rsi 13a3: 68 06 14 00 00 pushq $0x1406 13a8: 51 push %rcx 13a9: 52 push %rdx 13aa: b9 04 00 00 00 mov $0x4,%ecx 13af: ba 04 00 00 00 mov $0x4,%edx 13b4: e8 00 00 00 00 callq 13b9 <_mesa_UniformMatrix4fv+0x39> 13b9: 48 83 c4 28 add $0x28,%rsp 13bd: c3 retq After: 0000000000001360 <_mesa_UniformMatrix4fv>: 1360: 48 83 ec 10 sub $0x10,%rsp 1364: 48 8b 05 00 00 00 00 mov 0x0(%rip),%rax # 136b <_mesa_UniformMatrix4fv+0xb> 136b: 0f b6 d2 movzbl %dl,%edx 136e: 64 4c 8b 00 mov %fs:(%rax),%r8 1372: 49 8b 80 c8 01 02 00 mov 0x201c8(%r8),%rax 1379: 68 06 14 00 00 pushq $0x1406 137e: 6a 04 pushq $0x4 1380: 6a 04 pushq $0x4 1382: 4c 8b 48 70 mov 0x70(%rax),%r9 1386: e8 00 00 00 00 callq 138b <_mesa_UniformMatrix4fv+0x2b> 138b: 48 83 c4 28 add $0x28,%rsp 138f: c3 retq Saves a measly 576 bytes of text on x64. text data bss dec hex filename 6670131 228340 22552 6921023 699b3f lib/i965_dri.so before 6670131 228340 22552 6921023 699b3f lib/i965_dri.so after 6343924 293872 29880 6667676 65bd9c lib64/i965_dri.so before 6343348 293872 29880 6667100 65bb5c lib64/i965_dri.so after v2: Rebase on GL_ARB_gpu_shader_fp64. Signed-off-by: Ian Romanick <ian.d.romanick@intel.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
-
Ian Romanick authored
This is C++, so we can mix code and declarations. Doing so allows constification. Signed-off-by: Ian Romanick <ian.d.romanick@intel.com> Reviewed-by: Plamena Manolova <plamena.manolova@intel.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
-
Lionel Landwerlin authored
Fixes: dEQP-VK.spirv_assembly.instruction.compute.opspecconstantop.vector_related dEQP-VK.spirv_assembly.instruction.graphics.opspecconstantop.vector_related* Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Reviewed-by: Jason Ekstrand <jason@jlekstrand.net> Cc: "17.0 13.0" <mesa-stable@lists.freedesktop.org>
-
Lionel Landwerlin authored
Looking at the following bit of SPIRV shader : ... %zero = OpConstant %i32 0 %ivec3_0 = OpConstantComposite %ivec3 %zero %zero %zero %vec3_undef = OpUndef %ivec3 %sc_0 = OpSpecConstant %i32 0 %sc_1 = OpSpecConstant %i32 0 %sc_2 = OpSpecConstant %i32 0 ... Our compiler currently stops parsing variables & types on the OpUndef and switches to instructions, leaving the following sc_[0-2] variables untreated. Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Reviewed-by: Jason Ekstrand <jason@jlekstrand.net> Cc: "17.0 13.0" <mesa-stable@lists.freedesktop.org>
-
Lionel Landwerlin authored
The size of the pool is slightly smaller than the size of the structure containing the whole pool. We need to take that into account on when setting up the internals. Fixes a crash due to out of bound memory access in: dEQP-VK.api.descriptor_pool.out_of_pool_memory v2: Drop debug traces (Lionel) Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Reviewed-by: Jason Ekstrand <jason@jlekstrand.net> Cc: "17.0 13.0" <mesa-stable@lists.freedesktop.org>
-
Kenneth Graunke authored
When trying to blit larger tiled surfaces, the pitch can be larger than 32768 bytes, which means it won't fit in a GLshort. Passing it in will truncate the stride to 0, which has...surprising results. The pitch can be up to 32,768 DWords, or 128kB. We measure it in bytes, but divide by 4 when programming it. So we need to handle values up to 131,072. Switch from GLshort to int32_t to avoid the truncation. Fixes GL45-CTS.gtf30.GL3Tests.depth_texture.depth_texture_copyteximage at widths greater than 8192. v2: Use int32_t as negative values can be used (Jason). Cc: "17.0" <mesa-stable@lists.freedesktop.org> Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
-
Kenneth Graunke authored
SIMD16 compute shaders use a send(16) with mlen 1 for the EOT message, using a source of g127 for the single register. With a UD type, this supposedly could read g128, which doesn't exist, causing the simulator to get cranky. Use a UW type to avoid this. Cc: "17.0" <mesa-stable@lists.freedesktop.org> Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Francisco Jerez <currojerez@riseup.net> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
-
Iago Toral authored
According to GL_KHR_vulkan_glsl, the signature of subpassLoad() is: gvec4 subpassLoad(gsubpassInput subpass); gvec4 subpassLoad(gsubpassInputMS subpass, int sample); So the multisampled case always receives an explicit sample index that we should use. The current implementation was ignoring this parameter and using gl_SampleID value instead. Fixes: dEQP-VK.pipeline.multisample_shader_builtin.sample_id.* Reviewed-by: Jason Ekstrand <jason@jlekstrand.net> Cc: "17.0" <mesa-stable@lists.freedesktop.org>
-
Kenneth Graunke authored
I hadn't bothered to set this bit because I figured it would just paper over us getting the rectangle wrong. But it turns out that there is a legitimate reason to use it, so let's do so. The alternative would be to chop up 16k clears to multiple 8k clears, which is pointlessly painful. Cc: "17.0" <mesa-stable@lists.freedesktop.org> Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com> Reviewed-by: Nanley Chery <nanley.g.chery@intel.com>
-
Reviewed-by: Jason Ekstranad <jason@jlekstrand.net> Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
-
Add a helper function, anv_get_queue_family_properties(), which fills the struct. This patch reduces churn in the following patch that implements vkGetPhysicalDeviceQueueFamilyProperties2KHR. Reviewed-by: Jason Ekstranad <jason@jlekstrand.net> Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
-
Add a helper function, anv_get_image_format_properties(), which does all the work and has a VkPhysicalDeviceImageFormatInfo2KHR parameter. This patch reduces churn in the following patch that implements vkGetPhysicalDeviceImageFormatProperties2KHR. Reviewed-by: Jason Ekstranad <jason@jlekstrand.net> Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
-
The struct was deleted by: commit efe9d1cd Author: Edward O'Callaghan <funfunctor@folklore1984.net> Subject: anv: Clean up some unused variables Unlike the original anv_common, the new one has a non-const pNext pointer because we will use it for the output structs of VK_KHR_get_physical_device_properties2. v2: - Retype pNext from void* to struct anv_common*. Reviewed-by: Jason Ekstranad <jason@jlekstrand.net> Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
-
This is a printf-like macro that prints a debug message to stderr when built with DEBUG. If no DEBUG, then do nothing. Reviewed-by: Jason Ekstranad <jason@jlekstrand.net> Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
-
- Jan 25, 2017
-
-
Ian Romanick authored
All of the functions were passing 1 to _mesa_uniform instead of passing count. Fixes 16 unsed parameter warnings like: main/uniforms.c: In function ‘_mesa_Uniform1i64vARB’: main/uniforms.c:1692:47: warning: unused parameter ‘count’ [-Wunused-parameter] _mesa_Uniform1i64vARB(GLint location, GLsizei count, const GLint64 *value) ^~~~~ This is why I build with extra warnings enabled. Unfortunately, there are so many unused parameter warnings in Mesa that I didn't notice these added warnings for over 6 months. :( Signed-off-by: Ian Romanick <ian.d.romanick@intel.com> Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
-
Lionel Landwerlin authored
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl> Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
-
Lionel Landwerlin authored
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl> Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
-
Lionel Landwerlin authored
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl> Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
-
Lionel Landwerlin authored
The spec section 5.2 says: "vkAllocateCommandBuffers can be used to create multiple command buffers. If the creation of any of those command buffers fails, the implementation must destroy all successfully created command buffer objects from this command, set all entries of the pCommandBuffers array to VK_NULL_HANDLE and return the error." Fixes: dEQP-VK.api.object_management.alloc_callback_fail_multiple.command_buffer_primary dEQP-VK.api.object_management.alloc_callback_fail_multiple.command_buffer_secondary Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Reviewed-by: Jason Ekstrand <jason@jlekstrand.net> Cc: "13.0 17.0" <mesa-stable@lists.freedesktop.org>
-
Faith Ekstrand authored
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Cc: "17.0" <mesa-dev@lists.freedesktop.org>
-
Faith Ekstrand authored
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Cc: "17.0" <mesa-dev@lists.freedesktop.org>
-
Faith Ekstrand authored
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Cc: "17.0" <mesa-dev@lists.freedesktop.org>
-
In swr_update_derived() update texture and sampler state on a new fragment shader. GALLIUM_HUD can update fs using a previously bound texture and sampler. Reviewed-by: Bruce Cherniak <bruce.cherniak@intel.com>
-
Samuel Pitoiset authored
Useful when debugging applications which map a ton of buffers and also because we used to run into Linux's limit on the number of simultaneous mmap() calls. v2: - update the commit message Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com> Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
-
Iago Toral authored
SPIR-V maps both gl_SampleMask and gl_SampleMaskIn to the same builtin (SampleMask). The only way to tell which one we are dealing with is to check if it is an input or an output. Fixes: dEQP-VK.pipeline.multisample_shader_builtin.sample_mask.write.* Reviewed-by: Jason Ekstrand <jason@jlekstrand.net> Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com> Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
-
Iago Toral authored
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
-
- Jan 24, 2017
-
-
Dave Airlie authored
Along the lines of what 3b804819 anv: Default PointSize to 1.0 if not written by the shader does for anv, program a default point size in the hw of 1.0. This preempt fixes a bunch of geom shader tests. Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl> Cc: "17.0" <mesa-stable@lists.freedesktop.org> Signed-off-by: Dave Airlie <airlied@redhat.com>
-
Marek Olšák authored
This fixes R11G11B10_FLOAT, because it's in the category of "OTHER", meaning that it doesn't have any channel description. Cc: 17.0 <mesa-stable@lists.freedesktop.org> Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
-
Marek Olšák authored
If radeonsi starts compiling an optimized shader variant asynchronously with a GL debug callback set and the application destroys the GL context, radeonsi crashes when trying to write shader stats into the debug output of a non-existent context after compilation, because st/mesa was destroyed before pipe_context. Firefox with WebGL2 enabled hits this bug. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99456 v2: protect against a double destroy in st_create_context_priv and callers. Cc: 17.0 <mesa-stable@lists.freedesktop.org> Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
-
Timothy Arceri authored
The original number was chosen in an attempt to match the limits applied to GLSL IR. A look at the git history of the why these limits were chosen for GLSL IR shows it was more to do with the slow speed of unrolling large loops in GLSL IR than anything else. The speed of loop unrolling in NIR is not a problem so we may wish to bump this even higher in future. No shader-db change, however a furture change will disbale the GLSL IR optimisation loop in the i965 backend results in 4 loops from The Talos Principle failing to unroll. Bumping the limit allows them to unroll which results in the instruction count matching the previous output from when the GLSL IR opts were still enabled. Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
-
Timothy Arceri authored
Previously the constant array would not get copy propagated until the backend did its GLSL IR opt loop. I plan on removing that from i965 shortly which caused huge regressions in Deus-ex and Tomb Raider which have large constant arrays. Moving lowering before the opt loop in the GLSL linker fixes this and unexpectedly improves some compute shaders also. shader-db results BDW: instructions helped: shaders/closed/steam/deus-ex-mankind-divided/374.shader_test CS SIMD16: 204 -> 194 (-4.90%) instructions helped: shaders/closed/steam/deus-ex-mankind-divided/318.shader_test CS SIMD8: 1010 -> 741 (-26.63%) instructions helped: shaders/closed/steam/deus-ex-mankind-divided/144.shader_test CS SIMD8: 542 -> 385 (-28.97%) cycles helped: shaders/closed/steam/deus-ex-mankind-divided/318.shader_test CS SIMD8: 1831382 -> 1818492 (-0.70%) cycles helped: shaders/closed/steam/deus-ex-mankind-divided/144.shader_test CS SIMD8: 216238 -> 206180 (-4.65%) cycles helped: shaders/closed/steam/deus-ex-mankind-divided/374.shader_test CS SIMD16: 18484 -> 16644 (-9.95%) total instructions in shared programs: 13060313 -> 13059877 (-0.00%) instructions in affected programs: 1756 -> 1320 (-24.83%) helped: 3 HURT: 0 total cycles in shared programs: 256586698 -> 256561910 (-0.01%) cycles in affected programs: 2066104 -> 2041316 (-1.20%) helped: 3 HURT: 0 V3: only call the opt loop if lowering progressed (Suggested by Eric) V2: call opts before and after lowering (Suggested by Ken) Reviewed-by: Eric Anholt <eric@anholt.net>
-
Ian Romanick authored
OpenGL ES implementations are not allowed to ship ARB extensions, and OpenGL implementations are not allowed to ship OES extensions. The functionality is also included in GL_ARB_ES2_compatibility. Ever OpenGL core-profile driver currently exposes both extensions. I don't know of any applications that explicitly check for GL_OES_read_format, so removing it seems very unlikely to cause problems. No functionality is removed. I have left this extension in place for compatibility profile. There are still OpenGL 1.x drivers in Mesa, and adding code to check for compatibility profile and not GL_ARB_ES2_compatibility for GL_IMPLEMENTATION_COLOR_READ_TYPE and GL_IMPLEMENTATION_COLOR_READ_FORMAT just feels dumb. Three other other alternatives considered: - Remove the string from compatibility profile drivers but leave the functionality in place. - Add a flag to expose the extension string, and set it in every OpenGL driver that does not expose GL_ARB_ES2_compatibility (and those drivers only). I tried this. You can't have two instances of an extension in the extension table (one dummy_true for ES1 and one with a flag for compatibility profile), so the implementation requires a bit of effort. - Only expose the extension in compatibility if the version is less than 2.0. I didn't see an easy way to do this. Signed-off-by: Ian Romanick <ian.d.romanick@intel.com> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> Cc: mesa-stable@lists.freedesktop.org
-