Re: Intel clc dependency
On 4/10/24 13:53, Timo Aaltonen wrote: Brian Paul kirjoitti 6.4.2024 klo 1.05: I'm trying to build the Intel Vulkan driver. First time in a few months. I'm having build problems related to clc. I'm on Ubuntu 22.04 [...] [1347/3181] Generating src/intel/vulkan/...om command (wrapped by meson to set env) FAILED: src/intel/vulkan/grl/gfx125_bvh_build_BFS_BFS_pass1_indexed_batchable.h env MESA_SHADER_CACHE_DISABLE=true MESA_SPIRV_LOG_LEVEL=error /home/brianp/build3/mesa/build/src/intel/compiler/intel_clc -p dg2 --prefix gfx125_bvh_build_BFS_BFS_pass1_indexed_batchable -e BFS_pass1_indexed_batchable --in ../src/intel/vulkan/grl/gpu/bvh_build_BFS.cl --in /home/brianp/build3/mesa/src/intel/vulkan/grl/gpu/libs/lsc_intrinsics_fallback.cl -o src/intel/vulkan/grl/gfx125_bvh_build_BFS_BFS_pass1_indexed_batchable.h -- -cl-std=cl2.0 -D__OPENCL_VERSION__=200 -DMAX_HW_SIMD_WIDTH=16 -DMAX_WORKGROUP_SIZE=16 -I/home/brianp/build3/mesa/src/intel/vulkan/grl/gpu -I/home/brianp/build3/mesa/src/intel/vulkan/grl/include ERROR: libclc shader missing. Consider installing the libclc package Aborted (core dumped) I've installed every clc-related package I could find. I've tried several options for the 'intel-clc' option without luck. BTW, the description of intel-clc in meson_options.txt looks suspect: option( 'intel-clc', type : 'combo', deprecated: {'true': 'enabled', 'false': 'disabled'}, value : 'disabled', choices : [ 'enabled', 'disabled', 'system', ], description : 'Build the intel-clc compiler (enables Vulkan Intel ' + 'Ray Tracing on supported hardware).' ) The default is 'disabled' but that's deprecated? Choices include 'enabled' but that's deprecated too? Any tips for building the ToT Intel Vulkan driver? -Brian You need to have libclc-NN-dev installed matching with the llvm version, which on stock 22.04 would be libclc-13-dev. I'm using llvm 15 and have libclc-15-dev installed. I get the "ERROR: libclc shader missing. Consider installing the libclc package" issue I quoted above. I have llvm 15 installed because I also want to build the radv Vulkan driver. -Brian -- This electronic communication and the information and any files transmitted with it, or attached to it, are confidential and are intended solely for the use of the individual or entity to whom it is addressed and may contain information that is confidential, legally privileged, protected by privacy laws, or otherwise restricted from disclosure to anyone else. If you are not the intended recipient or the person responsible for delivering the e-mail to the intended recipient, you are hereby notified that any use, copying, distributing, dissemination, forwarding, printing, or copying of this e-mail is strictly prohibited. If you received this e-mail in error, please return the e-mail to the sender, delete it from your computer, and destroy any printed copy of it.
Re: Intel clc dependency
Thanks, Mike. That works as I don't need RT functionality. BTW, I was looking at a stale meson_options.txt file so ignore my comments about that. -Brian On 4/5/24 16:24, Mike Blumenkrantz wrote: This doesn't solve the problem about missing CLC, but I pass -Dintel_rt=disabled to avoid the whole thing. On Fri, Apr 5, 2024, 6:05 PM Brian Paul <mailto:brian.p...@broadcom.com>> wrote: I'm trying to build the Intel Vulkan driver. First time in a few months. I'm having build problems related to clc. I'm on Ubuntu 22.04 [...] [1347/3181] Generating src/intel/vulkan/...om command (wrapped by meson to set env) FAILED: src/intel/vulkan/grl/gfx125_bvh_build_BFS_BFS_pass1_indexed_batchable.h env MESA_SHADER_CACHE_DISABLE=true MESA_SPIRV_LOG_LEVEL=error /home/brianp/build3/mesa/build/src/intel/compiler/intel_clc -p dg2 --prefix gfx125_bvh_build_BFS_BFS_pass1_indexed_batchable -e BFS_pass1_indexed_batchable --in ../src/intel/vulkan/grl/gpu/bvh_build_BFS.cl --in /home/brianp/build3/mesa/src/intel/vulkan/grl/gpu/libs/lsc_intrinsics_fallback.cl <http://lsc_intrinsics_fallback.cl> -o src/intel/vulkan/grl/gfx125_bvh_build_BFS_BFS_pass1_indexed_batchable.h -- -cl-std=cl2.0 -D__OPENCL_VERSION__=200 -DMAX_HW_SIMD_WIDTH=16 -DMAX_WORKGROUP_SIZE=16 -I/home/brianp/build3/mesa/src/intel/vulkan/grl/gpu -I/home/brianp/build3/mesa/src/intel/vulkan/grl/include ERROR: libclc shader missing. Consider installing the libclc package Aborted (core dumped) I've installed every clc-related package I could find. I've tried several options for the 'intel-clc' option without luck. BTW, the description of intel-clc in meson_options.txt looks suspect: option( 'intel-clc', type : 'combo', deprecated: {'true': 'enabled', 'false': 'disabled'}, value : 'disabled', choices : [ 'enabled', 'disabled', 'system', ], description : 'Build the intel-clc compiler (enables Vulkan Intel ' + 'Ray Tracing on supported hardware).' ) The default is 'disabled' but that's deprecated? Choices include 'enabled' but that's deprecated too? Any tips for building the ToT Intel Vulkan driver? -Brian -- This electronic communication and the information and any files transmitted with it, or attached to it, are confidential and are intended solely for the use of the individual or entity to whom it is addressed and may contain information that is confidential, legally privileged, protected by privacy laws, or otherwise restricted from disclosure to anyone else. If you are not the intended recipient or the person responsible for delivering the e-mail to the intended recipient, you are hereby notified that any use, copying, distributing, dissemination, forwarding, printing, or copying of this e-mail is strictly prohibited. If you received this e-mail in error, please return the e-mail to the sender, delete it from your computer, and destroy any printed copy of it. -- This electronic communication and the information and any files transmitted with it, or attached to it, are confidential and are intended solely for the use of the individual or entity to whom it is addressed and may contain information that is confidential, legally privileged, protected by privacy laws, or otherwise restricted from disclosure to anyone else. If you are not the intended recipient or the person responsible for delivering the e-mail to the intended recipient, you are hereby notified that any use, copying, distributing, dissemination, forwarding, printing, or copying of this e-mail is strictly prohibited. If you received this e-mail in error, please return the e-mail to the sender, delete it from your computer, and destroy any printed copy of it.
Intel clc dependency
I'm trying to build the Intel Vulkan driver. First time in a few months. I'm having build problems related to clc. I'm on Ubuntu 22.04 [...] [1347/3181] Generating src/intel/vulkan/...om command (wrapped by meson to set env) FAILED: src/intel/vulkan/grl/gfx125_bvh_build_BFS_BFS_pass1_indexed_batchable.h env MESA_SHADER_CACHE_DISABLE=true MESA_SPIRV_LOG_LEVEL=error /home/brianp/build3/mesa/build/src/intel/compiler/intel_clc -p dg2 --prefix gfx125_bvh_build_BFS_BFS_pass1_indexed_batchable -e BFS_pass1_indexed_batchable --in ../src/intel/vulkan/grl/gpu/bvh_build_BFS.cl --in /home/brianp/build3/mesa/src/intel/vulkan/grl/gpu/libs/lsc_intrinsics_fallback.cl -o src/intel/vulkan/grl/gfx125_bvh_build_BFS_BFS_pass1_indexed_batchable.h -- -cl-std=cl2.0 -D__OPENCL_VERSION__=200 -DMAX_HW_SIMD_WIDTH=16 -DMAX_WORKGROUP_SIZE=16 -I/home/brianp/build3/mesa/src/intel/vulkan/grl/gpu -I/home/brianp/build3/mesa/src/intel/vulkan/grl/include ERROR: libclc shader missing. Consider installing the libclc package Aborted (core dumped) I've installed every clc-related package I could find. I've tried several options for the 'intel-clc' option without luck. BTW, the description of intel-clc in meson_options.txt looks suspect: option( 'intel-clc', type : 'combo', deprecated: {'true': 'enabled', 'false': 'disabled'}, value : 'disabled', choices : [ 'enabled', 'disabled', 'system', ], description : 'Build the intel-clc compiler (enables Vulkan Intel ' + 'Ray Tracing on supported hardware).' ) The default is 'disabled' but that's deprecated? Choices include 'enabled' but that's deprecated too? Any tips for building the ToT Intel Vulkan driver? -Brian -- This electronic communication and the information and any files transmitted with it, or attached to it, are confidential and are intended solely for the use of the individual or entity to whom it is addressed and may contain information that is confidential, legally privileged, protected by privacy laws, or otherwise restricted from disclosure to anyone else. If you are not the intended recipient or the person responsible for delivering the e-mail to the intended recipient, you are hereby notified that any use, copying, distributing, dissemination, forwarding, printing, or copying of this e-mail is strictly prohibited. If you received this e-mail in error, please return the e-mail to the sender, delete it from your computer, and destroy any printed copy of it.
Re: Porting / AMIGA / PiStorm32 / developer needed - Back to the roots
On 4/12/23 02:30, Ignacio Soriano Hernandez wrote: !! External Email Dear Mesa dev community, Please let me apologize if you consider this off topic but I think that this is probably the audience that could help in reviving and getting back to the roots where Mesa3D originated from. To use Brian Paul’s words: The core library was originally (started in 1993) written on an Amiga using the DCC compiler. Later, development was moved to an SGI workstation. Current development is done on PC/Linux systems. Hard to believe it's been 30 years! So thirty years later the AMIGA community is still huge, growing and the development on hardware and software accelerators is giving us new capabilities. One of the most interesting projects has been the PiStorm32 and Emu68 which enable the AMIGA to use a Pi as CPU accelerator with a baremetal ARM <-> 68k CPU emulator. Incredible CPU power but no access to the GPU and acceleration that could also boost graphics capabilities and applications via an RTG (Retargetable Graphics) access. The AMIGA OS is actively being developed (yes, still 40 years later) and AMIGA cross-compiler toolchains do exist for all kind of nowadays operating systems. So what are we looking for? An experienced Mesa3D developer with and affinity/background for/on AMIGA that would be interested in porting an actual Mesa3D build to the PiStorm32/Emu68/AMIGA OS combo. Yes, 30 years later where it originated from. We have been collecting some funds as we know that this is not a weekend job but maybe someone is looking to for a challenge where „this is impossible“ gains your interest. I'm not familiar with PiStorm32/Emu68 but the first big issue may be that Mesa makes pervasive use of 64-bit datatypes (int64_t, uint64_t). Just from its name, PiStorm32/Emu68 sounds like a 32-bit environment. So unless your compiler has good support for emulating 64-bit types with 32-bit operations, you may be out of luck. -Brian
Re: [Mesa-dev] Mesa (master): lavapipe: bump maxMemoryAllocationCount
On 3/17/21 6:12 PM, GitLab Mirror wrote: Module: Mesa Branch: master Commit: 23100f3b6531d7055ae4d42e07bda09d991ea438 URL: https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcgit.freedesktop.org%2Fmesa%2Fmesa%2Fcommit%2F%3Fid%3D23100f3b6531d7055ae4d42e07bda09d991ea438data=04%7C01%7Cbrianp%40vmware.com%7Cd05b2a74f4bd48bf385208d8e9a28db1%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C1%7C0%7C637516231677082505%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=d3Ypjgh4TYqFsQDUbFCY956sLSv1hpqG4NP2OwP4it4%3Dreserved=0 Author: Dave Airlie Date: Wed Mar 17 13:33:14 2021 +1000 lavapipe: bump maxMemoryAllocationCount not sure why this was so low 4096 is the minimum maximum that Vulkan supports. I believe that's what Nvidia and AMD's Windows Vulkan drivers say. If you want your Vulkan app to be really cross-platform it's a limit to be aware of. -Brian Reviewed-By: Mike Blumenkrantz Reviewed-by: Adam Jackson Part-of: <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.freedesktop.org%2Fmesa%2Fmesa%2F-%2Fmerge_requests%2F9644data=04%7C01%7Cbrianp%40vmware.com%7Cd05b2a74f4bd48bf385208d8e9a28db1%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C1%7C0%7C637516231677082505%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=uzbWE3%2FG6AupVIc0kOYl8n5XcKw%2FcufKmK3tDEzhTyE%3Dreserved=0> --- src/gallium/frontends/lavapipe/lvp_device.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/gallium/frontends/lavapipe/lvp_device.c b/src/gallium/frontends/lavapipe/lvp_device.c index 61edf15dd0a..b087e2a7d68 100644 --- a/src/gallium/frontends/lavapipe/lvp_device.c +++ b/src/gallium/frontends/lavapipe/lvp_device.c @@ -574,7 +574,7 @@ VKAPI_ATTR void VKAPI_CALL lvp_GetPhysicalDeviceProperties(VkPhysicalDevice phys .maxUniformBufferRange= pdevice->pscreen->get_shader_param(pdevice->pscreen, PIPE_SHADER_FRAGMENT, PIPE_SHADER_CAP_MAX_CONST_BUFFER_SIZE), .maxStorageBufferRange= pdevice->pscreen->get_param(pdevice->pscreen, PIPE_CAP_MAX_SHADER_BUFFER_SIZE), .maxPushConstantsSize = MAX_PUSH_CONSTANTS_SIZE, - .maxMemoryAllocationCount = 4096, + .maxMemoryAllocationCount = UINT32_MAX, .maxSamplerAllocationCount= 32 * 1024, .bufferImageGranularity = 64, /* A cache line */ .sparseAddressSpaceSize = 0, ___ mesa-commit mailing list mesa-com...@lists.freedesktop.org https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Fmesa-commitdata=04%7C01%7Cbrianp%40vmware.com%7Cd05b2a74f4bd48bf385208d8e9a28db1%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C1%7C0%7C637516231677082505%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=j0T9KnefIkBponHxMLxgKi8xBIMHYAydsEWV9ESBsSQ%3Dreserved=0 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] Fwd: [Mesa-users] Surfaceless mesa 20.3.X?
Forwarding to mesa-dev where you may get more help. There was talk of changing software rendering but I'm not sure what's changed. What version of Mesa are you using? -Brian Forwarded Message Subject:[Mesa-users] Surfaceless mesa 20.3.X? Date: Wed, 27 Jan 2021 09:59:03 +0100 From: Sophonet To: mesa-us...@lists.freedesktop.org Hi list, I would like to compile mesa for a surfaceless system (server, software rendering, no GPU). This was possible earlier with the „surfaceless“ platform. The recent versions do not allow surfaceless as a platform option anymore. The build info which is listed for building osmesa (https://docs.mesa3d.org/osmesa.html) does not list a platform, and in that case, wayland is required, which is not available on our server. I could build osMesa with the x11 platform, but rendering does not work if there is no (remote) X connection (DISPLAY missing etc.). What is the recommended approach now? Thanks, sophonet ___ mesa-users mailing list mesa-us...@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-users ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] Fwd: [Mesa-users] Issues with removal of classic OSMesa
Hi Andreas, I'm forwarding your message to the mesa-dev list for better visibility. BTW, when you say "antialiasing" below, what exactly do you mean? -Brian Forwarded Message Subject:[Mesa-users] Issues with removal of classic OSMesa Date: Thu, 31 Dec 2020 12:56:04 +0100 From: Andreas Fänger To: mesa-us...@lists.freedesktop.org Hi, I've just seen that classic OSMesa has been removed (again) from Mesa3D a few weeks ago with this commit "mesa: Retire classic OSMesa". We are still actively using classical OSMesa for high quality rendering of still images in a headless environment with no GPU support (server-based rendering on windows and linux) Unfortunately, none of the alternative software renderers provide all the features that we require, which is antialiasing and anisotropic filtering. The current state is (correct me if I'm wrong) * softpipe: anisotropic filtering is supported, no antialiasing * llvmpipe: no anisotropic filtering, has MSAA * openswr: no anisotropic filtering, has MSAA, no OSMesa interface (?) We had hoped that classical OSMesa is only removed when there is a full replacement after the discussions in 2016 when OSMesa was about to be removed for the first time https://lists.freedesktop.org/archives/mesa-dev/2016-March/109665.html https://lists.freedesktop.org/archives/mesa-users/2016-March/001132.html and the commit that reverted the removal http://cgit.freedesktop.org/mesa/mesa/commit/?id=9601815b4be886f4d92bf74916de98f3bdb7275c Are there any plans to enhance the renderers so that at least one of them is providing both anisotropic filtering and antialiasing? As far as I know, anisotropic texture filtering is also one of the OpenGL 4.6 requirements. In 2016 I was told that there are only very few developers involved in llvmpipe and that chances are not high that someone is going to port the softpipe anisotropic filtering implementation as llvmpipe is much more complex. Is there any change in that situation? If there are no such plans, is there any chance of reverting this commit again so that classical OSMesa is available for windows and linux in mesa >20? Regards, Andreas Fänger ___ mesa-users mailing list mesa-us...@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-users ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] GLSLstd450NMin/NMax/NClamp
On 11/17/2020 01:59 PM, Brian Paul wrote: On 11/17/2020 11:45 AM, Ian Romanick wrote: On 11/17/20 9:25 AM, Brian Paul wrote: It appears these SPIR-V extension functions don't behave as they should on Intel (don't know about other Vulkan drivers). They're supposed to be NaN-aware such that if one argument is NaN, the other argument is returned. From our testing, it looks like NMax works as expected, but not NMin or NClamp. Do you have some specific test cases that fail? Yeah, but they come from WHCK and I don't have a small test case. I'll try your patch series and see what happens. -Brian I'm using your patch and I'm also making use of VK_KHR_shader_float_control but neither has helped. Though, the later does help with some issues in Nvidia. -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] SpvOpSelect w/ float operands
On 11/18/2020 02:49 AM, Connor Abbott wrote: On Tue, Nov 17, 2020 at 9:56 PM Brian Paul wrote: On 11/17/2020 11:49 AM, Ian Romanick wrote: On 11/17/20 9:25 AM, Brian Paul wrote: Using the Intel Vulkan driver, we've found some cases where SpvOpSelect is returning -0.0 (negative zeros) instead of normal 0.0 depending on the arguments. Do you have a specific test case that fails? Yeah, but as with the NMin/NMax issue it's not a simple test case. It comes from a Windows WHCK test suite. It seems like on some platforms there was an errata about the version of the SEL instruction that is used for min or max that can return the wrong signed zero in some cases. It's also possible that some optimizations are causing problems. I don't remember exactly how it works in SPIR-V, but does marking those SPIR-V instructions as precise (that's what it was in GLSL) make a difference? AFAIK, there's only a SPIR-V decoration for tagging things for relaxed precision. The SPIR-V equivalent of "precise" is NoContract. But for emulating DX stuff you're supposed to use KHR_shader_float_controls which was specifically designed for emulating DX floating-point requirements. In NIR that just marks everything as "exact" if you force correct NaN/signed zero/Inf handling. Thanks for the tip! I'll take a look at that. -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] fp/int64 on gen11/12?
Another Intel question: It looks like gen11/gen12 don't have fp/int64 enabled in the Vulkan driver. From gen_device_info.c: #define GEN11_FEATURES(_gt, _slices, _subslices, _l3) \ GEN8_FEATURES, \ GEN11_HW_INFO, \ .has_64bit_float = false, \ .has_64bit_int = false, ... #define GEN12_FEATURES(_gt, _slices, _l3) \ GEN8_FEATURES, \ GEN12_HW_INFO, \ .has_64bit_float = false,\ .has_64bit_int = false, But gen8/9 do support it. Is this a driver and/or hardware issue? -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] GLSLstd450NMin/NMax/NClamp
On 11/17/2020 11:45 AM, Ian Romanick wrote: On 11/17/20 9:25 AM, Brian Paul wrote: It appears these SPIR-V extension functions don't behave as they should on Intel (don't know about other Vulkan drivers). They're supposed to be NaN-aware such that if one argument is NaN, the other argument is returned. From our testing, it looks like NMax works as expected, but not NMin or NClamp. Do you have some specific test cases that fail? Yeah, but they come from WHCK and I don't have a small test case. I'll try your patch series and see what happens. -Brian Looking at the SPIR-V/nir/intel code it's hard to tell what's going on and whether these semantics are actually being followed. Any comments? -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Fmesa-devdata=04%7C01%7Cbrianp%40vmware.com%7Ca9f0c2e6cfa846f3b20408d88b28f40d%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637412355305449546%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=dWV4%2Bsq4B7xBiCxRmyTj7zM4b2Xfl%2BLjtdll6qHhUAg%3Dreserved=0 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] SpvOpSelect w/ float operands
On 11/17/2020 11:49 AM, Ian Romanick wrote: On 11/17/20 9:25 AM, Brian Paul wrote: Using the Intel Vulkan driver, we've found some cases where SpvOpSelect is returning -0.0 (negative zeros) instead of normal 0.0 depending on the arguments. Do you have a specific test case that fails? Yeah, but as with the NMin/NMax issue it's not a simple test case. It comes from a Windows WHCK test suite. It seems like on some platforms there was an errata about the version of the SEL instruction that is used for min or max that can return the wrong signed zero in some cases. It's also possible that some optimizations are causing problems. I don't remember exactly how it works in SPIR-V, but does marking those SPIR-V instructions as precise (that's what it was in GLSL) make a difference? AFAIK, there's only a SPIR-V decoration for tagging things for relaxed precision. -Brian I'm wondering if "SpvOpSelect x, a, b" for floats is being implemented with something like "a*x + b*(1-x)" ? That might explain where the negative zeros are coming from. Our work-around is to implement selection with bitwise operations: (a & x) | (b & ~x) It seems to me that SpvOpSelect shouldn't interpret the bits and just return an exact copy of the argument. -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Fmesa-devdata=04%7C01%7Cbrianp%40vmware.com%7C5e1ffabf0f7c47a2f48308d88b298304%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637412357691565798%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=SdzrOYvGGFraVg61OGvIQ6NJrT2i7fye%2Fy03XoZOi7E%3Dreserved=0 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] SpvOpSelect w/ float operands
Using the Intel Vulkan driver, we've found some cases where SpvOpSelect is returning -0.0 (negative zeros) instead of normal 0.0 depending on the arguments. I'm wondering if "SpvOpSelect x, a, b" for floats is being implemented with something like "a*x + b*(1-x)" ? That might explain where the negative zeros are coming from. Our work-around is to implement selection with bitwise operations: (a & x) | (b & ~x) It seems to me that SpvOpSelect shouldn't interpret the bits and just return an exact copy of the argument. -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] GLSLstd450NMin/NMax/NClamp
It appears these SPIR-V extension functions don't behave as they should on Intel (don't know about other Vulkan drivers). They're supposed to be NaN-aware such that if one argument is NaN, the other argument is returned. From our testing, it looks like NMax works as expected, but not NMin or NClamp. Looking at the SPIR-V/nir/intel code it's hard to tell what's going on and whether these semantics are actually being followed. Any comments? -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] llvmpipe is OpenGL 4.5 conformant.
Nice work! It's good to see llvmpipe being maintained and improved like that. -Brian On 10/30/2020 02:24 PM, Dave Airlie wrote: Just to let everyone know, a month ago I submitted the 20.2 llvmpipe driver for OpenGL 4.5 conformance under the SPI/X.org umbrella, and it is now official[1]. Thanks to everyone who helped me drive this forward, and to all the contributors both to llvmpipe and the general Mesa stack that enabled this. Big shout out to Roland Scheidegger for helping review the mountain of patches I produced in this effort. My next plans involved submitting lavapipe for Vulkan 1.0, it's at 99% or so CTS, but there are line drawing, sampler accuracy and some snorm blending failure I have to work out. I also ran the OpenCL 3.0 conformance suite against clover/llvmpipe yesterday and have some vague hopes of driving that to some sort of completion. (for GL 4.6 only texture anisotropy is really missing, I've got patches for SPIR-V support, in case someone was feeling adventurous). Dave. [1] https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.khronos.org%2Fconformance%2Fadopters%2Fconformant-products%2Fopengl%23submission_272data=04%7C01%7Cbrianp%40vmware.com%7C9869322310dc466d3a6108d87d11db3a%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637396862939563580%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=3veHyDPNBvaJjOnvFRdg%2FGtkk3IZuvTFgDxYA3ihONE%3Dreserved=0 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Fmesa-devdata=04%7C01%7Cbrianp%40vmware.com%7C9869322310dc466d3a6108d87d11db3a%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637396862939563580%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=2KyGMO5H%2FodTRaQAxEJlNiVa2HOUkKUKim1sIXBWGUI%3Dreserved=0 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Gallium interface rename proposals
This all sounds find to me, FWIW. -Brian On 09/19/2020 04:24 AM, Marek Olšák wrote: Hi, I don't know if you have been following gitlab, but there are a few cleanups that I have been considering doing. Rename PIPE_TRANSFER flags to PIPE_MAP, and pipe_transfer_usage to pipe_map_flags: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5749 <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.freedesktop.org%2Fmesa%2Fmesa%2F-%2Fmerge_requests%2F5749=02%7C01%7Cbrianp%40vmware.com%7Cbedfd0817f704e06e75808d85c863fb3%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637361078970577405=7Nyd8ufSCAfWo1kBYPE%2Fta7aOKy1p%2BZ529GcejP4keY%3D=0> Other proposed renames: transfer_map -> resource_map transfer_unmap -> resource_unmap transfer_flush_region -> resource_flush_mapped_range draw_vbo -> draw pipe_transfer_* aux helpers -> pipe_resource_* or pipe_texture_* depending on context. We already have pipe_buffer_map. I'm inclined to keep the struct pipe_transfer name unchanged to indicate that mappings can cause internal copies. Please let me know your preferences. Thanks, Marek ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Fmesa-devdata=02%7C01%7Cbrianp%40vmware.com%7Cbedfd0817f704e06e75808d85c863fb3%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637361078970597391sdata=qI2%2BFMvRDEIePjAOjbGVwCOusUxyw6I1wwL7fJb%2Blgs%3Dreserved=0 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] New Mesa3D.org website proposal
On Sun, Jun 14, 2020 at 9:28 AM Daniel Stone wrote: > Hi, > > On Fri, 29 May 2020 at 10:08, Erik Faye-Lund > wrote: > > In the light of the explanation above, do you still have objections to > > this split? > > > > Obviously, we haven't moved forward yet ;-) > > Well, we have now after getting some agreement. Please enjoy your > shiny new https://www.mesa3d.org and https://docs.mesa3d.org > experience. > > Brian, could you please change the DNS for mesa3d.org and > www.mesa3d.org to point to 35.227.58.183? No need to change > archive.mesa3d.org, that should still point to the old site. > Done (may take 3 hours to go into effect). -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] New Mesa3D.org website proposal
On 05/13/2020 03:13 AM, Erik Faye-Lund wrote: On Tue, 2020-05-12 at 12:17 +0200, Erik Faye-Lund wrote: On Thu, 2020-05-07 at 11:03 -0600, Brian Paul wrote: On 05/07/2020 04:33 AM, Erik Faye-Lund wrote: Hey Brian TLDR; are you OK with me moving forward with the rework of mesa3d.org? Yes... Cool! We've now set up a repo here: https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.freedesktop.org%2Fmesa%2Fmesa3d.orgdata=02%7C01%7Cbrianp%40vmware.com%7Cb8ff6d838d46414812f208d7f71df219%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637249580306260765sdata=CLd07g8WPm7mbsa3033pnhycK25xPD5%2Bi00V0MJ6TIY%3Dreserved=0 I pushed the bare minimum (ish) there so far, and sent a MR for the importing of the news and article-redirects. This is now being served here: https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmesa.pages.freedesktop.org%2Fmesa3d.org%2Fdata=02%7C01%7Cbrianp%40vmware.com%7Cb8ff6d838d46414812f208d7f71df219%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637249580306260765sdata=GmaivI1wH4HR6osRoP%2FINlJm%2FgZ6tgb8HsE1ElVhZNE%3Dreserved=0 A few updates: 1. You can now preview the repo with the pending MRs merged here, if you're interested: https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fkusma.pages.freedesktop.org%2Fmesa3d.org%2Fdata=02%7C01%7Cbrianp%40vmware.com%7Cb8ff6d838d46414812f208d7f71df219%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637249580306260765sdata=U7cC71x9ql%2FCNXpdNxO2%2But3NAVzDo6S91%2BmevJjMsc%3Dreserved=0 2. Some people have been asking me why the website is set up as a separate repo rather than a subdirectory inside the main mesa repo. The quick answer to that is that it seemed more logical that way to me. The website isn't really tied to the mesa release-schedule, apart from linking to new releases. It's really its own thing. We might for instance want to post updates when other projects in the mesa-group cuts a release. So this seems to give us some more freedom. If someone has good arguments against this, I'm open to changing it. But this seems like the best option to me. I'd really like to keep the Mesa content as part of the main Mesa repo. I didn't realize you did that. The website is part of the project and it's more convenient to have it all in one place. -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] New Mesa3D.org website proposal
On Tue, May 12, 2020 at 4:04 AM Daniel Stone wrote: > Hi Brian, > > On Fri, 8 May 2020 at 15:30, Brian Paul wrote: > > Done. easydns says it may take up to 3 hours to go into effect. > > Thanks for doing this! Could you please add the following TXT records > as well (note that they're FQDN, so you might want to chop the > trailing '.mesa3d.org' from the first segment: > _gitlab-pages-verification-code.mesa3d.org TXT > gitlab-pages-verification-code=e8a33eb47c034b08afd339cb3a801d88 > _gitlab-pages-verification-code.www.mesa3d.org TXT > gitlab-pages-verification-code=28d457c44c75d4a1e460243ded2b4311 > _gitlab-pages-verification-code.docs.mesa3d.org TXT > gitlab-pages-verification-code=6045fd12252cc01f5891fa3f81b140fe > Done. -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] RFC: Memory allocation on Mesa
in thousands of places in Mesa/gallium and touching all of them seems like a hard way to go - maybe not so much technical as people just not liking it for various reasons. I prototyped a u_trackmem.h header with u_trackmem_malloc(), functions, etc. That header also does "#define malloc dont_call_malloc_here" to try to prevent use of malloc/free in the .c code. u_trackmem.h would typically have to be the last #include in a .c file. I think redefining malloc/free in the .h file is better than the -D compiler option because as soon as we include a .h file which uses malloc/free we get a big mess. u_trackmem.h attached. -Brian /** * * Copyright 2020 VMware, Inc. * All Rights Reserved. * * Permission is hereby granted, free of charge, to any person obtaining a * copy of this software and associated documentation files (the * "Software"), to deal in the Software without restriction, including * without limitation the rights to use, copy, modify, merge, publish, * distribute, sub license, and/or sell copies of the Software, and to * permit persons to whom the Software is furnished to do so, subject to * the following conditions: * * The above copyright notice and this permission notice (including the * next paragraph) shall be included in all copies or substantial portions * of the Software. * * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS * OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. * IN NO EVENT SHALL VMWARE AND/OR ITS SUPPLIERS BE LIABLE FOR * ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, * TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE * SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. * **/ /* * Functions for tracking memory usage. * * Some modules, like LLVMpipe, need memory tracking (how much memory is used) * in some applications (VMware). * * Where memory tracking might be needed, use these functions instead of * regular malloc/free. These functions may simply be implemented with * * When memo */ #ifndef U_TRACKMEM_H #define U_TRACKMEM_H #include // for size_t /* * These are the tracked memory functions. We may plug in conventional * malloc, free, etc. or special tracking/debug functions. */ struct u_trackmem_funcs { void *(*malloc_fn)(size_t size); void *(*calloc_fn)(size_t num, size_t size); void *(*realloc_fn)(void *ptr, size_t size); void (*free_fn)(void *p); void *(*align_malloc_fn)(size_t size, size_t alignment); void *(*align_calloc_fn)(size_t size, size_t alignment); void *(*align_realloc_fn)(void *p, size_t oldsize, size_t newsize, size_t alignment); void (*align_free_fn)(void *p); void *(*memdup_fn)(void *src, size_t size); }; /* * Clients of trackmem do malloc/free with: *foo = u_trackmem.malloc(16); *u_trackmem.free(foo); * etc. */ extern struct u_trackmem_funcs u_trackmem; /* Plug in alternate allocation funcs */ extern void u_trackmem_init(const struct u_trackmem_funcs *funcs); #if 0 // in the .c file: { if (funcs) { u_trackmem = *funcs; } else { /* plug in defaults */ u_trackmem.malloc_fn = malloc; u_trackmem.calloc_fn = calloc; u_trackmem.realloc_fn = realloc; u_trackmem.free_fn = free; u_trackmem.align_malloc_fn = align_malloc; u_trackmem.align_calloc_fn = align_calloc; u_trackmem.align_realloc_fn = align_realloc; u_trackmem.align_free_fn = align_free; u_trackmem.memdup_fn = memdup; } } #endif static inline void * u_trackmem_malloc(size_t size) { return u_trackmem.malloc_fn(size); } static inline void * u_trackmem_calloc(size_t num, size_t size) { return u_trackmem.calloc_fn(num, size); } static inline void * u_trackmem_realloc(void *ptr, size_t size) { return u_trackmem.realloc_fn(ptr, size); } static inline void u_trackmem_free(void *p) { u_trackmem.free_fn(p); } static inline void * u_trackmem_align_malloc(size_t size, size_t alignment) { return u_trackmem.align_malloc_fn(size, alignment); } static inline void * u_trackmem_align_calloc(size_t size, size_t alignment) { return u_trackmem.align_calloc_fn(size, alignment); } static inline void u_trackmem_align_free(void *p) { return u_trackmem.align_free_fn(p); } static inline void * u_trackmem_align_realloc(void *p, size_t oldsize, size_t newsize, size_t alignment) { return u_trackmem.align_realloc_fn(p, oldsize, newsize, alignment); } /* Helper funcs */ #define U_TRACKMEM_MALLOC_STRUCT(T) (struct T *) u_trackmem_malloc(sizeof(struct T)) #define U_TRACKMEM_CALLOC_STRUCT(T) (struct T *) u_trackmem_calloc(1, sizeo
Re: [Mesa-dev] New Mesa3D.org website proposal
On Thu, May 7, 2020 at 12:16 PM Brian Paul wrote: > On 05/07/2020 11:35 AM, Daniel Stone wrote: > > Hi, > > > > On Thu, 7 May 2020 at 18:08, Erik Faye-Lund > > wrote: > >> On Thu, 2020-05-07 at 11:03 -0600, Brian Paul wrote: > >>> It seems like only the front page is served at the moment. Is it > >>> possible to get a look at the rest? The front page looks nice. > >> > >> Yeah, we need to set up docs.mesa3d.org first. I haven't bothered > >> setting up the temporary URLs yet, but my current preview is hosted > >> here: > > > > After the nginx infrastructure work over the past few weeks, we can > > now actually set up redirects. So I think the better thing would be to > > assume this will be > https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.mesa3d.org%2Fdata=02%7C01%7Cbrianp%40vmware.com%7Cca45e2189c2847b0630f08d7f2ad385c%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637244698116403831sdata=2WRscmbHCqteoeEcy010Zg%2FxSPXfaoyfwr9MzEOdTL0%3Dreserved=0 > hosted on Pages, then have > > redirects over for tarball downloads. > > > > Brian, could you please add a DNS entry for archive.mesa3d.org as a > > CNAME to annarchy.freedesktop.org, and docs.mesa3d.org as a CNAME to > > gitlab.freedesktop.org? If you can do that, I'll get the archive > > hosting set up separately, then when we're ready we can cut over > > > https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.mesa3d.org%2Fdata=02%7C01%7Cbrianp%40vmware.com%7Cca45e2189c2847b0630f08d7f2ad385c%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637244698116403831sdata=2WRscmbHCqteoeEcy010Zg%2FxSPXfaoyfwr9MzEOdTL0%3Dreserved=0 > and mesa3d.org to Pages. > > Ok, I'll try to do this asap, but it may be 24 hours. > Done. easydns says it may take up to 3 hours to go into effect. -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] New Mesa3D.org website proposal
On 05/07/2020 11:35 AM, Daniel Stone wrote: Hi, On Thu, 7 May 2020 at 18:08, Erik Faye-Lund wrote: On Thu, 2020-05-07 at 11:03 -0600, Brian Paul wrote: It seems like only the front page is served at the moment. Is it possible to get a look at the rest? The front page looks nice. Yeah, we need to set up docs.mesa3d.org first. I haven't bothered setting up the temporary URLs yet, but my current preview is hosted here: After the nginx infrastructure work over the past few weeks, we can now actually set up redirects. So I think the better thing would be to assume this will be https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.mesa3d.org%2Fdata=02%7C01%7Cbrianp%40vmware.com%7Cca45e2189c2847b0630f08d7f2ad385c%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637244698116403831sdata=2WRscmbHCqteoeEcy010Zg%2FxSPXfaoyfwr9MzEOdTL0%3Dreserved=0 hosted on Pages, then have redirects over for tarball downloads. Brian, could you please add a DNS entry for archive.mesa3d.org as a CNAME to annarchy.freedesktop.org, and docs.mesa3d.org as a CNAME to gitlab.freedesktop.org? If you can do that, I'll get the archive hosting set up separately, then when we're ready we can cut over https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.mesa3d.org%2Fdata=02%7C01%7Cbrianp%40vmware.com%7Cca45e2189c2847b0630f08d7f2ad385c%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637244698116403831sdata=2WRscmbHCqteoeEcy010Zg%2FxSPXfaoyfwr9MzEOdTL0%3Dreserved=0 and mesa3d.org to Pages. Ok, I'll try to do this asap, but it may be 24 hours. -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] New Mesa3D.org website proposal
On 05/07/2020 04:33 AM, Erik Faye-Lund wrote: Hey Brian TLDR; are you OK with me moving forward with the rework of mesa3d.org? Yes... (BTW, sorry about the URL mangling below) As you hopefully are aware of, I've been working on a new website for mesa3d.org, split into a "marketing"-frontpage and a documentation page. You can read more about the structure and details here if you haven't already: https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.freedesktop.org%2Fmesa%2Fmesa%2F-%2Fmerge_requests%2F4630data=02%7C01%7Cbrianp%40vmware.com%7C6998774738b349bcb79108d7f2720ca6%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C63723970864799sdata=1Z%2B3KKoVjNLHRvIf2VbK7KHSM4kh10fZQ1zdfPsguA0%3Dreserved=0 That MR only deals with the marketing website, so I think it's time to talk more about the main website. What I currently have is located here: https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.freedesktop.org%2Fkusma%2Fkusma.pages.freedesktop.org%2Fdata=02%7C01%7Cbrianp%40vmware.com%7C6998774738b349bcb79108d7f2720ca6%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C63723970864799sdata=ttMgZuWT%2Bgg19H9qx1XmUQgl%2FO%2FlFF3vZuGkKxQGC9g%3Dreserved=0 This builds on CI and currently gets served here: https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fkusma.pages.freedesktop.org%2Fdata=02%7C01%7Cbrianp%40vmware.com%7C6998774738b349bcb79108d7f2720ca6%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C63723970864799sdata=258fUaF1DrIioGS1VTROkJznMNjI3xhxmbdl9RWyJZU%3Dreserved=0 It seems like only the front page is served at the moment. Is it possible to get a look at the rest? The front page looks nice. Since last time I published any details about this, I've: 1. Switched the static-site-generator from Jekyll to Hugo. This lead to a build-time decrease from about two minutes to about 200ms on my machine. This makes iteration times a lot more bearable. 2. Back-paddled on moving some pages. I think we can hold off on moving pages to the website until the initial work lands. 3. Gotten approval from the Khronos marketing team about the usage of their logos / trademarks. They had some minor requests for changes, which has been taken into account. The news articles and redirects for URL compatibility is converted from a branch in my Mesa fork, here: https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.freedesktop.org%2Fkusma%2Fmesa%2F-%2Ftree%2Fdocs-convert-news-hugodata=02%7C01%7Cbrianp%40vmware.com%7C6998774738b349bcb79108d7f2720ca6%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C63723970864799sdata=rmXuKgyMFAZqJD4ij%2F8mR1EvA4HvFYwnR5Gd%2BCdgJFM%3Dreserved=0 So, after a long introduction (sorry if a lot of this is stuff you already know), what I really want is for you Brian, as the project originator and listed webmaster, to say how you feel about all of this. Please remove me as the webmaster. I still occasionally get emails from that. Let readers know how to submit changes/edits. If you're happy to move forward with this, I will start the technical discussions with the FDO admins and other people who might need to be involved in setting this up for production. Yeah, go ahead. Sorry for not monitoring this work. I basically have zero time for Mesa nowadays. -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] Windows build broken
by: commit f8f1413070ae079443ab31a75679cfd10cb756ed Author: Pierre-Eric Pelloux-Prayer Date: Mon Mar 16 10:49:17 2020 +0100 util/u_process: add util_get_process_exec_path Reviewed-by: Marek Olšák Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4181> scons: Building targets ... Compiling src\gallium\auxiliary\driver_ddebug\dd_draw.c ... dd_draw.c Compiling src\gallium\auxiliary\os\os_process.c ... os_process.c Compiling src\util\os_file.c ... os_file.c Compiling src\util\u_process.c ... u_process.c Compiling src\util\u_queue.c ... src\util\u_process.c(34): fatal error C1083: Cannot open include file: 'unistd.h': No such file or directory The #include of unistd.h should probably be moved into the later #if DETECT_OS_WINDOWS block. -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Drop scons for 20.1?
I'm on vacation this week. When I get back next week we'll talk about this again at VMware. Unfortunately, integrating a new build tool into our infrastructure here can be pretty difficult. But I totally understand the appeal of getting rid of SCons. Please hold on a bit... -Brian On Wed, Feb 26, 2020 at 2:04 PM Kristian Høgsberg wrote: > On Wed, Feb 26, 2020 at 12:16 PM Jose Fonseca wrote: > > > > > but it bothers me how we keep not making a decision on this. If we'd > said, "let's keep it and support it", that would something. > > > > I'm surprised there's any doubt. > > > > SCons works great for us. Meson gives no immediate benefit for us > other than headaches. If we cared about nothing but ourselves, we'd keep > SCons indefinitely, until it became a pain. > > > > The only reason we don't stubbornly put the foot down is that we > understand that having one single build system would be beneficial the > whole community, and of course we appreciate all the work Dylan and others > did to get Meson to work on Windows, so we'd like to get there one day. > > > > That said, I don't understand why the rest of the Mesa community putting > a gun against our head to abandon SCons. > > > > Aren't we maintaining the SCons build? Since when in Mesa community are > some entitled to start remove code that still works, is used, and > maintained by others > > Nobody is entitled to remove the code, that's why we're having this > discussion. And I bet it's frustrating for you to have to deal with > this again and again, but on the other side, it's frustrating to see > this issue come up again and again with no evident progress > whatsoever. What has happened on your side since the last time this > was discussed? When is that "one day"? How are we supposed to move > this forward without bringing it up? > > As for removing code that works - we do that All. The. Time. We > refactor subsystems, IRs, entire drivers get rewritten and replace the > working code that was there before, in order the lower the maintenance > burden, run across more platforms, shader a compiler pass, reduce > techincal debt etc. > > Kristian > > > > > Jose > > > > > > From: Kristian Høgsberg > > Sent: Wednesday, February 26, 2020 18:37 > > To: Jason Ekstrand > > Cc: Rob Clark ; mesa-dev < > mesa-dev@lists.freedesktop.org>; Dylan Baker ; > Jose Fonseca ; Brian Paul > > Subject: Re: [Mesa-dev] Drop scons for 20.1? > > > > On Tue, Feb 25, 2020 at 8:15 PM Jason Ekstrand > wrote: > > > > > > +Jose & Brian > > > > > > I'm not personally opposed but I also can't remember the last time I > had to > > > fix the scons build. I think it's been years. Maybe that's because I > don't > > > work on GL anymore? In any case, I don't know that it's really costing > us > > > that much given that basically none of the drivers actually build with > it. > > > But fat meh, I guess. > > > > Maybe it is a bit meh... I did the MR to remove SCons and it's smaller > > that I thought it would be: > > > > > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.freedesktop.org%2Fmesa%2Fmesa%2F-%2Fmerge_requests%2F3955data=02%7C01%7Cjfonseca%40vmware.com%7C6b2e8f2abc98458d18ad08d7baeb0443%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637183390863817583sdata=96lM4flW9ja6fJG95nlNdmftNiYpajxpg0Il850%2FDLk%3Dreserved=0 > > > > but it bothers me how we keep not making a decision on this. If we'd > > said, "let's keep it and support it", that would something. But > > whenever it comes up, Dylan maybe fixes something on the windows > > build, we talk about trying to switch Windows to meson and then... > > nothing. > > > > Also, we've had this unfortunate split between Linux and Windows build > > systems where autotools suck on Windows and nobody on Unix ever had a > > reason to use SCons. With meson we've picked something that's a > > legitimate improvement on both sides, get's us back to one build > > system and done more than due dilligence to make it work on Windows > > and we're not taking the last step because... meh? > > > > Kristian > > > > > --Jason > > > > > > On February 25, 2020 21:56:30 Rob Clark wrote: > > > > > > > It looks like we have 4 scons build jobs in CI.. I'm not sure how > much > > > > that costs us, but I guess those cycles could be put to better use? > > > > So even ignoring the developer-cycles issue (ie. someone making > > &g
Re: [Mesa-dev] [Review Request (master branch)] svga: Use pipe_shader_state_from_tgsi to set shader state
I'm going to update the docs regarding patches and gitlab. It's kind of a mess now. -Brian On 02/11/2020 03:03 AM, Michel Dänzer wrote: Hi Charmaine, it looks like you pushed this patch and another one directly to the main Mesa repository master branch. Pushing directly to the main Mesa repository is no longer common practice, and indeed discouraged, as it circumvents the pre-merge GitLab CI pipeline and forfeits all other benefits of a merge request (MR). The common practice is to create an MR (normally already for patch review) and assign it to Marge Bot for merging. Marge will rebase as needed and merge once the pre-merge CI pipeline has passed. Thanks, On 2020-01-29 5:14 p.m., Neha Bhende wrote: Use pipe_shader_state_from_tgsi() to set shader state for transformed shader so that we get all correct data for respective shader state. This fixes several regressed glretrace, piglit crashes found during merging upsteam mesa Fixes: bf12bc2dd7a2 (draw: add nir info gathering and building support) Reviewed-by: Charmaine Lee --- src/gallium/drivers/svga/svga_state_tgsi_transform.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/gallium/drivers/svga/svga_state_tgsi_transform.c b/src/gallium/drivers/svga/svga_state_tgsi_transform.c index b567aab6bc8..9d701b73772 100644 --- a/src/gallium/drivers/svga/svga_state_tgsi_transform.c +++ b/src/gallium/drivers/svga/svga_state_tgsi_transform.c @@ -131,7 +131,7 @@ emulate_point_sprite(struct svga_context *svga, tgsi_dump(new_tokens, 0); } - templ.tokens = new_tokens; + pipe_shader_state_from_tgsi(, new_tokens); templ.stream_output.num_outputs = 0; if (streamout) { ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Is it time to stop using the mailing list for patch review?
On 12/11/2019 10:42 AM, Jason Ekstrand wrote: On Wed, Dec 11, 2019 at 11:33 AM Michel Dänzer <mailto:mic...@daenzer.net>> wrote: On 2019-12-11 5:47 p.m., Brian Paul wrote: > > I've had little time for Mesa work the past 18 months. That makes me sad, I hope you'll have more time again in the future. Between family life and VMware work, there's little left over. I'll be lurking if nothing else. > 1. I don't think the mesa-dev list should be shut down nor purged from > the documentation. Yeah, I don't think anybody seriously suggested the list should be shut down, just that GitLab is now preferred for patch submission & review. > Someone mentioned hardly reading the mailing list anymore. I still > haven't gotten into the habit of monitoring the MRs page... Instead of monitoring a web page, I recommend setting up notifications via the bell icon on https://gitlab.freedesktop.org/mesa/mesa <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.freedesktop.org%2Fmesa%2Fmesa=02%7C01%7Cbrianp%40vmware.com%7Cb98a969240530d4908d77e61906d%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637116829815378870=vENdTPXFgRswVXvIKNhfYf7G3msmOTYYcJ2MAvU%2BKxc%3D=0> [0]. If you select "Custom", you can select in detail which events you want to get notification e-mails for. Check "New merge request" to get an e-mail for each new MR created. Then you can either enable notifications for other MR events here as well, or enable all notifications for MRs you're interested in using the "Notifications" switch in the right hand panel on each MR's page. Thanks for the tip! That's the kind of thing that would be useful to document. You can also subscribe to specific labels which is what I've done. That way I get e-mails about anything going on in NIR or our Vulkan driver but don't have to see every nouveau MR. Are labels put on MRs automatically or does the person submitting have to do that manually? -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Is it time to stop using the mailing list for patch review?
On 12/09/2019 04:07 PM, Dylan Baker wrote: Hi everyone, I think its time we discussed whether we're going to continue to do patch review on the mailing list, or if it it should all go through gitlab. I think we should stop using the mailing list, here are some reasons: 1) Most development is happening on gitlab at this point, patches on the mailing list are often overlooked 2) The mailing list bypasses CI which potentially breaks the build 3) Probably more reasons I'm forgetting. I've had little time for Mesa work the past 18 months. But I'd say: 1. I don't think the mesa-dev list should be shut down nor purged from the documentation. 2. I think the complete workflow for submitting patches via gitlab MRs should be documented on the Mesa site. Being a gitlab newbie I wasted a lot of time a few months ago trying to figure out the details. Mesa's "Submitting Patches" page is kind of a mess. It would be great if someone could work on that. Someone mentioned hardly reading the mailing list anymore. I still haven't gotten into the habit of monitoring the MRs page... -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] util/atomic: Fix p_atomic_add for unlocked and msvc paths
Reviewed-by: Brian Paul On 12/09/2019 10:49 AM, srol...@vmware.com wrote: From: Roland Scheidegger Braces mismatch (flagged by CI, untested). Fixes: 385d13f26d2 "util/atomic: Add a _return variant of p_atomic_add" --- src/util/u_atomic.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/util/u_atomic.h b/src/util/u_atomic.h index 9cbc6dd1eaa..1ad87c8feb1 100644 --- a/src/util/u_atomic.h +++ b/src/util/u_atomic.h @@ -89,7 +89,7 @@ #define p_atomic_dec_zero(_v) (p_atomic_dec_return(_v) == 0) #define p_atomic_inc(_v) ((void) p_atomic_inc_return(_v)) #define p_atomic_dec(_v) ((void) p_atomic_dec_return(_v)) -#define p_atomic_add(_v, _i) ((void) p_atomic_add_return((_v), (_i)) +#define p_atomic_add(_v, _i) ((void) p_atomic_add_return((_v), (_i))) #define p_atomic_inc_return(_v) (++(*(_v))) #define p_atomic_dec_return(_v) (--(*(_v))) #define p_atomic_add_return(_v, _i) (*(_v) = *(_v) + (_i)) @@ -146,7 +146,7 @@ (assert(!"should not get here"), 0)) #define p_atomic_add(_v, _i) \ - ((void) p_atomic_add_return((_v), (_i)) + ((void) p_atomic_add_return((_v), (_i))) #define p_atomic_add_return(_v, _i) (\ sizeof *(_v) == sizeof(char)? _InterlockedExchangeAdd8 ((char *) (_v), (_i)) : \ ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] nir: no-op C99 _Pragma() with MSVC
On 11/22/2019 09:16 PM, Ian Romanick wrote: On 11/22/19 6:49 PM, Brian Paul wrote: This fixes a build failure on MSVC. BTW, it looks like clang supports _Pragma() but I don't know if it understands the "gcc unroll N" directive. It probably doesn't, but that should be okay. This just exists to speed up the debug builds in the pre-merge CI. Reviewed-by: Ian Romanick BTW, With gcc 5.4.0, there's a lot of warnings about the pragma not being understood: ../src/compiler/nir/nir_range_analysis.c:268:0: warning: ignoring #pragma GCC unroll [-Wunknown-pragmas] ASSERT_TABLE_IS_COMMUTATIVE(union_table); ^ ../src/compiler/nir/nir_range_analysis.c:268:0: warning: ignoring #pragma GCC unroll [-Wunknown-pragmas] ../src/compiler/nir/nir_range_analysis.c:269:0: warning: ignoring #pragma GCC unroll [-Wunknown-pragmas] I'd have to dig to see what version of gcc added that to add more preprocessor tests to silence it. -Brian Signed-off-by: Brian Paul --- src/compiler/nir/nir_range_analysis.c | 7 +++ 1 file changed, 7 insertions(+) diff --git a/src/compiler/nir/nir_range_analysis.c b/src/compiler/nir/nir_range_analysis.c index df5d4da..d38bcc0 100644 --- a/src/compiler/nir/nir_range_analysis.c +++ b/src/compiler/nir/nir_range_analysis.c @@ -218,6 +218,13 @@ analyze_constant(const struct nir_alu_instr *instr, unsigned src, */ #define ___ unknown + +/* MSVC doesn't have C99's _Pragma() */ +#ifdef _MSC_VER +#define _Pragma(x) +#endif + + #ifndef NDEBUG #define ASSERT_TABLE_IS_COMMUTATIVE(t)\ do { \ ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] nir: no-op C99 _Pragma() with MSVC
This fixes a build failure on MSVC. BTW, it looks like clang supports _Pragma() but I don't know if it understands the "gcc unroll N" directive. Signed-off-by: Brian Paul --- src/compiler/nir/nir_range_analysis.c | 7 +++ 1 file changed, 7 insertions(+) diff --git a/src/compiler/nir/nir_range_analysis.c b/src/compiler/nir/nir_range_analysis.c index df5d4da..d38bcc0 100644 --- a/src/compiler/nir/nir_range_analysis.c +++ b/src/compiler/nir/nir_range_analysis.c @@ -218,6 +218,13 @@ analyze_constant(const struct nir_alu_instr *instr, unsigned src, */ #define ___ unknown + +/* MSVC doesn't have C99's _Pragma() */ +#ifdef _MSC_VER +#define _Pragma(x) +#endif + + #ifndef NDEBUG #define ASSERT_TABLE_IS_COMMUTATIVE(t)\ do { \ -- 1.8.5.6 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] Call shmget() with permission 0600 instead of 0777
Ping again. On 10/24/2019 03:25 PM, Brian Paul wrote: Ping. Anyone? -Brian On Tue, Oct 22, 2019 at 3:52 PM Brian Paul <mailto:bri...@vmware.com>> wrote: A security advisory (TALOS-2019-0857/CVE-2019-5068) found that creating shared memory regions with permission mode 0777 could allow any user to access that memory. Several Mesa drivers use shared- memory XImages to implement back buffers for improved performance. This path changes the shmget() calls to use 0600 (user r/w). Tested with legacy Xlib driver and llvmpipe. Cc: mesa-sta...@lists.freedesktop.org <mailto:mesa-sta...@lists.freedesktop.org> --- src/gallium/winsys/sw/dri/dri_sw_winsys.c | 3 ++- src/gallium/winsys/sw/xlib/xlib_sw_winsys.c | 3 ++- src/mesa/drivers/x11/xm_buffer.c | 3 ++- 3 files changed, 6 insertions(+), 3 deletions(-) diff --git a/src/gallium/winsys/sw/dri/dri_sw_winsys.c b/src/gallium/winsys/sw/dri/dri_sw_winsys.c index 761f5d1..2e5970b 100644 --- a/src/gallium/winsys/sw/dri/dri_sw_winsys.c +++ b/src/gallium/winsys/sw/dri/dri_sw_winsys.c @@ -92,7 +92,8 @@ alloc_shm(struct dri_sw_displaytarget *dri_sw_dt, unsigned size) { char *addr; - dri_sw_dt->shmid = shmget(IPC_PRIVATE, size, IPC_CREAT|0777); + /* 0600 = user read+write */ + dri_sw_dt->shmid = shmget(IPC_PRIVATE, size, IPC_CREAT | 0600); if (dri_sw_dt->shmid < 0) return NULL; diff --git a/src/gallium/winsys/sw/xlib/xlib_sw_winsys.c b/src/gallium/winsys/sw/xlib/xlib_sw_winsys.c index c14c9de..edebb48 100644 --- a/src/gallium/winsys/sw/xlib/xlib_sw_winsys.c +++ b/src/gallium/winsys/sw/xlib/xlib_sw_winsys.c @@ -126,7 +126,8 @@ alloc_shm(struct xlib_displaytarget *buf, unsigned size) shminfo->shmid = -1; shminfo->shmaddr = (char *) -1; - shminfo->shmid = shmget(IPC_PRIVATE, size, IPC_CREAT|0777); + /* 0600 = user read+write */ + shminfo->shmid = shmget(IPC_PRIVATE, size, IPC_CREAT | 0600); if (shminfo->shmid < 0) { return NULL; } diff --git a/src/mesa/drivers/x11/xm_buffer.c b/src/mesa/drivers/x11/xm_buffer.c index d945d8a..0da08a6 100644 --- a/src/mesa/drivers/x11/xm_buffer.c +++ b/src/mesa/drivers/x11/xm_buffer.c @@ -89,8 +89,9 @@ alloc_back_shm_ximage(XMesaBuffer b, GLuint width, GLuint height) return GL_FALSE; } + /* 0600 = user read+write */ b->shminfo.shmid = shmget(IPC_PRIVATE, b->backxrb->ximage->bytes_per_line - * b->backxrb->ximage->height, IPC_CREAT|0777); + * b->backxrb->ximage->height, IPC_CREAT | 0600); if (b->shminfo.shmid < 0) { _mesa_warning(NULL, "shmget failed while allocating back buffer.\n"); XDestroyImage(b->backxrb->ximage); -- 1.8.5.6 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org <mailto:mesa-dev@lists.freedesktop.org> https://lists.freedesktop.org/mailman/listinfo/mesa-dev <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Fmesa-dev=02%7C01%7Cbrianp%40vmware.com%7Cae41e27c807a41901c9308d758c8b6f7%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637075491402263356=FDvN5Y%2BHswpYAfg96qF9sDykW7nn9ubkedWkFTKQTU0%3D=0> ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] spirv: s/{}/{0}/ initializer to fix MSVC build
Trivial. --- src/compiler/spirv/vtn_variables.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/compiler/spirv/vtn_variables.c b/src/compiler/spirv/vtn_variables.c index 944d1f0..37ad4f2 100644 --- a/src/compiler/spirv/vtn_variables.c +++ b/src/compiler/spirv/vtn_variables.c @@ -50,7 +50,7 @@ static struct vtn_pointer* vtn_decorate_pointer(struct vtn_builder *b, struct vtn_value *val, struct vtn_pointer *ptr) { - struct vtn_pointer dummy = { }; + struct vtn_pointer dummy = {0}; vtn_foreach_decoration(b, val, ptr_decoration_cb, ); /* If we're adding access flags, make a copy of the pointer. We could -- 1.8.5.6 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] nir: fix a couple signed/unsigned comparison warnings in nir_builder.h
--- src/compiler/nir/nir_builder.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/compiler/nir/nir_builder.h b/src/compiler/nir/nir_builder.h index de00fe7..aed4759 100644 --- a/src/compiler/nir/nir_builder.h +++ b/src/compiler/nir/nir_builder.h @@ -782,7 +782,7 @@ nir_extract_bits(nir_builder *b, nir_ssa_def **srcs, unsigned num_srcs, for (unsigned i = 0; i < num_srcs; i++) common_bit_size = MIN2(common_bit_size, srcs[i]->bit_size); if (first_bit > 0) - common_bit_size = MIN2(common_bit_size, (1 << (ffs(first_bit) - 1))); + common_bit_size = MIN2(common_bit_size, (1u << (ffs(first_bit) - 1))); /* We don't want to have to deal with 1-bit values */ assert(common_bit_size >= 8); @@ -800,7 +800,7 @@ nir_extract_bits(nir_builder *b, nir_ssa_def **srcs, unsigned num_srcs, const unsigned bit = first_bit + (i * common_bit_size); while (bit >= src_end_bit) { src_idx++; - assert(src_idx < num_srcs); + assert(src_idx < (int) num_srcs); src_start_bit = src_end_bit; src_end_bit += srcs[src_idx]->bit_size * srcs[src_idx]->num_components; -- 1.8.5.6 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] s/APIENTRY/GLAPIENTRY/ in teximage.c
The later is the right symbol for entrypoint functions. --- src/mesa/main/texgetimage.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/mesa/main/texgetimage.c b/src/mesa/main/texgetimage.c index e43f336..d6ec4c5 100644 --- a/src/mesa/main/texgetimage.c +++ b/src/mesa/main/texgetimage.c @@ -1969,7 +1969,7 @@ _mesa_GetCompressedTextureImage(GLuint texture, GLint level, } -void APIENTRY +void GLAPIENTRY _mesa_GetCompressedTextureSubImage(GLuint texture, GLint level, GLint xoffset, GLint yoffset, GLint zoffset, GLsizei width, -- 1.8.5.6 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] Call shmget() with permission 0600 instead of 0777
Ping. Anyone? -Brian On Tue, Oct 22, 2019 at 3:52 PM Brian Paul wrote: > A security advisory (TALOS-2019-0857/CVE-2019-5068) found that > creating shared memory regions with permission mode 0777 could allow > any user to access that memory. Several Mesa drivers use shared- > memory XImages to implement back buffers for improved performance. > > This path changes the shmget() calls to use 0600 (user r/w). > > Tested with legacy Xlib driver and llvmpipe. > > Cc: mesa-sta...@lists.freedesktop.org > --- > src/gallium/winsys/sw/dri/dri_sw_winsys.c | 3 ++- > src/gallium/winsys/sw/xlib/xlib_sw_winsys.c | 3 ++- > src/mesa/drivers/x11/xm_buffer.c| 3 ++- > 3 files changed, 6 insertions(+), 3 deletions(-) > > diff --git a/src/gallium/winsys/sw/dri/dri_sw_winsys.c > b/src/gallium/winsys/sw/dri/dri_sw_winsys.c > index 761f5d1..2e5970b 100644 > --- a/src/gallium/winsys/sw/dri/dri_sw_winsys.c > +++ b/src/gallium/winsys/sw/dri/dri_sw_winsys.c > @@ -92,7 +92,8 @@ alloc_shm(struct dri_sw_displaytarget *dri_sw_dt, > unsigned size) > { > char *addr; > > - dri_sw_dt->shmid = shmget(IPC_PRIVATE, size, IPC_CREAT|0777); > + /* 0600 = user read+write */ > + dri_sw_dt->shmid = shmget(IPC_PRIVATE, size, IPC_CREAT | 0600); > if (dri_sw_dt->shmid < 0) >return NULL; > > diff --git a/src/gallium/winsys/sw/xlib/xlib_sw_winsys.c > b/src/gallium/winsys/sw/xlib/xlib_sw_winsys.c > index c14c9de..edebb48 100644 > --- a/src/gallium/winsys/sw/xlib/xlib_sw_winsys.c > +++ b/src/gallium/winsys/sw/xlib/xlib_sw_winsys.c > @@ -126,7 +126,8 @@ alloc_shm(struct xlib_displaytarget *buf, unsigned > size) > shminfo->shmid = -1; > shminfo->shmaddr = (char *) -1; > > - shminfo->shmid = shmget(IPC_PRIVATE, size, IPC_CREAT|0777); > + /* 0600 = user read+write */ > + shminfo->shmid = shmget(IPC_PRIVATE, size, IPC_CREAT | 0600); > if (shminfo->shmid < 0) { >return NULL; > } > diff --git a/src/mesa/drivers/x11/xm_buffer.c > b/src/mesa/drivers/x11/xm_buffer.c > index d945d8a..0da08a6 100644 > --- a/src/mesa/drivers/x11/xm_buffer.c > +++ b/src/mesa/drivers/x11/xm_buffer.c > @@ -89,8 +89,9 @@ alloc_back_shm_ximage(XMesaBuffer b, GLuint width, > GLuint height) >return GL_FALSE; > } > > + /* 0600 = user read+write */ > b->shminfo.shmid = shmget(IPC_PRIVATE, > b->backxrb->ximage->bytes_per_line > -* b->backxrb->ximage->height, IPC_CREAT|0777); > + * b->backxrb->ximage->height, IPC_CREAT | > 0600); > if (b->shminfo.shmid < 0) { >_mesa_warning(NULL, "shmget failed while allocating back > buffer.\n"); >XDestroyImage(b->backxrb->ximage); > -- > 1.8.5.6 > > ___ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] Call shmget() with permission 0600 instead of 0777
A security advisory (TALOS-2019-0857/CVE-2019-5068) found that creating shared memory regions with permission mode 0777 could allow any user to access that memory. Several Mesa drivers use shared- memory XImages to implement back buffers for improved performance. This path changes the shmget() calls to use 0600 (user r/w). Tested with legacy Xlib driver and llvmpipe. Cc: mesa-sta...@lists.freedesktop.org --- src/gallium/winsys/sw/dri/dri_sw_winsys.c | 3 ++- src/gallium/winsys/sw/xlib/xlib_sw_winsys.c | 3 ++- src/mesa/drivers/x11/xm_buffer.c| 3 ++- 3 files changed, 6 insertions(+), 3 deletions(-) diff --git a/src/gallium/winsys/sw/dri/dri_sw_winsys.c b/src/gallium/winsys/sw/dri/dri_sw_winsys.c index 761f5d1..2e5970b 100644 --- a/src/gallium/winsys/sw/dri/dri_sw_winsys.c +++ b/src/gallium/winsys/sw/dri/dri_sw_winsys.c @@ -92,7 +92,8 @@ alloc_shm(struct dri_sw_displaytarget *dri_sw_dt, unsigned size) { char *addr; - dri_sw_dt->shmid = shmget(IPC_PRIVATE, size, IPC_CREAT|0777); + /* 0600 = user read+write */ + dri_sw_dt->shmid = shmget(IPC_PRIVATE, size, IPC_CREAT | 0600); if (dri_sw_dt->shmid < 0) return NULL; diff --git a/src/gallium/winsys/sw/xlib/xlib_sw_winsys.c b/src/gallium/winsys/sw/xlib/xlib_sw_winsys.c index c14c9de..edebb48 100644 --- a/src/gallium/winsys/sw/xlib/xlib_sw_winsys.c +++ b/src/gallium/winsys/sw/xlib/xlib_sw_winsys.c @@ -126,7 +126,8 @@ alloc_shm(struct xlib_displaytarget *buf, unsigned size) shminfo->shmid = -1; shminfo->shmaddr = (char *) -1; - shminfo->shmid = shmget(IPC_PRIVATE, size, IPC_CREAT|0777); + /* 0600 = user read+write */ + shminfo->shmid = shmget(IPC_PRIVATE, size, IPC_CREAT | 0600); if (shminfo->shmid < 0) { return NULL; } diff --git a/src/mesa/drivers/x11/xm_buffer.c b/src/mesa/drivers/x11/xm_buffer.c index d945d8a..0da08a6 100644 --- a/src/mesa/drivers/x11/xm_buffer.c +++ b/src/mesa/drivers/x11/xm_buffer.c @@ -89,8 +89,9 @@ alloc_back_shm_ximage(XMesaBuffer b, GLuint width, GLuint height) return GL_FALSE; } + /* 0600 = user read+write */ b->shminfo.shmid = shmget(IPC_PRIVATE, b->backxrb->ximage->bytes_per_line -* b->backxrb->ximage->height, IPC_CREAT|0777); + * b->backxrb->ximage->height, IPC_CREAT | 0600); if (b->shminfo.shmid < 0) { _mesa_warning(NULL, "shmget failed while allocating back buffer.\n"); XDestroyImage(b->backxrb->ximage); -- 1.8.5.6 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] st/nir: fix illegal designated initializer in st_glsl_to_nir.cpp
On 09/11/2019 03:06 PM, Ian Romanick wrote: On 9/10/19 10:53 PM, Brian Paul wrote: IIRC, designated initializers are not legal C++. Fixes the MSVC build. Fixes: 83fd1e58 ("glsl/nir: Add and use a gl_nir_link() function") --- src/mesa/state_tracker/st_glsl_to_nir.cpp | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/mesa/state_tracker/st_glsl_to_nir.cpp b/src/mesa/state_tracker/st_glsl_to_nir.cpp index 280a778..d6a0264 100644 --- a/src/mesa/state_tracker/st_glsl_to_nir.cpp +++ b/src/mesa/state_tracker/st_glsl_to_nir.cpp @@ -688,7 +688,7 @@ st_link_nir(struct gl_context *ctx, */ if (shader_program->data->spirv) { static const gl_nir_linker_options opts = { - .fill_parameters = true, + true /*fill_parameters */ Could we get a comment in the definition of gl_nir_linker_options to remind people to either add options only to the end or double check all of the places that initialize the structures? If someone adds 'bool do_foo_instead_of_bar' option at the beginning of that struct, it will cause problems. }; if (!gl_nir_link(ctx, shader_program, )) return GL_FALSE; How about something simple like this instead: diff --git a/src/mesa/state_tracker/st_glsl_to_nir.cpp b/src/mesa/state_tracker index d6a0264..4f5acfd 100644 --- a/src/mesa/state_tracker/st_glsl_to_nir.cpp +++ b/src/mesa/state_tracker/st_glsl_to_nir.cpp @@ -687,9 +687,14 @@ st_link_nir(struct gl_context *ctx, * st_nir_preprocess. */ if (shader_program->data->spirv) { - static const gl_nir_linker_options opts = { - true /*fill_parameters */ - }; + /* Note: this object could be static const but designated + * initializers are not part of the C++ standard (allowed by GCC + * but not MSVC.) + */ + gl_nir_linker_options opts = { 0 }; + + opts.fill_parameters = true; + if (!gl_nir_link(ctx, shader_program, )) return GL_FALSE; -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] st/nir: fix illegal designated initializer in st_glsl_to_nir.cpp
IIRC, designated initializers are not legal C++. Fixes the MSVC build. Fixes: 83fd1e58 ("glsl/nir: Add and use a gl_nir_link() function") --- src/mesa/state_tracker/st_glsl_to_nir.cpp | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/mesa/state_tracker/st_glsl_to_nir.cpp b/src/mesa/state_tracker/st_glsl_to_nir.cpp index 280a778..d6a0264 100644 --- a/src/mesa/state_tracker/st_glsl_to_nir.cpp +++ b/src/mesa/state_tracker/st_glsl_to_nir.cpp @@ -688,7 +688,7 @@ st_link_nir(struct gl_context *ctx, */ if (shader_program->data->spirv) { static const gl_nir_linker_options opts = { - .fill_parameters = true, + true /*fill_parameters */ }; if (!gl_nir_link(ctx, shader_program, )) return GL_FALSE; -- 1.8.5.6 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 4/4] scons: Make GCC builds stricter.
For the series, Reviewed-by: Brian Paul On 08/27/2019 04:57 AM, Jose Fonseca wrote: Uses some of the same -Werror options used by Meson, as suggested by Michel Daezer. --- scons/gallium.py | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/scons/gallium.py b/scons/gallium.py index 21197c8d0d1..2eff4174257 100755 --- a/scons/gallium.py +++ b/scons/gallium.py @@ -473,7 +473,10 @@ def generate(env): '-fmessage-length=0', # be nice to Eclipse ] cflags += [ -'-Wmissing-prototypes', +'-Werror=implicit-function-declaration', +'-Werror=missing-prototypes', +'-Werror=return-type', +'-Werror=incompatible-pointer-types', '-std=gnu99', ] if icc: ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] st/mesa: don't allocate mipmapped texture for NEAREST_MIPMAP_LINEAR
Reviewed-by: Brian Paul On 08/10/2019 10:14 AM, Marek Olšák wrote: Ping On Fri., Aug. 2, 2019, 19:13 Marek Olšák, <mailto:mar...@gmail.com>> wrote: From: Marek Olšák mailto:marek.ol...@amd.com>> --- src/mesa/state_tracker/st_cb_texture.c | 12 1 file changed, 12 insertions(+) diff --git a/src/mesa/state_tracker/st_cb_texture.c b/src/mesa/state_tracker/st_cb_texture.c index 0edb3ea5c7e..1ace61863ff 100644 --- a/src/mesa/state_tracker/st_cb_texture.c +++ b/src/mesa/state_tracker/st_cb_texture.c @@ -516,20 +516,32 @@ allocate_full_mipmap(const struct st_texture_object *stObj, return FALSE; if (stObj->base.BaseLevel == 0 && stObj->base.MaxLevel == 0) return FALSE; if (stObj->base.Sampler.MinFilter == GL_NEAREST || stObj->base.Sampler.MinFilter == GL_LINEAR) /* not a mipmap minification filter */ return FALSE; + /* If the following sequence of GL calls is used: + * glTexImage2D(GL_TEXTURE_2D, 0, GL_RGB, w, h, 0, GL_RGB, ... + * glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_LINEAR); + * + * we would needlessly allocate a mipmapped texture, because the initial + * MinFilter is GL_NEAREST_MIPMAP_LINEAR. Catch this case and don't + * allocate a mipmapped texture by default. This may cause texture + * reallocation later, but GL_NEAREST_MIPMAP_LINEAR is pretty rare. + */ + if (stObj->base.Sampler.MinFilter == GL_NEAREST_MIPMAP_LINEAR) + return FALSE; + if (stObj->base.Target == GL_TEXTURE_3D) /* 3D textures are seldom mipmapped */ return FALSE; return TRUE; } /** * Try to allocate a pipe_resource object for the given st_texture_object. -- 2.17.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] gallivm: fix issue with AtomicCmpXchg wrapper on llvm 3.5-3.8
On 08/02/2019 10:36 AM, srol...@vmware.com wrote: From: Roland Scheidegger These versions still need wrapper but already have both success and failure ordering. (Compile tested on llvm 3.7, llvm 3.8.) Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=02 --- src/gallium/auxiliary/gallivm/lp_bld_misc.cpp | 16 +++- 1 file changed, 15 insertions(+), 1 deletion(-) diff --git a/src/gallium/auxiliary/gallivm/lp_bld_misc.cpp b/src/gallium/auxiliary/gallivm/lp_bld_misc.cpp index 79d10293e80..723c84d57c2 100644 --- a/src/gallium/auxiliary/gallivm/lp_bld_misc.cpp +++ b/src/gallium/auxiliary/gallivm/lp_bld_misc.cpp @@ -822,15 +822,29 @@ static llvm::AtomicOrdering mapFromLLVMOrdering(LLVMAtomicOrdering Ordering) { llvm_unreachable("Invalid LLVMAtomicOrdering value!"); } +#if HAVE_LLVM < 0x305 LLVMValueRef LLVMBuildAtomicCmpXchg(LLVMBuilderRef B, LLVMValueRef Ptr, LLVMValueRef Cmp, LLVMValueRef New, LLVMAtomicOrdering SuccessOrdering, LLVMAtomicOrdering FailureOrdering, LLVMBool SingleThread) { - /* LLVM 3.8 doesn't have a second ordering and uses old SynchronizationScope enum */ + /* LLVM < 3.5 doesn't have a second ordering and uses old SynchronizationScope enum */ return llvm::wrap(llvm::unwrap(B)->CreateAtomicCmpXchg(llvm::unwrap(Ptr), llvm::unwrap(Cmp), llvm::unwrap(New), mapFromLLVMOrdering(SuccessOrdering), SingleThread ? llvm::SynchronizationScope::SingleThread : llvm::SynchronizationScope::CrossThread)); } +#else +LLVMValueRef LLVMBuildAtomicCmpXchg(LLVMBuilderRef B, LLVMValueRef Ptr, +LLVMValueRef Cmp, LLVMValueRef New, +LLVMAtomicOrdering SuccessOrdering, +LLVMAtomicOrdering FailureOrdering, +LLVMBool SingleThread) +{ + return llvm::wrap(llvm::unwrap(B)->CreateAtomicCmpXchg(llvm::unwrap(Ptr), llvm::unwrap(Cmp), + llvm::unwrap(New), mapFromLLVMOrdering(SuccessOrdering), + mapFromLLVMOrdering(FailureOrdering), + SingleThread ? llvm::SynchronizationScope::SingleThread : llvm::SynchronizationScope::CrossThread)); +} +#endif #endif Could the #if / #endif logic be moved into the body of LLVMBuildAtomicCmpXchg() so the whole function isn't duplicated? Other than that, Reviewed-by: Brian Paul ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Mesa (update-reviewers-for-vmware): i965/clear: clear_value better precision
On 08/02/2019 09:56 AM, Eric Engestrom wrote: On Friday, 2019-08-02 17:50:17 +0200, Michel Dänzer wrote: On 2019-08-02 5:37 p.m., Brian Paul wrote: Ugh, I didn't mean to do this. I'm trying to figure out how to make a merge request with gitlab. Just push to a branch in your personal repository, and the output of git push contains an URL for creating an MR for it. Precisely, but just to be extra clear: your personal repo needs to be forked from the main mesa repo [1], not just "a repo containing the mesa git history". GitLab needs to know the two are linked and pressing that "fork" button is how you tell it. Yeah, I just figured that out a few minutes ago. After I figure out all the detailed steps from scratch I'll add it to the documentation. I've really never done anything with gitlab, github, etc. and have been busy with non-Mesa work for over a year now. I have a lot of catch-up to do. -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Mesa (update-reviewers-for-vmware): i965/clear: clear_value better precision
Ugh, I didn't mean to do this. I'm trying to figure out how to make a merge request with gitlab. -Brian On 08/02/2019 09:35 AM, GitLab Mirror wrote: Module: Mesa Branch: update-reviewers-for-vmware Commit: a86eccfb78092493b3999849db62613838951756 URL: https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcgit.freedesktop.org%2Fmesa%2Fmesa%2Fcommit%2F%3Fid%3Da86eccfb78092493b3999849db62613838951756data=02%7C01%7Cbrianp%40vmware.com%7C6aa9bf59501d420b03af08d7175f0b0f%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637003569293293608sdata=bLEb7XY3mLFAkME7v8QJ0GugG%2FbzFoNONSSGTjKSfFs%3Dreserved=0 Author: Sergii Romantsov Date: Fri Jul 12 16:46:45 2019 +0300 i965/clear: clear_value better precision Test-case with depth-clear 0.5 and format MESA_FORMAT_Z24_UNORM_X8_UINT fails due inconsistent clear-value of 0.497. Maybe its better to improve? CC: Jason Ekstrand Fixes: 0ae9ce0f29ea (i965/clear: Quantize the depth clear value based on the format) Bugzilla: https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.freedesktop.org%2Fshow_bug.cgi%3Fid%3D13data=02%7C01%7Cbrianp%40vmware.com%7C6aa9bf59501d420b03af08d7175f0b0f%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637003569293293608sdata=OD1YuhGY%2B4IZG7g8PMh%2Bk3amc6O9HjDV92pOFPd8RlE%3Dreserved=0 Signed-off-by: Sergii Romantsov Signed-off-by: Danylo Piliaiev Reviewed-by: Jason Ekstrand --- src/mesa/drivers/dri/i965/brw_clear.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/mesa/drivers/dri/i965/brw_clear.c b/src/mesa/drivers/dri/i965/brw_clear.c index 30e09861491..1508171da10 100644 --- a/src/mesa/drivers/dri/i965/brw_clear.c +++ b/src/mesa/drivers/dri/i965/brw_clear.c @@ -167,7 +167,7 @@ brw_fast_clear_depth(struct gl_context *ctx) */ float clear_value = mt->format == MESA_FORMAT_Z_FLOAT32 ? ctx->Depth.Clear : - (unsigned)(ctx->Depth.Clear * fb->_DepthMax) / (float)fb->_DepthMax; + _mesa_lroundeven(ctx->Depth.Clear * fb->_DepthMax) / (float)(fb->_DepthMax); const uint32_t num_layers = depth_att->Layered ? depth_irb->layer_count : 1; ___ mesa-commit mailing list mesa-com...@lists.freedesktop.org https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Fmesa-commitdata=02%7C01%7Cbrianp%40vmware.com%7C6aa9bf59501d420b03af08d7175f0b0f%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637003569293293608sdata=UWAkli3USsLDpnoElsuycRJ8KTrJV%2FC0r%2FarUay7SNQ%3Dreserved=0 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] gallivm: fix a missing argument to CreateAtomicCmpXchg
On 08/01/2019 04:56 PM, Charmaine Lee wrote: This patch fixes a missing argument to CreateAtomicCmpXchg for older version of LLVM. --- src/gallium/auxiliary/gallivm/lp_bld_misc.cpp | 1 + 1 file changed, 1 insertion(+) diff --git a/src/gallium/auxiliary/gallivm/lp_bld_misc.cpp b/src/gallium/auxiliary/gallivm/lp_bld_misc.cpp index 79d1029..8205d24 100644 --- a/src/gallium/auxiliary/gallivm/lp_bld_misc.cpp +++ b/src/gallium/auxiliary/gallivm/lp_bld_misc.cpp @@ -831,6 +831,7 @@ LLVMValueRef LLVMBuildAtomicCmpXchg(LLVMBuilderRef B, LLVMValueRef Ptr, /* LLVM 3.8 doesn't have a second ordering and uses old SynchronizationScope enum */ return llvm::wrap(llvm::unwrap(B)->CreateAtomicCmpXchg(llvm::unwrap(Ptr), llvm::unwrap(Cmp), llvm::unwrap(New), mapFromLLVMOrdering(SuccessOrdering), + mapFromLLVMOrdering(FailureOrdering), SingleThread ? llvm::SynchronizationScope::SingleThread : llvm::SynchronizationScope::CrossThread)); } #endif Reviewed-by: Brian Paul ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] nir/loop_analyze: used nir_alu_src to track loop limit
+ if (!try_find_limit_of_alu(limit, _val, terminator)) { /* Guess loop limit based on array access */ if (!guess_loop_limit(state, _val, basic_ind)) { continue; I'm seeing a suspicious warning with these patches: [105/1031] Compiling C object 'src/com...ler/nir/nir@sta/nir_loop_analyze.c.o'. ../src/compiler/nir/nir_loop_analyze.c: In function ‘process_loops’: ../src/compiler/nir/nir_loop_analyze.c:933:7: warning: ‘limit_rhs’ may be used uninitialized in this function [-Wmaybe-uninitialized] terminator->induction_rhs = !limit_rhs; ^~ ../src/compiler/nir/nir_loop_analyze.c:895:12: note: ‘limit_rhs’ was declared here bool limit_rhs; ^ -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] freedreno: 'Unhandled NIR tex src type: 11' on A3XX
On Mon, Jun 10, 2019 at 06:58:30AM -0700, Rob Clark wrote: > On Mon, Jun 10, 2019 at 6:53 AM Rob Clark wrote: > > > > On Sat, Jun 8, 2019 at 6:08 PM Brian Masney wrote: > > > > > > Hi, > > > > > > I'm trying to get the GPU working using the Freedreno driver (A330) on > > > the Nexus 5 phone. I'm using kernel 5.2rc3 with some out of tree patches > > > related to the GPU [1] and mesa 19.1.0-rc5 on postmarketOS. When I run > > > glxgears, I see the gears show up for a fraction of a second and then > > > it terminates due to the following error: > > > > > > - > > > shader: MESA_SHADER_FRAGMENT > > > inputs: 1 > > > outputs: 1 > > > uniforms: 0 > > > shared: 0 > > > decl_var uniform INTERP_MODE_NONE sampler2D sampler (0, 0, 0) > > > decl_var shader_in INTERP_MODE_SMOOTH vec4 in_0 (VARYING_SLOT_VAR0, 0, 0) > > > decl_var shader_out INTERP_MODE_FLAT vec4 out_0 (FRAG_RESULT_DATA0, 0, 0) > > > decl_function main (0 params) > > > > > > impl main { > > > block block_0: > > > /* preds: */ > > > vec1 32 ssa_0 = load_const (0x /* 0.00 */) > > > vec2 32 ssa_1 = intrinsic load_barycentric_pixel () (1) /* > > > interp_mode=1 */ > > > vec4 32 ssa_2 = intrinsic load_interpolated_input (ssa_1, ssa_0) > > > (0, 0) /* base=0 */ /* component=0 */ /* in_0 */ > > > vec1 32 ssa_3 = deref_var (uniform sampler2D) > > > vec2 32 ssa_4 = vec2 ssa_2.x, ssa_2.y > > > vec4 32 ssa_5 = tex ssa_3 (texture_deref), ssa_3 (sampler_deref), > > > ssa_4 (coord) > > > Unhandled NIR tex src type: 11 > > > > This should be getting lowered somewhere.. and I don't *think* it > > should be a3xx specific. > > It should be getting lowered in gl_nir_lower_samplers().. which should > be called from mesa/st before the driver even sees this shader. > > Could you build mesa from git w/ latest 19.1, I guess this must have > been fixed by now, since other drivers that use nir would hit the same > issue. This error doesn't happen on X11 using the mesa master branch. Instead, I get the following error on that branch: ../src/gallium/drivers/freedreno/freedreno_batch.c:424:fd_batch_add_dep: Assertion `!batch_depends_on(dep, batch)' failed. Full disclosure though: I rebuilt the mesa package using the postmarketOS packaging yesterday and it includes a few extra patches for musl libc. https://gitlab.com/postmarketOS/pmaports/tree/master/temp/mesa Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] freedreno: 'Unhandled NIR tex src type: 11' on A3XX
On Mon, Jun 10, 2019 at 10:00:01PM -0400, Jonathan Marek wrote: > On 6/10/19 10:00 PM, Brian Masney wrote: > > On Mon, Jun 10, 2019 at 09:53:25PM -0400, Jonathan Marek wrote: > > > > > > This error doesn't happen on X11 using the mesa master branch. > > > > > > Instead, > > > > > > I get the following error on that branch: > > > > > > > > > > > > ../src/gallium/drivers/freedreno/freedreno_batch.c:424:fd_batch_add_dep: > > > > > > Assertion `!batch_depends_on(dep, batch)' failed. > > > > > > > > > > > > Full disclosure though: I rebuilt the mesa package using the > > > > > > postmarketOS packaging yesterday and it includes a few extra > > > > > > patches for > > > > > > musl libc. > > > > > > > > > > > > https://gitlab.com/postmarketOS/pmaports/tree/master/temp/mesa > > > > > > > > > > > > > > > I don't see anything obvious in those patches that would be related.. > > > > > but I suspect this type of error is going to be timing related. > > > > > (Which could ofc be due to musl or something else) > > > > > > > > > > but a bit surprised debug_assert() is enabled in debug builds.. it > > > > > would probably be a "harmless" situation if asserts were not enabled. > > > > > > > > > > (note that I do most of my testing with debug builds with asserts > > > > > enabled.. this is the type of thing that I want to see and fix.. but > > > > > probably shouldn't matter to end users) > > > > > > > > I recompiled the master branch of mesa in pmOS with '-Db_ndebug=true' > > > > and X11 is now working properly on the Nexus 5. glxgears averages about > > > > 59.5 FPS. I'll add a bug report with pmOS to have them add that flag to > > > > their mesa build. Fedora added that flag to their builds: > > > > https://bugzilla.redhat.com/show_bug.cgi?id=1692426 > > > > > > > > 19.1.0-rc5 still doesn't work for me due to the original error. > > > > > > > > Brian > > > > > > > > > > You probably want '--buildtype=release' instead of '-Db_ndebug=true' > > > > According to: > > https://gitlab.freedesktop.org/mesa/mesa/blob/master/docs/meson.html#L321 > > > > -Db_ndebug - This option controls assertions in meson projects. When > > set to false (the default) assertions are enabled, when set to true > > they are disabled. This is unrelated to the buildtype; setting the > > latter to release will not turn off assertions. > > > > Brian > > > > I always thought release == no assertions, I guess meson has different > ideas. You will want '--buildtype=release' anyway for optimizations, etc. That's also missing from the pmOS build, so I added it to the bug report as well: https://gitlab.com/postmarketOS/pmaports/issues/296 Thanks, Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] freedreno: 'Unhandled NIR tex src type: 11' on A3XX
On Mon, Jun 10, 2019 at 09:53:25PM -0400, Jonathan Marek wrote: > > > > This error doesn't happen on X11 using the mesa master branch. Instead, > > > > I get the following error on that branch: > > > > > > > > ../src/gallium/drivers/freedreno/freedreno_batch.c:424:fd_batch_add_dep: > > > > Assertion `!batch_depends_on(dep, batch)' failed. > > > > > > > > Full disclosure though: I rebuilt the mesa package using the > > > > postmarketOS packaging yesterday and it includes a few extra patches for > > > > musl libc. > > > > > > > > https://gitlab.com/postmarketOS/pmaports/tree/master/temp/mesa > > > > > > > > > I don't see anything obvious in those patches that would be related.. > > > but I suspect this type of error is going to be timing related. > > > (Which could ofc be due to musl or something else) > > > > > > but a bit surprised debug_assert() is enabled in debug builds.. it > > > would probably be a "harmless" situation if asserts were not enabled. > > > > > > (note that I do most of my testing with debug builds with asserts > > > enabled.. this is the type of thing that I want to see and fix.. but > > > probably shouldn't matter to end users) > > > > I recompiled the master branch of mesa in pmOS with '-Db_ndebug=true' > > and X11 is now working properly on the Nexus 5. glxgears averages about > > 59.5 FPS. I'll add a bug report with pmOS to have them add that flag to > > their mesa build. Fedora added that flag to their builds: > > https://bugzilla.redhat.com/show_bug.cgi?id=1692426 > > > > 19.1.0-rc5 still doesn't work for me due to the original error. > > > > Brian > > > > You probably want '--buildtype=release' instead of '-Db_ndebug=true' According to: https://gitlab.freedesktop.org/mesa/mesa/blob/master/docs/meson.html#L321 -Db_ndebug - This option controls assertions in meson projects. When set to false (the default) assertions are enabled, when set to true they are disabled. This is unrelated to the buildtype; setting the latter to release will not turn off assertions. Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] freedreno: 'Unhandled NIR tex src type: 11' on A3XX
Hi Rob, On Mon, Jun 10, 2019 at 05:10:45PM -0700, Rob Clark wrote: > On Mon, Jun 10, 2019 at 3:54 PM Brian Masney wrote: > > > > On Mon, Jun 10, 2019 at 06:58:30AM -0700, Rob Clark wrote: > > > On Mon, Jun 10, 2019 at 6:53 AM Rob Clark wrote: > > > > > > > > On Sat, Jun 8, 2019 at 6:08 PM Brian Masney > > > > wrote: > > > > > > > > > > Hi, > > > > > > > > > > I'm trying to get the GPU working using the Freedreno driver (A330) on > > > > > the Nexus 5 phone. I'm using kernel 5.2rc3 with some out of tree > > > > > patches > > > > > related to the GPU [1] and mesa 19.1.0-rc5 on postmarketOS. When I run > > > > > glxgears, I see the gears show up for a fraction of a second and then > > > > > it terminates due to the following error: > > > > > > > > > > - > > > > > shader: MESA_SHADER_FRAGMENT > > > > > inputs: 1 > > > > > outputs: 1 > > > > > uniforms: 0 > > > > > shared: 0 > > > > > decl_var uniform INTERP_MODE_NONE sampler2D sampler (0, 0, 0) > > > > > decl_var shader_in INTERP_MODE_SMOOTH vec4 in_0 (VARYING_SLOT_VAR0, > > > > > 0, 0) > > > > > decl_var shader_out INTERP_MODE_FLAT vec4 out_0 (FRAG_RESULT_DATA0, > > > > > 0, 0) > > > > > decl_function main (0 params) > > > > > > > > > > impl main { > > > > > block block_0: > > > > > /* preds: */ > > > > > vec1 32 ssa_0 = load_const (0x /* 0.00 */) > > > > > vec2 32 ssa_1 = intrinsic load_barycentric_pixel () (1) /* > > > > > interp_mode=1 */ > > > > > vec4 32 ssa_2 = intrinsic load_interpolated_input (ssa_1, > > > > > ssa_0) (0, 0) /* base=0 */ /* component=0 */ /* in_0 */ > > > > > vec1 32 ssa_3 = deref_var (uniform sampler2D) > > > > > vec2 32 ssa_4 = vec2 ssa_2.x, ssa_2.y > > > > > vec4 32 ssa_5 = tex ssa_3 (texture_deref), ssa_3 > > > > > (sampler_deref), ssa_4 (coord) > > > > > Unhandled NIR tex src type: 11 > > > > > > > > This should be getting lowered somewhere.. and I don't *think* it > > > > should be a3xx specific. > > > > > > It should be getting lowered in gl_nir_lower_samplers().. which should > > > be called from mesa/st before the driver even sees this shader. > > > > > > Could you build mesa from git w/ latest 19.1, I guess this must have > > > been fixed by now, since other drivers that use nir would hit the same > > > issue. > > > > This error doesn't happen on X11 using the mesa master branch. Instead, > > I get the following error on that branch: > > > > ../src/gallium/drivers/freedreno/freedreno_batch.c:424:fd_batch_add_dep: > > Assertion `!batch_depends_on(dep, batch)' failed. > > > > Full disclosure though: I rebuilt the mesa package using the > > postmarketOS packaging yesterday and it includes a few extra patches for > > musl libc. > > > > https://gitlab.com/postmarketOS/pmaports/tree/master/temp/mesa > > > I don't see anything obvious in those patches that would be related.. > but I suspect this type of error is going to be timing related. > (Which could ofc be due to musl or something else) > > but a bit surprised debug_assert() is enabled in debug builds.. it > would probably be a "harmless" situation if asserts were not enabled. > > (note that I do most of my testing with debug builds with asserts > enabled.. this is the type of thing that I want to see and fix.. but > probably shouldn't matter to end users) I recompiled the master branch of mesa in pmOS with '-Db_ndebug=true' and X11 is now working properly on the Nexus 5. glxgears averages about 59.5 FPS. I'll add a bug report with pmOS to have them add that flag to their mesa build. Fedora added that flag to their builds: https://bugzilla.redhat.com/show_bug.cgi?id=1692426 19.1.0-rc5 still doesn't work for me due to the original error. Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] freedreno: 'Unhandled NIR tex src type: 11' on A3XX
On Sun, Jun 09, 2019 at 10:40:52AM -0400, Jonathan Marek wrote: > On 6/9/19 8:41 AM, Brian Masney wrote: > > On Sat, Jun 08, 2019 at 10:58:11PM -0400, Jonathan Marek wrote: > > > Hi, > > > > > > It's possible 19.1 has another issue, I only tested the master branch with > > > my fix. I would suggest trying 19.0 or the master branch. > > > > The mesa master branch and 19.0.6 both give the following error when > > glxgears starts up: > > > > ../src/gallium/drivers/freedreno/freedreno_batch.c:424:fd_batch_add_dep: > > Assertion `!batch_depends_on(dep, batch)' failed. > > > > No one is testing freedreno+X11 AFAIK. This would affect all adrenos too, > not just a3xx. I can look into it at some point, if no one else does. > > To test if the GPU works at all you should use kmscube. If that works then > you can try wayland/weston, or if you really need X11 IIRC 18.1 was working > with X11. kmscube works on the Nexus 5 and that's all I need for my kernel testing. Thank you! Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] freedreno: 'Unhandled NIR tex src type: 11' on A3XX
On Sat, Jun 08, 2019 at 10:58:11PM -0400, Jonathan Marek wrote: > Hi, > > It's possible 19.1 has another issue, I only tested the master branch with > my fix. I would suggest trying 19.0 or the master branch. The mesa master branch and 19.0.6 both give the following error when glxgears starts up: ../src/gallium/drivers/freedreno/freedreno_batch.c:424:fd_batch_add_dep: Assertion `!batch_depends_on(dep, batch)' failed. > FYI, I haven't pushed it anywhere but I recently rebased my Nexus 5 patches > from last year (and been looking at getting call audio working). Fantastic! Brian > On 6/8/19 9:08 PM, Brian Masney wrote: > > Hi, > > > > I'm trying to get the GPU working using the Freedreno driver (A330) on > > the Nexus 5 phone. I'm using kernel 5.2rc3 with some out of tree patches > > related to the GPU [1] and mesa 19.1.0-rc5 on postmarketOS. When I run > > glxgears, I see the gears show up for a fraction of a second and then > > it terminates due to the following error: > > > > - > > shader: MESA_SHADER_FRAGMENT > > inputs: 1 > > outputs: 1 > > uniforms: 0 > > shared: 0 > > decl_var uniform INTERP_MODE_NONE sampler2D sampler (0, 0, 0) > > decl_var shader_in INTERP_MODE_SMOOTH vec4 in_0 (VARYING_SLOT_VAR0, 0, 0) > > decl_var shader_out INTERP_MODE_FLAT vec4 out_0 (FRAG_RESULT_DATA0, 0, 0) > > decl_function main (0 params) > > > > impl main { > > block block_0: > > /* preds: */ > > vec1 32 ssa_0 = load_const (0x /* 0.00 */) > > vec2 32 ssa_1 = intrinsic load_barycentric_pixel () (1) /* > > interp_mode=1 */ > > vec4 32 ssa_2 = intrinsic load_interpolated_input (ssa_1, ssa_0) > > (0, 0) /* base=0 */ /* component=0 */ /* in_0 */ > > vec1 32 ssa_3 = deref_var (uniform sampler2D) > > vec2 32 ssa_4 = vec2 ssa_2.x, ssa_2.y > > vec4 32 ssa_5 = tex ssa_3 (texture_deref), ssa_3 (sampler_deref), > > ssa_4 (coord) > > Unhandled NIR tex src type: 11 > > > > > > intrinsic store_output (ssa_5, ssa_0) (0, 15, 0) /* base=0 */ /* > > wrmask=xyzw */ /* component=0 */ /* out_0 */ > > /* succs: block_1 */ > > block block_1: > > } > > > > Assertion failed: !"" (../src/freedreno/ir3/ir3_context.c: > > ir3_context_error: 407) > > - > > > > I verified that the mesa 19.1.0-rc5 release contains this recent a3xx > > fix from Jonathan: > > https://gitlab.freedesktop.org/mesa/mesa/commit/1db86d8b62860380c34af77ae62b019ed2376443 > > > > Any suggestions? > > > > [1] https://github.com/masneyb/linux/commits/v5.2-rc3-nexus5-gpu-wip > > The GPU specific patches start at Rob's patch 'qcom-scm: add support > > to restore secure config' on that list. I submitted the patches > > below that a few weeks ago to the upstream kernel and I expect > > they'll be merged. Once I have a working GPU, I plan to start > > working on the interconnect support in the kernel for msm8974 so > > that the clock hacks can be dropped. > > > > Brian > > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] freedreno: 'Unhandled NIR tex src type: 11' on A3XX
Hi, I'm trying to get the GPU working using the Freedreno driver (A330) on the Nexus 5 phone. I'm using kernel 5.2rc3 with some out of tree patches related to the GPU [1] and mesa 19.1.0-rc5 on postmarketOS. When I run glxgears, I see the gears show up for a fraction of a second and then it terminates due to the following error: - shader: MESA_SHADER_FRAGMENT inputs: 1 outputs: 1 uniforms: 0 shared: 0 decl_var uniform INTERP_MODE_NONE sampler2D sampler (0, 0, 0) decl_var shader_in INTERP_MODE_SMOOTH vec4 in_0 (VARYING_SLOT_VAR0, 0, 0) decl_var shader_out INTERP_MODE_FLAT vec4 out_0 (FRAG_RESULT_DATA0, 0, 0) decl_function main (0 params) impl main { block block_0: /* preds: */ vec1 32 ssa_0 = load_const (0x /* 0.00 */) vec2 32 ssa_1 = intrinsic load_barycentric_pixel () (1) /* interp_mode=1 */ vec4 32 ssa_2 = intrinsic load_interpolated_input (ssa_1, ssa_0) (0, 0) /* base=0 */ /* component=0 */ /* in_0 */ vec1 32 ssa_3 = deref_var (uniform sampler2D) vec2 32 ssa_4 = vec2 ssa_2.x, ssa_2.y vec4 32 ssa_5 = tex ssa_3 (texture_deref), ssa_3 (sampler_deref), ssa_4 (coord) Unhandled NIR tex src type: 11 intrinsic store_output (ssa_5, ssa_0) (0, 15, 0) /* base=0 */ /* wrmask=xyzw */ /* component=0 */ /* out_0 */ /* succs: block_1 */ block block_1: } Assertion failed: !"" (../src/freedreno/ir3/ir3_context.c: ir3_context_error: 407) - I verified that the mesa 19.1.0-rc5 release contains this recent a3xx fix from Jonathan: https://gitlab.freedesktop.org/mesa/mesa/commit/1db86d8b62860380c34af77ae62b019ed2376443 Any suggestions? [1] https://github.com/masneyb/linux/commits/v5.2-rc3-nexus5-gpu-wip The GPU specific patches start at Rob's patch 'qcom-scm: add support to restore secure config' on that list. I submitted the patches below that a few weeks ago to the upstream kernel and I expect they'll be merged. Once I have a working GPU, I plan to start working on the interconnect support in the kernel for msm8974 so that the clock hacks can be dropped. Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] nir: silence three compiler warnings seen with MinGW
Ping. -Brian On 05/20/2019 07:36 AM, Brian Paul wrote: Silence two unused var warnings. And init elem_size, elem_align to zero to silence "maybe uninitialized" warnings. --- src/compiler/nir/nir_lower_int_to_float.c | 2 +- src/compiler/nir/nir_opt_copy_prop_vars.c | 4 +--- src/compiler/nir_types.cpp| 2 +- 3 files changed, 3 insertions(+), 5 deletions(-) diff --git a/src/compiler/nir/nir_lower_int_to_float.c b/src/compiler/nir/nir_lower_int_to_float.c index 439afa0..66a740d9 100644 --- a/src/compiler/nir/nir_lower_int_to_float.c +++ b/src/compiler/nir/nir_lower_int_to_float.c @@ -28,7 +28,7 @@ static bool assert_ssa_def_is_not_int(nir_ssa_def *def, void *arg) { - BITSET_WORD *int_types = arg; + MAYBE_UNUSED BITSET_WORD *int_types = arg; assert(!BITSET_TEST(int_types, def->index)); return true; } diff --git a/src/compiler/nir/nir_opt_copy_prop_vars.c b/src/compiler/nir/nir_opt_copy_prop_vars.c index 94bc8af..0fd96b7 100644 --- a/src/compiler/nir/nir_opt_copy_prop_vars.c +++ b/src/compiler/nir/nir_opt_copy_prop_vars.c @@ -433,9 +433,7 @@ load_element_from_ssa_entry_value(struct copy_prop_var_state *state, nir_builder *b, nir_intrinsic_instr *intrin, struct value *value, unsigned index) { - const struct glsl_type *type = entry->dst->type; - unsigned num_components = glsl_get_vector_elements(type); - assert(index < num_components); + assert(index < glsl_get_vector_elements(entry->dst->type)); /* We don't have the element available, so let the instruction do the work. */ if (!entry->src.ssa.def[index]) diff --git a/src/compiler/nir_types.cpp b/src/compiler/nir_types.cpp index 3bf93c5..e2dfc40 100644 --- a/src/compiler/nir_types.cpp +++ b/src/compiler/nir_types.cpp @@ -630,7 +630,7 @@ glsl_get_natural_size_align_bytes(const struct glsl_type *type, *size = 0; *align = 0; for (unsigned i = 0; i < type->length; i++) { - unsigned elem_size, elem_align; + unsigned elem_size = 0, elem_align = 0; glsl_get_natural_size_align_bytes(type->fields.structure[i].type, _size, _align); *align = MAX2(*align, elem_align); ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Mesa (master): glsl: do not use deprecated bison-keyword
On 05/23/2019 02:48 AM, Erik Faye-Lund wrote: On Wed, 2019-05-22 at 18:06 +0200, Akim Demaille wrote: Hi Erik, Le 22 mai 2019 à 08:54, Erik Faye-Lund < erik.faye-l...@collabora.com> a écrit : I ended up reverting the change [from-%error-verbose to %define parse.error verbose] , and I can't find an obcious way to support both old and new versions with the same source file. Well, you just disable warnings about deprecated features. -Wno-deprecated. The Android SDK also ships a pre-3.x version of Bison, so you're not the only one affected. Also, Chocolatey doesn't provide a new enough version of Bison for Windows either. I would be interested in knowing why some distros lag. Do you happen to know why for some of them? The only clear examples I know of are the Android SDK and Chocolatey. As I said before, we mighit not have to use the bison version shipped in the Android SDK, so perhaps that's fixable. And for Chocolatey, it turns out they have a winflexbison pacakge and a winflexbison3 package, and the latter has a more recent Bison version. So looking at this again, it looks like it might be solveable, at least in the cases where this is visible to me. Brian: do you think VMWare cuold upgrade the Bison version used in the forseeable future? I could start to work on that. Getting new ancillary components into our build system is rather complex, but I've been through it a few times. -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Mesa (master): glsl: do not use deprecated bison-keyword
I think this change broke the MSVC build for us. I may not have time to investigate until later today. -Brian On 05/21/2019 05:41 AM, GitLab Mirror wrote: Module: Mesa Branch: master Commit: eb85124a9f6e9cb94d0d4a99f91bbae374777e3a URL: https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcgit.freedesktop.org%2Fmesa%2Fmesa%2Fcommit%2F%3Fid%3Deb85124a9f6e9cb94d0d4a99f91bbae374777e3adata=02%7C01%7Cbrianp%40vmware.com%7C8fb4b04aba0f46cf005d08d6dde15558%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C636940357210597924sdata=N0sBC6rz%2F4KcpZyCKuNbNqNNhSE%2Fu6d8DcMCQY7STkY%3Dreserved=0 Author: Erik Faye-Lund Date: Mon May 20 13:29:05 2019 +0200 glsl: do not use deprecated bison-keyword %error-verbose has been deprecated since Bison 3.0, which was released in 2013. In Bison 3.3.1 which was recently released, this has started causing warnings. Let's update the code to do this in the modern way intead, to avoid cluttering the output needlessly. Signed-off-by: Erik Faye-Lund Reviewed-by: Timothy Arceri --- src/compiler/glsl/glcpp/glcpp-parse.y | 2 +- src/compiler/glsl/glsl_parser.yy | 2 +- src/mesa/program/program_parse.y | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/src/compiler/glsl/glcpp/glcpp-parse.y b/src/compiler/glsl/glcpp/glcpp-parse.y index 1c095cb66f9..736af7e680d 100644 --- a/src/compiler/glsl/glcpp/glcpp-parse.y +++ b/src/compiler/glsl/glcpp/glcpp-parse.y @@ -155,7 +155,7 @@ add_builtin_define(glcpp_parser_t *parser, const char *name, int value); %} %pure-parser -%error-verbose +%define parse.error verbose %locations %initial-action { diff --git a/src/compiler/glsl/glsl_parser.yy b/src/compiler/glsl/glsl_parser.yy index 6426f890b9e..dc6aade2643 100644 --- a/src/compiler/glsl/glsl_parser.yy +++ b/src/compiler/glsl/glsl_parser.yy @@ -81,7 +81,7 @@ static bool match_layout_qualifier(const char *s1, const char *s2, %expect 0 %pure-parser -%error-verbose +%define parse.error verbose %locations %initial-action { diff --git a/src/mesa/program/program_parse.y b/src/mesa/program/program_parse.y index 7398f5f507a..3d0c1e2ea9e 100644 --- a/src/mesa/program/program_parse.y +++ b/src/mesa/program/program_parse.y @@ -124,7 +124,7 @@ static struct asm_instruction *asm_instruction_copy_ctor( %locations %lex-param { struct asm_parser_state *state } %parse-param { struct asm_parser_state *state } -%error-verbose +%define parse.error verbose %union { struct asm_instruction *inst; ___ mesa-commit mailing list mesa-com...@lists.freedesktop.org https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Fmesa-commitdata=02%7C01%7Cbrianp%40vmware.com%7C8fb4b04aba0f46cf005d08d6dde15558%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C636940357210607919sdata=%2F%2FK4CMY1Wd9PgydEgugYq63pp26NkX%2B4venu%2FYk7FQk%3Dreserved=0 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/2] mesa: unreference current winsys buffers when unbinding winsys buffers
Both look OK to me. Do they need to be tagged with "Cc: mesa-sta...@lists.freedesktop.org" for the stable branches? Reviewed-by: Brian Paul On 05/18/2019 07:46 PM, Charmaine Lee wrote: This fixes surface leak when no winsys buffers are bound. --- src/mesa/main/context.c | 4 1 file changed, 4 insertions(+) diff --git a/src/mesa/main/context.c b/src/mesa/main/context.c index 34da16b..04ef4d5 100644 --- a/src/mesa/main/context.c +++ b/src/mesa/main/context.c @@ -1765,6 +1765,10 @@ _mesa_make_current( struct gl_context *newCtx, check_init_viewport(newCtx, drawBuffer->Width, drawBuffer->Height); } + else { + _mesa_reference_framebuffer(>WinSysDrawBuffer, NULL); + _mesa_reference_framebuffer(>WinSysReadBuffer, NULL); + } if (newCtx->FirstTimeCurrent) { handle_first_current(newCtx); ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] nir: silence three compiler warnings seen with MinGW
Silence two unused var warnings. And init elem_size, elem_align to zero to silence "maybe uninitialized" warnings. --- src/compiler/nir/nir_lower_int_to_float.c | 2 +- src/compiler/nir/nir_opt_copy_prop_vars.c | 4 +--- src/compiler/nir_types.cpp| 2 +- 3 files changed, 3 insertions(+), 5 deletions(-) diff --git a/src/compiler/nir/nir_lower_int_to_float.c b/src/compiler/nir/nir_lower_int_to_float.c index 439afa0..66a740d9 100644 --- a/src/compiler/nir/nir_lower_int_to_float.c +++ b/src/compiler/nir/nir_lower_int_to_float.c @@ -28,7 +28,7 @@ static bool assert_ssa_def_is_not_int(nir_ssa_def *def, void *arg) { - BITSET_WORD *int_types = arg; + MAYBE_UNUSED BITSET_WORD *int_types = arg; assert(!BITSET_TEST(int_types, def->index)); return true; } diff --git a/src/compiler/nir/nir_opt_copy_prop_vars.c b/src/compiler/nir/nir_opt_copy_prop_vars.c index 94bc8af..0fd96b7 100644 --- a/src/compiler/nir/nir_opt_copy_prop_vars.c +++ b/src/compiler/nir/nir_opt_copy_prop_vars.c @@ -433,9 +433,7 @@ load_element_from_ssa_entry_value(struct copy_prop_var_state *state, nir_builder *b, nir_intrinsic_instr *intrin, struct value *value, unsigned index) { - const struct glsl_type *type = entry->dst->type; - unsigned num_components = glsl_get_vector_elements(type); - assert(index < num_components); + assert(index < glsl_get_vector_elements(entry->dst->type)); /* We don't have the element available, so let the instruction do the work. */ if (!entry->src.ssa.def[index]) diff --git a/src/compiler/nir_types.cpp b/src/compiler/nir_types.cpp index 3bf93c5..e2dfc40 100644 --- a/src/compiler/nir_types.cpp +++ b/src/compiler/nir_types.cpp @@ -630,7 +630,7 @@ glsl_get_natural_size_align_bytes(const struct glsl_type *type, *size = 0; *align = 0; for (unsigned i = 0; i < type->length; i++) { - unsigned elem_size, elem_align; + unsigned elem_size = 0, elem_align = 0; glsl_get_natural_size_align_bytes(type->fields.structure[i].type, _size, _align); *align = MAX2(*align, elem_align); -- 2.7.4 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] svga: clamp max_const_buffers to SVGA_MAX_CONST_BUFS
In case the device reports 15 (or more) buffers. --- src/gallium/drivers/svga/svga_screen.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/gallium/drivers/svga/svga_screen.c b/src/gallium/drivers/svga/svga_screen.c index 02c1a99..b70fd85 100644 --- a/src/gallium/drivers/svga/svga_screen.c +++ b/src/gallium/drivers/svga/svga_screen.c @@ -1079,7 +1079,8 @@ svga_screen_create(struct svga_winsys_screen *sws) /* Maximum number of constant buffers */ svgascreen->max_const_buffers = get_uint_cap(sws, SVGA3D_DEVCAP_DX_MAX_CONSTANT_BUFFERS, 1); - assert(svgascreen->max_const_buffers <= SVGA_MAX_CONST_BUFS); + svgascreen->max_const_buffers = MIN2(svgascreen->max_const_buffers, + SVGA_MAX_CONST_BUFS); screen->is_format_supported = svga_is_dx_format_supported; } -- 2.7.4 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 0/6] Update mesa state handling past VAO changes.
The series LGTM. Reviewed-by: Brian Paul On 05/12/2019 07:05 AM, mathias.froehl...@gmx.net wrote: From: Mathias Fröhlich Hi Brian, The series is a collection of comment updates and state handling cleanup past the VAO changes that went into mesa. There are two fixes for potential bugs in state handling included. There were no reports accoring that, and it does not change the outcome of intels CI. please review best Mathias Mathias Fröhlich (6): mesa/vbo: Update Comment to what is actually happening. mesa: Fix old outdated variable name in a comment. mesa: Make _mesa_set_varying_vp_inputs static in state.c. mesa: Fix test for setting the _NEW_VARYING_VP_INPUTS flag. mesa: Avoid setting _NEW_VARYING_VP_INPUTS in non fixed function mode. mesa: Set _NEW_VARYING_VP_INPUTS iff varying_vp_inputs are set. src/mesa/main/ff_fragment_shader.cpp | 2 ++ src/mesa/main/ffvertex_prog.c| 3 +++ src/mesa/main/state.c| 38 +++- src/mesa/main/state.h| 6 + src/mesa/vbo/vbo_exec_draw.c | 4 +-- 5 files changed, 27 insertions(+), 26 deletions(-) -- 2.21.0 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] st/mesa: fix uninitialized lower_flrp_progress variable
The 'progress' variable is initialized to false in other locations. This fixes a new Coverity warning. --- src/mesa/state_tracker/st_glsl_to_nir.cpp | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/mesa/state_tracker/st_glsl_to_nir.cpp b/src/mesa/state_tracker/st_glsl_to_nir.cpp index 0a67d45..5706425 100644 --- a/src/mesa/state_tracker/st_glsl_to_nir.cpp +++ b/src/mesa/state_tracker/st_glsl_to_nir.cpp @@ -338,7 +338,7 @@ st_nir_opts(nir_shader *nir, bool scalar) NIR_PASS(progress, nir, nir_opt_constant_folding); if (lower_flrp != 0) { - bool lower_flrp_progress; + bool lower_flrp_progress = false; NIR_PASS(lower_flrp_progress, nir, nir_lower_flrp, lower_flrp, -- 2.7.4 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] gallivm: fix broken 8-wide s3tc decoding
LGTM. Just two little nits below. Reviewed-by: Brian Paul Perhaps you could review the 5-patch series of clean-ups I posted on Saturday? On 05/06/2019 06:12 PM, srol...@vmware.com wrote: From: Roland Scheidegger Brian noticed there was an uninitialized var for the 8-wide case and 128 bit blocks, which made it always crash. Likewise, the 64bit block case had another crash bug due to type mismatch. Color decode (used for all s3tc formats) also had a bogus shuffle for this case, leading to decode artifacts. Fix these all up, which makes the code actually work 8-wide. Note that it's still not used - I've verified it works, and the generated assembly does look quite a bit simpler actually (20-30% less instructions for the s3tc decode part with avx2), however in practice it still seems to be sligthly slower for some unknown reason (tested with openarena) on my haswell box, so for now continue to split things into 4-wide vectors before decoding. --- .../auxiliary/gallivm/lp_bld_format_s3tc.c| 33 +-- 1 file changed, 16 insertions(+), 17 deletions(-) diff --git a/src/gallium/auxiliary/gallivm/lp_bld_format_s3tc.c b/src/gallium/auxiliary/gallivm/lp_bld_format_s3tc.c index 9561c349dad..8f6e9bec18a 100644 --- a/src/gallium/auxiliary/gallivm/lp_bld_format_s3tc.c +++ b/src/gallium/auxiliary/gallivm/lp_bld_format_s3tc.c @@ -77,24 +77,17 @@ lp_build_uninterleave2_half(struct gallivm_state *gallivm, unsigned lo_hi) { LLVMValueRef shuffle, elems[LP_MAX_VECTOR_LENGTH]; - unsigned i, j; + unsigned i; assert(type.length <= LP_MAX_VECTOR_LENGTH); assert(lo_hi < 2); if (type.length * type.width == 256) { - assert(type.length >= 4); - for (i = 0, j = 0; i < type.length; ++i) { - if (i == type.length / 4) { -j = type.length; - } else if (i == type.length / 2) { -j = type.length / 2; - } else if (i == 3 * type.length / 4) { -j = 3 * type.length / 4; - } else { -j += 2; - } - elems[i] = lp_build_const_int32(gallivm, j + lo_hi); + assert(type.length == 8); + assert(type.width == 32); + const unsigned shufvals[8] = {0, 2, 8, 10, 4, 6, 12, 14}; could be static + for (i = 0; i < type.length; ++i) { + elems[i] = lp_build_const_int32(gallivm, shufvals[i] + lo_hi); } } else { for (i = 0; i < type.length; ++i) { @@ -277,7 +270,7 @@ lp_build_gather_s3tc(struct gallivm_state *gallivm, } else { LLVMValueRef tmp[4], cc01, cc23; - struct lp_type lp_type32, lp_type64, lp_type32dxt; + struct lp_type lp_type32, lp_type64; memset(_type32, 0, sizeof lp_type32); lp_type32.width = 32; lp_type32.length = length; @@ -309,10 +302,14 @@ lp_build_gather_s3tc(struct gallivm_state *gallivm, lp_build_const_extend_shuffle(gallivm, 2, 4), ""); } if (length == 8) { +struct lp_type lp_type32_4; +memset(_type32_4, 0, sizeof lp_type32_4); Maybe we could move toward using initializers in these case? struct lp_type lp_type32_4 = {0}; ? +lp_type32_4.width = 32; +lp_type32_4.length = 4; for (i = 0; i < 4; ++i) { tmp[0] = elems[i]; tmp[1] = elems[i+4]; - elems[i] = lp_build_concat(gallivm, tmp, lp_type32, 2); + elems[i] = lp_build_concat(gallivm, tmp, lp_type32_4, 2); } } cc01 = lp_build_interleave2_half(gallivm, lp_type32, elems[0], elems[1], 0); @@ -811,7 +808,7 @@ s3tc_dxt3_to_rgba_aos(struct gallivm_state *gallivm, tmp = lp_build_select(, sel_mask, alpha_low, alpha_hi); bit_pos = LLVMBuildAnd(builder, bit_pos, lp_build_const_int_vec(gallivm, type, 0xffdf), ""); - /* Warning: slow shift with per element count */ + /* Warning: slow shift with per element count (without avx2) */ /* * Could do pshufb here as well - just use appropriate 2 bits in bit_pos * to select the right byte with pshufb. Then for the remaining one bit @@ -1640,7 +1637,6 @@ s3tc_decode_block_dxt5(struct gallivm_state *gallivm, lp_build_const_int_vec(gallivm, type16, 8), ""); alpha = LLVMBuildBitCast(builder, alpha, i64t, ""); shuffle1 = lp_build_const_shuffle1(gallivm, 0, 8); - /* XXX this shuffle broken with LLVM 2.8 */ alpha0 = LLVMBuildShuffleVector(builder, alpha0, alpha0, shuffle1, ""); alpha1 = LLVMBuildShuffleVector(builder, alpha1, alpha1, shuffle1, ""); @@ -2176,6 +2172,9 @@ lp_build_fetch_s3tc_rgba_aos(struct gallivm_state *gallivm, return rgba; } + /* +* Could use n > 8 here with avx2, but doesn't seem fast
[Mesa-dev] [PATCH 2/5] ddebug: fix a few MSVC compiler warnings
Don't return an expression in void functions. Replace an unsigned int with proper enum. --- src/gallium/auxiliary/driver_ddebug/dd_context.c | 15 --- src/gallium/auxiliary/driver_ddebug/dd_screen.c | 2 +- 2 files changed, 9 insertions(+), 8 deletions(-) diff --git a/src/gallium/auxiliary/driver_ddebug/dd_context.c b/src/gallium/auxiliary/driver_ddebug/dd_context.c index 8a3b75a..001a69f 100644 --- a/src/gallium/auxiliary/driver_ddebug/dd_context.c +++ b/src/gallium/auxiliary/driver_ddebug/dd_context.c @@ -534,7 +534,8 @@ dd_context_set_shader_images(struct pipe_context *_pipe, } static void -dd_context_set_shader_buffers(struct pipe_context *_pipe, unsigned shader, +dd_context_set_shader_buffers(struct pipe_context *_pipe, + enum pipe_shader_type shader, unsigned start, unsigned num_buffers, const struct pipe_shader_buffer *buffers, unsigned writable_bitmask) @@ -680,7 +681,7 @@ dd_context_set_compute_resources(struct pipe_context *_pipe, struct pipe_surface **resources) { struct pipe_context *pipe = dd_context(_pipe)->pipe; - return pipe->set_compute_resources(pipe, start, count, resources); + pipe->set_compute_resources(pipe, start, count, resources); } static void @@ -690,7 +691,7 @@ dd_context_set_global_binding(struct pipe_context *_pipe, uint32_t **handles) { struct pipe_context *pipe = dd_context(_pipe)->pipe; - return pipe->set_global_binding(pipe, first, count, resources, handles); + pipe->set_global_binding(pipe, first, count, resources, handles); } static void @@ -700,8 +701,8 @@ dd_context_get_sample_position(struct pipe_context *_pipe, { struct pipe_context *pipe = dd_context(_pipe)->pipe; - return pipe->get_sample_position(pipe, sample_count, sample_index, -out_value); + pipe->get_sample_position(pipe, sample_count, sample_index, + out_value); } static void @@ -727,7 +728,7 @@ dd_context_set_device_reset_callback(struct pipe_context *_pipe, { struct pipe_context *pipe = dd_context(_pipe)->pipe; - return pipe->set_device_reset_callback(pipe, cb); + pipe->set_device_reset_callback(pipe, cb); } static void @@ -747,7 +748,7 @@ dd_context_dump_debug_state(struct pipe_context *_pipe, FILE *stream, { struct pipe_context *pipe = dd_context(_pipe)->pipe; - return pipe->dump_debug_state(pipe, stream, flags); + pipe->dump_debug_state(pipe, stream, flags); } static uint64_t diff --git a/src/gallium/auxiliary/driver_ddebug/dd_screen.c b/src/gallium/auxiliary/driver_ddebug/dd_screen.c index ce9f697..f3bd079 100644 --- a/src/gallium/auxiliary/driver_ddebug/dd_screen.c +++ b/src/gallium/auxiliary/driver_ddebug/dd_screen.c @@ -126,7 +126,7 @@ static void dd_screen_query_memory_info(struct pipe_screen *_screen, { struct pipe_screen *screen = dd_screen(_screen)->screen; - return screen->query_memory_info(screen, info); + screen->query_memory_info(screen, info); } static struct pipe_context * -- 1.8.5.6 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/5] glsl: s/GLboolean/bool/ to silence MSVC compiler warning
It complains about mixing GLboolean and bool in the |= expression. --- src/compiler/glsl/glsl_parser_extras.cpp | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/compiler/glsl/glsl_parser_extras.cpp b/src/compiler/glsl/glsl_parser_extras.cpp index d99ab3d..41f2a97 100644 --- a/src/compiler/glsl/glsl_parser_extras.cpp +++ b/src/compiler/glsl/glsl_parser_extras.cpp @@ -2226,7 +2226,7 @@ do_common_optimization(exec_list *ir, bool linked, bool native_integers) { const bool debug = false; - GLboolean progress = GL_FALSE; + bool progress = false; #define OPT(PASS, ...) do { \ if (debug) { \ -- 1.8.5.6 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 4/5] gallium/pp: s/uint/enum tgsi_semantic/ to fix MSVC warning
--- src/gallium/auxiliary/postprocess/pp_program.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/gallium/auxiliary/postprocess/pp_program.c b/src/gallium/auxiliary/postprocess/pp_program.c index 52786de..4cd3990 100644 --- a/src/gallium/auxiliary/postprocess/pp_program.c +++ b/src/gallium/auxiliary/postprocess/pp_program.c @@ -126,7 +126,7 @@ pp_init_prog(struct pp_queue_t *ppq, struct pipe_context *pipe, { - const uint semantic_names[] = { TGSI_SEMANTIC_POSITION, + const enum tgsi_semantic semantic_names[] = { TGSI_SEMANTIC_POSITION, TGSI_SEMANTIC_GENERIC }; const uint semantic_indexes[] = { 0, 0 }; -- 1.8.5.6 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 3/5] noop: s/enum pipe_transfer_usage/unsigned/ to fix MSVC warning
The function pointer declaration in pipe_context uses unsigned for the bitmask. --- src/gallium/auxiliary/driver_noop/noop_pipe.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/gallium/auxiliary/driver_noop/noop_pipe.c b/src/gallium/auxiliary/driver_noop/noop_pipe.c index a6497f0..2a4d3eb 100644 --- a/src/gallium/auxiliary/driver_noop/noop_pipe.c +++ b/src/gallium/auxiliary/driver_noop/noop_pipe.c @@ -172,7 +172,7 @@ static void noop_resource_destroy(struct pipe_screen *screen, static void *noop_transfer_map(struct pipe_context *pipe, struct pipe_resource *resource, unsigned level, - enum pipe_transfer_usage usage, + unsigned usage, const struct pipe_box *box, struct pipe_transfer **ptransfer) { -- 1.8.5.6 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 5/5] gallium/util: fix two MSVC compiler warnings
Remove stray const qualifier. s/unsigned/enum tgsi_semantic/ --- src/gallium/auxiliary/util/u_format_zs.h | 2 +- src/gallium/auxiliary/util/u_simple_shaders.c | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/src/gallium/auxiliary/util/u_format_zs.h b/src/gallium/auxiliary/util/u_format_zs.h index 160919d..bed3c51 100644 --- a/src/gallium/auxiliary/util/u_format_zs.h +++ b/src/gallium/auxiliary/util/u_format_zs.h @@ -113,7 +113,7 @@ void util_format_z24_unorm_s8_uint_pack_s_8uint(uint8_t *dst_row, unsigned dst_stride, const uint8_t *src_row, unsigned src_stride, unsigned width, unsigned height); void -util_format_z24_unorm_s8_uint_pack_separate(uint8_t *dst_row, unsigned dst_stride, const uint32_t *z_src_row, unsigned z_src_stride, const uint8_t *s_src_row, unsigned s_src_stride, const unsigned width, unsigned height); +util_format_z24_unorm_s8_uint_pack_separate(uint8_t *dst_row, unsigned dst_stride, const uint32_t *z_src_row, unsigned z_src_stride, const uint8_t *s_src_row, unsigned s_src_stride, unsigned width, unsigned height); void util_format_s8_uint_z24_unorm_unpack_z_float(float *dst_row, unsigned dst_stride, const uint8_t *src_row, unsigned src_stride, unsigned width, unsigned height); diff --git a/src/gallium/auxiliary/util/u_simple_shaders.c b/src/gallium/auxiliary/util/u_simple_shaders.c index 4046ab1..d62a655 100644 --- a/src/gallium/auxiliary/util/u_simple_shaders.c +++ b/src/gallium/auxiliary/util/u_simple_shaders.c @@ -117,8 +117,8 @@ util_make_vertex_passthrough_shader_with_so(struct pipe_context *pipe, void *util_make_layered_clear_vertex_shader(struct pipe_context *pipe) { - const unsigned semantic_names[] = {TGSI_SEMANTIC_POSITION, - TGSI_SEMANTIC_GENERIC}; + const enum tgsi_semantic semantic_names[] = {TGSI_SEMANTIC_POSITION, +TGSI_SEMANTIC_GENERIC}; const unsigned semantic_indices[] = {0, 0}; return util_make_vertex_passthrough_shader_with_so(pipe, 2, semantic_names, -- 1.8.5.6 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] nir/algebraic: Don't emit empty arrays for MSVC
Just don't emit the transform array at all if there are no transforms for a state, and avoid trying to walk over it. Original patch by Connor Abbott. Updated with suggestions by Dylan Baker. --- src/compiler/nir/nir_algebraic.py | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/src/compiler/nir/nir_algebraic.py b/src/compiler/nir/nir_algebraic.py index 6db749e..da5e39c 100644 --- a/src/compiler/nir/nir_algebraic.py +++ b/src/compiler/nir/nir_algebraic.py @@ -993,11 +993,13 @@ static const uint16_t CONST_STATE = 1; % endfor % for state_id, state_xforms in enumerate(automaton.state_patterns): +% if state_xforms: # avoid emitting a 0-length array for MSVC static const struct transform ${pass_name}_state${state_id}_xforms[] = { % for i in state_xforms: { ${xforms[i].search.c_ptr(cache)}, ${xforms[i].replace.c_value_ptr(cache)}, ${xforms[i].condition_index} }, % endfor }; +% endif % endfor static const struct per_op_table ${pass_name}_table[nir_num_search_ops] = { @@ -1080,7 +1082,8 @@ ${pass_name}_block(nir_builder *build, nir_block *block, switch (states[alu->dest.dest.ssa.index]) { % for i in range(len(automaton.state_patterns)): case ${i}: - for (unsigned i = 0; i < ARRAY_SIZE(${pass_name}_state${i}_xforms); i++) { + % if automaton.state_patterns[i]: + for (unsigned i = 0; i < ${len(automaton.state_patterns[i])}; i++) { const struct transform *xform = &${pass_name}_state${i}_xforms[i]; if (condition_flags[xform->condition_offset] && nir_replace_instr(build, alu, xform->search, xform->replace)) { @@ -1088,6 +1091,7 @@ ${pass_name}_block(nir_builder *build, nir_block *block, break; } } + % endif break; % endfor default: assert(0); -- 2.7.4 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 03/10] mesa: Implement _mesa_array_element by walking enabled arrays.
On 05/02/2019 11:18 PM, Mathias Fröhlich wrote: Hi Brian, On Friday, 3 May 2019 00:17:51 CEST Brian Paul wrote: On 05/02/2019 03:27 AM, mathias.froehl...@gmx.net wrote: From: Mathias Fröhlich In glArrayElement, use the bitmask trick to just walk the enabled vao arrays. This should be about equivalent in execution time to walk the prepare aelt_context list. Finally this will allow us to reduce the _mesa_update_state calls in a few patches. Signed-off-by: Mathias Fröhlich --- src/mesa/main/api_arrayelt.c | 78 1 file changed, 61 insertions(+), 17 deletions(-) diff --git a/src/mesa/main/api_arrayelt.c b/src/mesa/main/api_arrayelt.c index d46c8d14b68..62f1e73ca4c 100644 --- a/src/mesa/main/api_arrayelt.c +++ b/src/mesa/main/api_arrayelt.c @@ -1541,32 +1541,76 @@ _ae_update_state(struct gl_context *ctx) } +static inline attrib_func +func_nv(const struct gl_vertex_format *vformat) +{ + return AttribFuncsNV[vformat->Normalized][vformat->Size-1] + [TYPE_IDX(vformat->Type)]; +} + + +static inline attrib_func +func_arb(const struct gl_vertex_format *vformat) +{ + return AttribFuncsARB[NORM_IDX(vformat)][vformat->Size-1] + [TYPE_IDX(vformat->Type)]; +} + + +static inline const void * +attrib_src(const struct gl_vertex_array_object *vao, + const struct gl_array_attributes *array, GLint elt) +{ + const struct gl_vertex_buffer_binding *binding = + >BufferBinding[array->BufferBindingIndex]; + const GLubyte *src + = ADD_POINTERS(binding->BufferObj->Mappings[MAP_INTERNAL].Pointer, + _mesa_vertex_attrib_address(array, binding)) + + elt * binding->Stride; + return src; +} Could you add some brief comments on those functions to explain what they do? Added brief comments: /* * Return VertexAttrib*NV function pointer matching the provided vertex format. */ static inline attrib_func func_nv(const struct gl_vertex_format *vformat) [...] /* * Return VertexAttrib*ARB function pointer matching the provided vertex format. */ static inline attrib_func func_arb(const struct gl_vertex_format *vformat) [...] /* * Return the address of the array attribute array at elt in the * vertex array object vao. */ static inline const void * attrib_src(const struct gl_vertex_array_object *vao, const struct gl_array_attributes *array, GLint elt) Otherwise, for the rest of the series, Reviewed-by: Brian Paul Nice work!! Thanks for looking at the patches! All your suggested changes look good. Reviewed-by: Brian Paul Thanks. -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 03/10] mesa: Implement _mesa_array_element by walking enabled arrays.
On 05/02/2019 03:27 AM, mathias.froehl...@gmx.net wrote: From: Mathias Fröhlich In glArrayElement, use the bitmask trick to just walk the enabled vao arrays. This should be about equivalent in execution time to walk the prepare aelt_context list. Finally this will allow us to reduce the _mesa_update_state calls in a few patches. Signed-off-by: Mathias Fröhlich --- src/mesa/main/api_arrayelt.c | 78 1 file changed, 61 insertions(+), 17 deletions(-) diff --git a/src/mesa/main/api_arrayelt.c b/src/mesa/main/api_arrayelt.c index d46c8d14b68..62f1e73ca4c 100644 --- a/src/mesa/main/api_arrayelt.c +++ b/src/mesa/main/api_arrayelt.c @@ -1541,32 +1541,76 @@ _ae_update_state(struct gl_context *ctx) } +static inline attrib_func +func_nv(const struct gl_vertex_format *vformat) +{ + return AttribFuncsNV[vformat->Normalized][vformat->Size-1] + [TYPE_IDX(vformat->Type)]; +} + + +static inline attrib_func +func_arb(const struct gl_vertex_format *vformat) +{ + return AttribFuncsARB[NORM_IDX(vformat)][vformat->Size-1] + [TYPE_IDX(vformat->Type)]; +} + + +static inline const void * +attrib_src(const struct gl_vertex_array_object *vao, + const struct gl_array_attributes *array, GLint elt) +{ + const struct gl_vertex_buffer_binding *binding = + >BufferBinding[array->BufferBindingIndex]; + const GLubyte *src + = ADD_POINTERS(binding->BufferObj->Mappings[MAP_INTERNAL].Pointer, + _mesa_vertex_attrib_address(array, binding)) + + elt * binding->Stride; + return src; +} Could you add some brief comments on those functions to explain what they do? Otherwise, for the rest of the series, Reviewed-by: Brian Paul Nice work!! -Brian + + void _mesa_array_element(struct gl_context *ctx, struct _glapi_table *disp, GLint elt) { - const AEcontext *actx = AE_CONTEXT(ctx); + const struct gl_vertex_array_object *vao = ctx->Array.VAO; + GLbitfield mask; - if (actx->dirty_state) - _ae_update_state(ctx); + /* emit conventional arrays elements */ + mask = (VERT_BIT_FF_ALL & ~VERT_BIT_POS) & vao->Enabled; + while (mask) { + const gl_vert_attrib attrib = u_bit_scan(); + const struct gl_array_attributes *array = >VertexAttrib[attrib]; + const void *src = attrib_src(vao, array, elt); + func_nv(>Format)(attrib, src); + } /* emit generic attribute elements */ - for (const AEattrib *at = actx->attribs; at->func; at++) { - const GLubyte *src - = ADD_POINTERS(at->binding->BufferObj->Mappings[MAP_INTERNAL].Pointer, -_mesa_vertex_attrib_address(at->array, at->binding)) - + elt * at->binding->Stride; - at->func(at->index, src); + mask = (VERT_BIT_GENERIC_ALL & ~VERT_BIT_GENERIC0) & vao->Enabled; + while (mask) { + const gl_vert_attrib attrib = u_bit_scan(); + const struct gl_array_attributes *array = >VertexAttrib[attrib]; + const void *src = attrib_src(vao, array, elt); + func_arb(>Format)(attrib - VERT_ATTRIB_GENERIC0, src); } - /* emit conventional arrays elements */ - for (const AEarray *aa = actx->arrays; aa->offset != -1 ; aa++) { - const GLubyte *src - = ADD_POINTERS(aa->binding->BufferObj->Mappings[MAP_INTERNAL].Pointer, -_mesa_vertex_attrib_address(aa->array, aa->binding)) - + elt * aa->binding->Stride; - CALL_by_offset(disp, (array_func), aa->offset, ((const void *) src)); - } + /* finally, vertex position */ + if (vao->Enabled & VERT_BIT_GENERIC0) { + const gl_vert_attrib attrib = VERT_ATTRIB_GENERIC0; + const struct gl_array_attributes *array = >VertexAttrib[attrib]; + const void *src = attrib_src(vao, array, elt); + /* Use glVertex(v) instead of glVertexAttrib(0, v) to be sure it's + * issued as the last (provoking) attribute). + */ + func_nv(>Format)(0, src); + } else if (vao->Enabled & VERT_BIT_POS) { + const gl_vert_attrib attrib = VERT_ATTRIB_POS; + const struct gl_array_attributes *array = >VertexAttrib[attrib]; + const void *src = attrib_src(vao, array, elt); + func_nv(>Format)(0, src); +} } -- 2.20.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 01/10] mesa: Factor out index function that will have multiple use.
On 05/02/2019 03:27 AM, mathias.froehl...@gmx.net wrote: From: Mathias Fröhlich For access to glArrayElement methods factor out a function to get the table lookup index for normalized/integer/double access. The function will be used in the next patch at least twice. Signed-off-by: Mathias Fröhlich --- src/mesa/main/api_arrayelt.c | 29 ++--- 1 file changed, 18 insertions(+), 11 deletions(-) diff --git a/src/mesa/main/api_arrayelt.c b/src/mesa/main/api_arrayelt.c index 1c086bbcda4..3f16e18b44d 100644 --- a/src/mesa/main/api_arrayelt.c +++ b/src/mesa/main/api_arrayelt.c @@ -90,6 +90,23 @@ TYPE_IDX(GLenum t) } +/* + * Convert normalized/integer/double to the range [0, 3]. + */ +static inline int +NORM_IDX(const struct gl_vertex_format *vformat) Maybe we could find a better name. How about vertex_format_to_index()? -Brian +{ + if (vformat->Doubles) + return 3; + else if (vformat->Integer) + return 2; + else if (vformat->Normalized) + return 1; + else + return 0; +} + + bool _ae_is_state_dirty(struct gl_context *ctx) { @@ -1610,7 +1627,6 @@ _ae_update_state(struct gl_context *ctx) if (vao->Enabled & VERT_BIT_GENERIC(i)) { struct gl_array_attributes *attribArray = >VertexAttrib[VERT_ATTRIB_GENERIC(i)]; - GLint intOrNorm; at->array = attribArray; at->binding = >BufferBinding[attribArray->BufferBindingIndex]; /* Note: we can't grab the _glapi_Dispatch->VertexAttrib1fvNV @@ -1618,16 +1634,7 @@ _ae_update_state(struct gl_context *ctx) * change from one execution of _ae_ArrayElement() to * the next. Doing so caused UT to break. */ - if (at->array->Format.Doubles) -intOrNorm = 3; - else if (at->array->Format.Integer) -intOrNorm = 2; - else if (at->array->Format.Normalized) -intOrNorm = 1; - else -intOrNorm = 0; - - at->func = AttribFuncsARB[intOrNorm] + at->func = AttribFuncsARB[NORM_IDX(>array->Format)] [at->array->Format.Size-1] [TYPE_IDX(at->array->Format.Type)]; -- 2.20.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 02/10] mesa: Use glVertexAttrib*NV functions for fixed function attribs.
On 05/02/2019 03:27 AM, mathias.froehl...@gmx.net wrote: From: Mathias Fröhlich In the glArrayElement implementation, use glVertexAttrib*NV type functions for fixed function attributes. We do the same in display execution when the list is replayed using immediate mode attribute functions. By that use a loop to walk the attributes. I'm not sure I understand that last sentence. The code looks fine. Reviewed-by: Brian Paul Signed-off-by: Mathias Fröhlich --- src/mesa/main/api_arrayelt.c | 185 ++- 1 file changed, 28 insertions(+), 157 deletions(-) diff --git a/src/mesa/main/api_arrayelt.c b/src/mesa/main/api_arrayelt.c index 3f16e18b44d..d46c8d14b68 100644 --- a/src/mesa/main/api_arrayelt.c +++ b/src/mesa/main/api_arrayelt.c @@ -117,89 +117,6 @@ _ae_is_state_dirty(struct gl_context *ctx) #define NUM_TYPES 8 -static const int ColorFuncs[2][NUM_TYPES] = { - { - _gloffset_Color3bv, - _gloffset_Color3ubv, - _gloffset_Color3sv, - _gloffset_Color3usv, - _gloffset_Color3iv, - _gloffset_Color3uiv, - _gloffset_Color3fv, - _gloffset_Color3dv, - }, - { - _gloffset_Color4bv, - _gloffset_Color4ubv, - _gloffset_Color4sv, - _gloffset_Color4usv, - _gloffset_Color4iv, - _gloffset_Color4uiv, - _gloffset_Color4fv, - _gloffset_Color4dv, - }, -}; - -static const int VertexFuncs[3][NUM_TYPES] = { - { - -1, - -1, - _gloffset_Vertex2sv, - -1, - _gloffset_Vertex2iv, - -1, - _gloffset_Vertex2fv, - _gloffset_Vertex2dv, - }, - { - -1, - -1, - _gloffset_Vertex3sv, - -1, - _gloffset_Vertex3iv, - -1, - _gloffset_Vertex3fv, - _gloffset_Vertex3dv, - }, - { - -1, - -1, - _gloffset_Vertex4sv, - -1, - _gloffset_Vertex4iv, - -1, - _gloffset_Vertex4fv, - _gloffset_Vertex4dv, - }, -}; - -static const int IndexFuncs[NUM_TYPES] = { - -1, - _gloffset_Indexubv, - _gloffset_Indexsv, - -1, - _gloffset_Indexiv, - -1, - _gloffset_Indexfv, - _gloffset_Indexdv, -}; - -static const int NormalFuncs[NUM_TYPES] = { - _gloffset_Normal3bv, - -1, - _gloffset_Normal3sv, - -1, - _gloffset_Normal3iv, - -1, - _gloffset_Normal3fv, - _gloffset_Normal3dv, -}; - -/* Note: _gloffset_* for these may not be a compile-time constant. */ -static int SecondaryColorFuncs[NUM_TYPES]; -static int FogCoordFuncs[NUM_TYPES]; - - /** ** GL_NV_vertex_program **/ @@ -1508,25 +1425,6 @@ _ae_create_context(struct gl_context *ctx) if (ctx->aelt_context) return GL_TRUE; - /* These _gloffset_* values may not be compile-time constants */ - SecondaryColorFuncs[0] = _gloffset_SecondaryColor3bv; - SecondaryColorFuncs[1] = _gloffset_SecondaryColor3ubv; - SecondaryColorFuncs[2] = _gloffset_SecondaryColor3sv; - SecondaryColorFuncs[3] = _gloffset_SecondaryColor3usv; - SecondaryColorFuncs[4] = _gloffset_SecondaryColor3iv; - SecondaryColorFuncs[5] = _gloffset_SecondaryColor3uiv; - SecondaryColorFuncs[6] = _gloffset_SecondaryColor3fvEXT; - SecondaryColorFuncs[7] = _gloffset_SecondaryColor3dv; - - FogCoordFuncs[0] = -1; - FogCoordFuncs[1] = -1; - FogCoordFuncs[2] = -1; - FogCoordFuncs[3] = -1; - FogCoordFuncs[4] = -1; - FogCoordFuncs[5] = -1; - FogCoordFuncs[6] = _gloffset_FogCoordfvEXT; - FogCoordFuncs[7] = _gloffset_FogCoorddv; - ctx->aelt_context = calloc(1, sizeof(AEcontext)); if (!ctx->aelt_context) return GL_FALSE; @@ -1562,52 +1460,10 @@ _ae_update_state(struct gl_context *ctx) struct gl_vertex_array_object *vao = ctx->Array.VAO; /* conventional vertex arrays */ - if (vao->Enabled & VERT_BIT_COLOR_INDEX) { - aa->array = >VertexAttrib[VERT_ATTRIB_COLOR_INDEX]; - aa->binding = >BufferBinding[aa->array->BufferBindingIndex]; - aa->offset = IndexFuncs[TYPE_IDX(aa->array->Format.Type)]; - aa++; - } - - if (vao->Enabled & VERT_BIT_EDGEFLAG) { - aa->array = >VertexAttrib[VERT_ATTRIB_EDGEFLAG]; - aa->binding = >BufferBinding[aa->array->BufferBindingIndex]; - aa->offset = _gloffset_EdgeFlagv; - aa++; - } - - if (vao->Enabled & VERT_BIT_NORMAL) { - aa->array = >VertexAttrib[VERT_ATTRIB_NORMAL]; - aa->binding = >BufferBinding[aa->array->BufferBindingIndex]; - aa->offset = NormalFuncs[TYPE_IDX(aa->array->Format.Type)]; - aa++; - } - - if (vao->Enabled & VERT_BIT_COLOR0) { - aa->array = >VertexAttrib[VERT_ATTRIB_COLOR0]; - aa->binding = >BufferBinding[aa->array->BufferBindingIndex]; - aa->offset = ColorFuncs[aa->array->Format.Size-3][TYPE_IDX(aa->array->Format.Type)]; - aa++; - } - - if (vao->Enabled & VERT_BIT_COLOR1) { - aa->array = >VertexAttrib[VERT_ATTRIB_
Re: [Mesa-dev] [PATCH] nir/algebraic: Don't emit empty initializers for MSVC
On 05/02/2019 02:34 PM, Connor Abbott wrote: Just don't emit the transform array at all if there are no transforms for a state, and avoid trying to walk over it. --- Brian, does this build on Windows? I tested it on my shader-db on radeonsi. Yes, it compiles. Thanks! Tested-by: Brian Paul Though it looks like Dylan had some suggestions. -Brian --- src/compiler/nir/nir_algebraic.py | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/src/compiler/nir/nir_algebraic.py b/src/compiler/nir/nir_algebraic.py index 6db749e9248..7af80a4f92e 100644 --- a/src/compiler/nir/nir_algebraic.py +++ b/src/compiler/nir/nir_algebraic.py @@ -993,11 +993,13 @@ static const uint16_t CONST_STATE = 1; % endfor % for state_id, state_xforms in enumerate(automaton.state_patterns): +% if len(state_xforms) > 0: # avoid emitting a 0-length array for MSVC static const struct transform ${pass_name}_state${state_id}_xforms[] = { % for i in state_xforms: { ${xforms[i].search.c_ptr(cache)}, ${xforms[i].replace.c_value_ptr(cache)}, ${xforms[i].condition_index} }, % endfor }; +% endif % endfor static const struct per_op_table ${pass_name}_table[nir_num_search_ops] = { @@ -1080,7 +1082,8 @@ ${pass_name}_block(nir_builder *build, nir_block *block, switch (states[alu->dest.dest.ssa.index]) { % for i in range(len(automaton.state_patterns)): case ${i}: - for (unsigned i = 0; i < ARRAY_SIZE(${pass_name}_state${i}_xforms); i++) { + % if len(automaton.state_patterns[i]) > 0: + for (unsigned i = 0; i < ${len(automaton.state_patterns[i])}; i++) { const struct transform *xform = &${pass_name}_state${i}_xforms[i]; if (condition_flags[xform->condition_offset] && nir_replace_instr(build, alu, xform->search, xform->replace)) { @@ -1088,6 +1091,7 @@ ${pass_name}_block(nir_builder *build, nir_block *block, break; } } + % endif break; % endfor default: assert(0); ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] nir: don't emit empty initializers for MSVC
On 05/02/2019 01:35 PM, Connor Abbott wrote: This will crash at runtime, since it'll construct a "struct transform" with all NULL pointers, and then the loop below in ${pass_name}_block() will see that there's one transform in the array since it uses ARRAY_SIZE and then crash trying to access it. Hmm, any ideas for how to fix this? -Brian Running piglit with i965, or radeonsi will reproduce the crash. On Thu, May 2, 2019 at 7:52 PM Brian Paul <mailto:bri...@vmware.com>> wrote: This fixes a build failure with MSVC. --- I've compiled tested this, but not sure how to runtime test it. --- src/compiler/nir/nir_algebraic.py | 3 +++ 1 file changed, 3 insertions(+) diff --git a/src/compiler/nir/nir_algebraic.py b/src/compiler/nir/nir_algebraic.py index 6db749e..dc25421 100644 --- a/src/compiler/nir/nir_algebraic.py +++ b/src/compiler/nir/nir_algebraic.py @@ -997,6 +997,9 @@ static const struct transform ${pass_name}_state${state_id}_xforms[] = { % for i in state_xforms: { ${xforms[i].search.c_ptr(cache)}, ${xforms[i].replace.c_value_ptr(cache)}, ${xforms[i].condition_index} }, % endfor +% if state_xforms == []: # avoid empty initializers for MSVC + 0 +% endif }; % endfor -- 2.7.4 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org <mailto:mesa-dev@lists.freedesktop.org> https://lists.freedesktop.org/mailman/listinfo/mesa-dev <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Fmesa-dev=02%7C01%7Cbrianp%40vmware.com%7C9a2c222ad2db4e0696b908d6cf355dca%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C636924225451191768=TIk8%2BIqORtPKOvvdeJM2Yo4sMgpk3m97T2WZIKLYdxg%3D=0> ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] nir: don't emit empty initializers for MSVC
This fixes a build failure with MSVC. --- I've compiled tested this, but not sure how to runtime test it. --- src/compiler/nir/nir_algebraic.py | 3 +++ 1 file changed, 3 insertions(+) diff --git a/src/compiler/nir/nir_algebraic.py b/src/compiler/nir/nir_algebraic.py index 6db749e..dc25421 100644 --- a/src/compiler/nir/nir_algebraic.py +++ b/src/compiler/nir/nir_algebraic.py @@ -997,6 +997,9 @@ static const struct transform ${pass_name}_state${state_id}_xforms[] = { % for i in state_xforms: { ${xforms[i].search.c_ptr(cache)}, ${xforms[i].replace.c_value_ptr(cache)}, ${xforms[i].condition_index} }, % endfor +% if state_xforms == []: # avoid empty initializers for MSVC + 0 +% endif }; % endfor -- 2.7.4 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/2] svga: move host logging to winsys
From: Charmaine Lee This patch adds a host_log interface to svga_winsys and moves the host logging code to the winsys layer. Reviewed-by: Brian Paul --- src/gallium/drivers/svga/Makefile.sources | 2 - src/gallium/drivers/svga/meson.build | 1 - src/gallium/drivers/svga/svga_msg.c | 451 -- src/gallium/drivers/svga/svga_msg.h | 42 --- src/gallium/drivers/svga/svga_screen.c| 12 +- src/gallium/drivers/svga/svga_winsys.h| 5 + src/gallium/winsys/svga/drm/Makefile.sources | 2 + src/gallium/winsys/svga/drm/meson.build | 1 + src/gallium/winsys/svga/drm/vmw_msg.c | 448 + src/gallium/winsys/svga/drm/vmw_msg.h | 41 +++ src/gallium/winsys/svga/drm/vmw_screen_svga.c | 3 + 11 files changed, 506 insertions(+), 502 deletions(-) delete mode 100755 src/gallium/drivers/svga/svga_msg.c delete mode 100644 src/gallium/drivers/svga/svga_msg.h create mode 100644 src/gallium/winsys/svga/drm/vmw_msg.c create mode 100644 src/gallium/winsys/svga/drm/vmw_msg.h diff --git a/src/gallium/drivers/svga/Makefile.sources b/src/gallium/drivers/svga/Makefile.sources index 72024cf..229d286 100644 --- a/src/gallium/drivers/svga/Makefile.sources +++ b/src/gallium/drivers/svga/Makefile.sources @@ -15,8 +15,6 @@ C_SOURCES := \ svga_hw_reg.h \ svga_link.c \ svga_link.h \ - svga_msg.c \ - svga_msg.h \ svga_mksstats.h \ svga_pipe_blend.c \ svga_pipe_blit.c \ diff --git a/src/gallium/drivers/svga/meson.build b/src/gallium/drivers/svga/meson.build index 7981e29..4d3207a 100644 --- a/src/gallium/drivers/svga/meson.build +++ b/src/gallium/drivers/svga/meson.build @@ -27,7 +27,6 @@ files_svga = files( 'svga_draw_elements.c', 'svga_format.c', 'svga_link.c', - 'svga_msg.c', 'svga_pipe_blend.c', 'svga_pipe_blit.c', 'svga_pipe_clear.c', diff --git a/src/gallium/drivers/svga/svga_msg.c b/src/gallium/drivers/svga/svga_msg.c deleted file mode 100755 index 8b63132..000 --- a/src/gallium/drivers/svga/svga_msg.c +++ /dev/null @@ -1,451 +0,0 @@ -/* - * Copyright © 2016 VMware, Inc., Palo Alto, CA., USA - * All Rights Reserved. - * - * Permission is hereby granted, free of charge, to any person obtaining a - * copy of this software and associated documentation files (the - * "Software"), to deal in the Software without restriction, including - * without limitation the rights to use, copy, modify, merge, publish, - * distribute, sub license, and/or sell copies of the Software, and to - * permit persons to whom the Software is furnished to do so, subject to - * the following conditions: - * - * The above copyright notice and this permission notice (including the - * next paragraph) shall be included in all copies or substantial portions - * of the Software. - * - * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR - * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, - * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL - * THE COPYRIGHT HOLDERS, AUTHORS AND/OR ITS SUPPLIERS BE LIABLE FOR ANY CLAIM, - * DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR - * OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE - * USE OR OTHER DEALINGS IN THE SOFTWARE. - * - */ - -#include "util/u_math.h" /* for MAX2/MIN2 */ -#include "util/u_debug.h" -#include "util/u_memory.h" -#include "util/u_string.h" -#include "pipe/p_defines.h" -#include "svga_msg.h" - - -#define MESSAGE_STATUS_SUCCESS 0x0001 -#define MESSAGE_STATUS_DORECV 0x0002 -#define MESSAGE_STATUS_CPT 0x0010 -#define MESSAGE_STATUS_HB 0x0080 - -#define RPCI_PROTOCOL_NUM 0x49435052 -#define GUESTMSG_FLAG_COOKIE0x8000 - -#define RETRIES 3 - -#define VMW_HYPERVISOR_MAGIC0x564D5868 -#define VMW_HYPERVISOR_PORT 0x5658 -#define VMW_HYPERVISOR_HB_PORT 0x5659 - -#define VMW_PORT_CMD_MSG30 -#define VMW_PORT_CMD_HB_MSG 0 -#define VMW_PORT_CMD_OPEN_CHANNEL (MSG_TYPE_OPEN << 16 | VMW_PORT_CMD_MSG) -#define VMW_PORT_CMD_CLOSE_CHANNEL (MSG_TYPE_CLOSE << 16 | VMW_PORT_CMD_MSG) -#define VMW_PORT_CMD_SENDSIZE (MSG_TYPE_SENDSIZE << 16 | VMW_PORT_CMD_MSG) -#define VMW_PORT_CMD_RECVSIZE (MSG_TYPE_RECVSIZE << 16 | VMW_PORT_CMD_MSG) -#define VMW_PORT_CMD_RECVSTATUS (MSG_TYPE_RECVSTATUS << 16 | VMW_PORT_CMD_MSG) - -#define HIGH_WORD(X) ((X & 0x) >> 16) - - -#if defined(PIPE_CC_GCC) && (PIPE_CC_GCC_VERSION > 502) - -/** - * Hypervisor-specific bi-directional communication channel. Should never - * execute on bare metal hardware. The caller must make sure to check for - * supported hypervisor before using these macros. - * - * The last two parameters are both input and output and must be initia
[Mesa-dev] [PATCH 2/2] svga: add SVGA_NO_LOGGING env var (v2)
valgrind crashes when we try to initialize host logging. This env var can be used to disable logging. v2: rebase onto "svga: move host logging to winsys". Cc: mesa-sta...@lists.freedesktop.org --- docs/envvars.html | 3 +++ src/gallium/drivers/svga/svga_screen.c | 16 +++- 2 files changed, 18 insertions(+), 1 deletion(-) diff --git a/docs/envvars.html b/docs/envvars.html index c9733e6..43d3a6c 100644 --- a/docs/envvars.html +++ b/docs/envvars.html @@ -338,6 +338,9 @@ See src/mesa/state_tracker/st_debug.c for other options. for details. SVGA_EXTRA_LOGGING - if set, enables extra logging to the vmware.log file, such as the OpenGL program's name and command line arguments. +SVGA_NO_LOGGING - if set, disables logging to the vmware.log file. +This is useful when using Valgrind because it otherwise crashes when +initializing the host log feature. See the driver code for other, lesser-used variables. diff --git a/src/gallium/drivers/svga/svga_screen.c b/src/gallium/drivers/svga/svga_screen.c index 664b9bf..f747ff7 100644 --- a/src/gallium/drivers/svga/svga_screen.c +++ b/src/gallium/drivers/svga/svga_screen.c @@ -917,6 +917,16 @@ init_logging(struct pipe_screen *screen) } +/** + * no-op logging function to use when SVGA_NO_LOGGING is set. + */ +static void +nop_host_log(struct svga_winsys_screen *sws, const char *message) +{ + /* nothing */ +} + + static void svga_destroy_screen( struct pipe_screen *screen ) { @@ -1134,7 +1144,11 @@ svga_screen_create(struct svga_winsys_screen *sws) svga_screen_cache_init(svgascreen); - init_logging(screen); + if (debug_get_bool_option("SVGA_NO_LOGGING", FALSE) == TRUE) { + svgascreen->sws->host_log = nop_host_log; + } else { + init_logging(screen); + } return screen; error2: -- 1.8.5.6 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] glsl: work around MinGW 7.x compiler bug
I'm not sure what triggered this, but building with scons platform=windows toolchain=crossmingw machine=x86 build=profile with MinGW g++ 7.3 or 7.4 causes an internal compiler error. We can work around it by forcing -O1 optimization. --- src/compiler/glsl/builtin_variables.cpp | 15 +++ 1 file changed, 15 insertions(+) diff --git a/src/compiler/glsl/builtin_variables.cpp b/src/compiler/glsl/builtin_variables.cpp index 17ee80c..1b9963a 100644 --- a/src/compiler/glsl/builtin_variables.cpp +++ b/src/compiler/glsl/builtin_variables.cpp @@ -21,6 +21,21 @@ * DEALINGS IN THE SOFTWARE. */ + +/** + * Building this file with MinGW g++ 7.3 or 7.4 with: + * scons platform=windows toolchain=crossmingw machine=x86 build=profile + * triggers an internal compiler error. + * Overriding the optimization level to -O1 works around the issue. + * MinGW 5.3.1 does not seem to have the bug, neither does 8.3. So for now + * we're simply testing for version 7.x here. + */ +#if defined(__MINGW32__) && __GNUC__ == 7 +#warning "disabling optimizations for this file to work around compiler bug in MiGW gcc 7.x" +#pragma GCC optimize("O1") +#endif + + #include "ir.h" #include "ir_builder.h" #include "linker.h" -- 1.8.5.6 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] llvmpipe: init some vars to NULL to silence MinGW compiler warnings
--- src/gallium/auxiliary/gallivm/lp_bld_format_s3tc.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/gallium/auxiliary/gallivm/lp_bld_format_s3tc.c b/src/gallium/auxiliary/gallivm/lp_bld_format_s3tc.c index 9561c34..90b2be9 100644 --- a/src/gallium/auxiliary/gallivm/lp_bld_format_s3tc.c +++ b/src/gallium/auxiliary/gallivm/lp_bld_format_s3tc.c @@ -2191,7 +2191,7 @@ lp_build_fetch_s3tc_rgba_aos(struct gallivm_state *gallivm, rgba = LLVMGetUndef(i128_vectype); for (count = 0; count < n / 4; count++) { - LLVMValueRef colors, codewords, alpha_lo, alpha_hi; + LLVMValueRef colors, codewords, alpha_lo = NULL, alpha_hi = NULL; i4 = lp_build_extract_range(gallivm, i, count * 4, 4); j4 = lp_build_extract_range(gallivm, j, count * 4, 4); @@ -2230,7 +2230,7 @@ lp_build_fetch_s3tc_rgba_aos(struct gallivm_state *gallivm, rgba = LLVMBuildBitCast(builder, rgba, i8_vectype, ""); } else { - LLVMValueRef colors, codewords, alpha_lo, alpha_hi; + LLVMValueRef colors, codewords, alpha_lo = NULL, alpha_hi = NULL; lp_build_gather_s3tc(gallivm, n, format_desc, , , _lo, _hi, base_ptr, offset); -- 1.8.5.6 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] svga: add SVGA_NO_LOGGING env var
valgrind crashes when we try to initialize host logging. This env var can be used to disable logging. Cc: mesa-sta...@lists.freedesktop.org --- docs/envvars.html | 3 +++ src/gallium/drivers/svga/svga_screen.c | 4 +++- 2 files changed, 6 insertions(+), 1 deletion(-) diff --git a/docs/envvars.html b/docs/envvars.html index c9733e6..43d3a6c 100644 --- a/docs/envvars.html +++ b/docs/envvars.html @@ -338,6 +338,9 @@ See src/mesa/state_tracker/st_debug.c for other options. for details. SVGA_EXTRA_LOGGING - if set, enables extra logging to the vmware.log file, such as the OpenGL program's name and command line arguments. +SVGA_NO_LOGGING - if set, disables logging to the vmware.log file. +This is useful when using Valgrind because it otherwise crashes when +initializing the host log feature. See the driver code for other, lesser-used variables. diff --git a/src/gallium/drivers/svga/svga_screen.c b/src/gallium/drivers/svga/svga_screen.c index 6cb5a14..8158950 100644 --- a/src/gallium/drivers/svga/svga_screen.c +++ b/src/gallium/drivers/svga/svga_screen.c @@ -1134,7 +1134,9 @@ svga_screen_create(struct svga_winsys_screen *sws) svga_screen_cache_init(svgascreen); - init_logging(screen); + if (debug_get_bool_option("SVGA_NO_LOGGING", FALSE) == FALSE) { + init_logging(screen); + } return screen; error2: -- 1.8.5.6 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/5] winsys/svga: Add an environment variable to force host-backed operation
The series looks good to me. Reviewed-by: Brian Paul On 04/30/2019 05:04 AM, Thomas Hellstrom wrote: The vmwgfx kernel module has a compatibility mode for user-space that is not guest-backed resource aware. Add an environment variable to facilitate testing of this mode on guest-backed aware kernels: if the environment variable SVGA_FORCE_HOST_BACKED is defined, the driver will use host-backed operation. Signed-off-by: Thomas Hellstrom Reviewed-by: Deepak Rawat --- src/gallium/winsys/svga/drm/vmw_screen_ioctl.c | 17 +++-- 1 file changed, 11 insertions(+), 6 deletions(-) diff --git a/src/gallium/winsys/svga/drm/vmw_screen_ioctl.c b/src/gallium/winsys/svga/drm/vmw_screen_ioctl.c index 0ec8c1abe11..cdfe284c4c8 100644 --- a/src/gallium/winsys/svga/drm/vmw_screen_ioctl.c +++ b/src/gallium/winsys/svga/drm/vmw_screen_ioctl.c @@ -967,6 +967,7 @@ vmw_ioctl_init(struct vmw_winsys_screen *vws) drmVersionPtr version; boolean drm_gb_capable; boolean have_drm_2_5; + const char *getenv_val; VMW_FUNC; @@ -1006,17 +1007,21 @@ vmw_ioctl_init(struct vmw_winsys_screen *vws) goto out_no_3d; } vws->ioctl.hwversion = gp_arg.value; - - memset(_arg, 0, sizeof(gp_arg)); - gp_arg.param = DRM_VMW_PARAM_HW_CAPS; - ret = drmCommandWriteRead(vws->ioctl.drm_fd, DRM_VMW_GET_PARAM, - _arg, sizeof(gp_arg)); + getenv_val = getenv("SVGA_FORCE_HOST_BACKED"); + if (!getenv_val || strcmp(getenv_val, "0") == 0) { + memset(_arg, 0, sizeof(gp_arg)); + gp_arg.param = DRM_VMW_PARAM_HW_CAPS; + ret = drmCommandWriteRead(vws->ioctl.drm_fd, DRM_VMW_GET_PARAM, +_arg, sizeof(gp_arg)); + } else { + ret = -EINVAL; + } if (ret) vws->base.have_gb_objects = FALSE; else vws->base.have_gb_objects = !!(gp_arg.value & (uint64_t) SVGA_CAP_GBOBJECTS); - + if (vws->base.have_gb_objects && !drm_gb_capable) goto out_no_3d; ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/3] pipebuffer: use new pb_usage_flags enum type
It was committed in early March: b286e74df66e25cadd1c82d9ddc4d1fc3887b646 -Brian On 04/23/2019 07:25 AM, Thomas Hellstrom wrote: Hi, Brian, Did this series get reviewed? I don't see any replies? /Thomas On Tue, 2019-03-05 at 20:48 -0700, Brian Paul wrote: Use a new enum type instead of 'unsigned' to make things a bit more understandable. --- src/gallium/auxiliary/pipebuffer/pb_buffer.h | 34 ++ .../auxiliary/pipebuffer/pb_buffer_fenced.c| 6 ++-- .../auxiliary/pipebuffer/pb_buffer_malloc.c| 4 +-- src/gallium/auxiliary/pipebuffer/pb_bufmgr_cache.c | 4 +-- src/gallium/auxiliary/pipebuffer/pb_bufmgr_debug.c | 6 ++-- src/gallium/auxiliary/pipebuffer/pb_bufmgr_mm.c| 4 +-- .../auxiliary/pipebuffer/pb_bufmgr_ondemand.c | 4 +-- src/gallium/auxiliary/pipebuffer/pb_bufmgr_pool.c | 5 ++-- src/gallium/auxiliary/pipebuffer/pb_bufmgr_slab.c | 6 ++-- src/gallium/auxiliary/pipebuffer/pb_validate.c | 2 +- src/gallium/auxiliary/pipebuffer/pb_validate.h | 2 +- 11 files changed, 45 insertions(+), 32 deletions(-) diff --git a/src/gallium/auxiliary/pipebuffer/pb_buffer.h b/src/gallium/auxiliary/pipebuffer/pb_buffer.h index 33c2306..11f70ea 100644 --- a/src/gallium/auxiliary/pipebuffer/pb_buffer.h +++ b/src/gallium/auxiliary/pipebuffer/pb_buffer.h @@ -59,13 +59,22 @@ struct pb_vtbl; struct pb_validate; struct pipe_fence_handle; +enum pb_usage_flags { + PB_USAGE_CPU_READ = (1 << 0), + PB_USAGE_CPU_WRITE = (1 << 1), + PB_USAGE_GPU_READ = (1 << 2), + PB_USAGE_GPU_WRITE = (1 << 3), + PB_USAGE_DONTBLOCK = (1 << 9), + PB_USAGE_UNSYNCHRONIZED = (1 << 10), +}; -#define PB_USAGE_CPU_READ (1 << 0) -#define PB_USAGE_CPU_WRITE (1 << 1) -#define PB_USAGE_GPU_READ (1 << 2) -#define PB_USAGE_GPU_WRITE (1 << 3) -#define PB_USAGE_UNSYNCHRONIZED (1 << 10) -#define PB_USAGE_DONTBLOCK (1 << 9) +/* For error checking elsewhere */ +#define PB_USAGE_ALL (PB_USAGE_CPU_READ | \ + PB_USAGE_CPU_WRITE | \ + PB_USAGE_GPU_READ | \ + PB_USAGE_GPU_WRITE | \ + PB_USAGE_DONTBLOCK | \ + PB_USAGE_UNSYNCHRONIZED) #define PB_USAGE_CPU_READ_WRITE \ ( PB_USAGE_CPU_READ | PB_USAGE_CPU_WRITE ) @@ -82,7 +91,7 @@ struct pipe_fence_handle; struct pb_desc { unsigned alignment; - unsigned usage; + enum pb_usage_flags usage; }; @@ -100,7 +109,7 @@ struct pb_buffer struct pipe_reference reference; unsigned alignment; pb_sizesize; - unsigned usage; + enum pb_usage_flagsusage; /** * Pointer to the virtual function table. @@ -126,13 +135,13 @@ struct pb_vtbl * flags is bitmask of PB_USAGE_CPU_READ/WRITE. */ void *(*map)( struct pb_buffer *buf, - unsigned flags, void *flush_ctx ); + enum pb_usage_flags flags, void *flush_ctx ); void (*unmap)( struct pb_buffer *buf ); enum pipe_error (*validate)( struct pb_buffer *buf, struct pb_validate *vl, -unsigned flags ); +enum pb_usage_flags flags ); void (*fence)( struct pb_buffer *buf, struct pipe_fence_handle *fence ); @@ -160,7 +169,7 @@ struct pb_vtbl */ static inline void * pb_map(struct pb_buffer *buf, - unsigned flags, void *flush_ctx) + enum pb_usage_flags flags, void *flush_ctx) { assert(buf); if (!buf) @@ -201,7 +210,8 @@ pb_get_base_buffer( struct pb_buffer *buf, static inline enum pipe_error -pb_validate(struct pb_buffer *buf, struct pb_validate *vl, unsigned flags) +pb_validate(struct pb_buffer *buf, struct pb_validate *vl, +enum pb_usage_flags flags) { assert(buf); if (!buf) diff --git a/src/gallium/auxiliary/pipebuffer/pb_buffer_fenced.c b/src/gallium/auxiliary/pipebuffer/pb_buffer_fenced.c index 7421741..53b9ce0 100644 --- a/src/gallium/auxiliary/pipebuffer/pb_buffer_fenced.c +++ b/src/gallium/auxiliary/pipebuffer/pb_buffer_fenced.c @@ -139,7 +139,7 @@ struct fenced_buffer * A bitmask of PB_USAGE_CPU/GPU_READ/WRITE describing the current * buffer usage. */ - unsigned flags; + enum pb_usage_flags flags; unsigned mapcount; @@ -662,7 +662,7 @@ fenced_buffer_destroy(struct pb_buffer *buf) static void * fenced_buffer_map(struct pb_buffer *buf, - unsigned flags, void *flush_ctx) + enum pb_usage_flags flags, void *flush_ctx) { struct fenced_buffer *fenced_buf = fenced_buffer(buf); struct fenced_manager *fenced_mgr = fenced_buf->mgr; @@ -739,7 +739,7 @@ fenced_buffer_unmap(struct pb_buffer *buf) static enum pipe_error fenced_buffer_validate(struct pb_buffer *buf,
Re: [Mesa-dev] [PATCH] gallivm: fix saturated signed add / sub with llvm 9
On 04/16/2019 06:35 PM, srol...@vmware.com wrote: From: Roland Scheidegger llvm 8 removed saturated unsigned add / sub x86 sse2 intrinsics, and now llvm 9 removed the signed versions as well - they were proposed for removal earlier, but the pattern to recognize those was very complex, so it wasn't done then. However, instead of these arch-specific intrinsics, there's now arch-independent intrinsics for saturated add / sub, both for signed and unsigned, so use these. They should have only advantages (work with arbitrary vector sizes, optimal code for all archs), although I don't know how well they work in practice for other archs (at least for x86 they do the right thing). Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=110454 --- src/gallium/auxiliary/gallivm/lp_bld_arit.c | 14 ++ 1 file changed, 14 insertions(+) diff --git a/src/gallium/auxiliary/gallivm/lp_bld_arit.c b/src/gallium/auxiliary/gallivm/lp_bld_arit.c index 057c50ed278..02fb81afe51 100644 --- a/src/gallium/auxiliary/gallivm/lp_bld_arit.c +++ b/src/gallium/auxiliary/gallivm/lp_bld_arit.c @@ -555,6 +555,12 @@ lp_build_add(struct lp_build_context *bld, return bld->one; if (!type.floating && !type.fixed) { + if (HAVE_LLVM >= 0x0900) { +char intrin[32]; +intrinsic = type.sign ? "llvm.sadd.sat" : "llvm.uadd.sat"; +lp_format_intrinsic(intrin, sizeof intrin, intrinsic, bld->vec_type); +return lp_build_intrinsic_binary(builder, intrin, bld->vec_type, a, b); + } if (type.width * type.length == 128) { if (util_cpu_caps.has_sse2) { if (type.width == 8) @@ -625,6 +631,7 @@ lp_build_add(struct lp_build_context *bld, * NOTE: cmp/select does sext/trunc of the mask. Does not seem to * interfere with llvm's ability to recognize the pattern but seems * a bit brittle. + * NOTE: llvm 9+ always uses (non arch specific) intrinsic. */ LLVMValueRef overflowed = lp_build_cmp(bld, PIPE_FUNC_GREATER, a, res); res = lp_build_select(bld, overflowed, @@ -876,6 +883,12 @@ lp_build_sub(struct lp_build_context *bld, return bld->zero; if (!type.floating && !type.fixed) { + if (HAVE_LLVM >= 0x0900) { +char intrin[32]; +intrinsic = type.sign ? "llvm.ssub.sat" : "llvm.usub.sat"; +lp_format_intrinsic(intrin, sizeof intrin, intrinsic, bld->vec_type); +return lp_build_intrinsic_binary(builder, intrin, bld->vec_type, a, b); + } if (type.width * type.length == 128) { if (util_cpu_caps.has_sse2) { if (type.width == 8) @@ -925,6 +938,7 @@ lp_build_sub(struct lp_build_context *bld, * NOTE: cmp/select does sext/trunc of the mask. Does not seem to * interfere with llvm's ability to recognize the pattern but seems * a bit brittle. + * NOTE: llvm 9+ always uses (non arch specific) intrinsic. */ LLVMValueRef no_ov = lp_build_cmp(bld, PIPE_FUNC_GREATER, a, b); a = lp_build_select(bld, no_ov, a, b); LGTM. Reviewed-by: Brian Paul ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] gallivm: fix bogus assert in get_indirect_index
On 04/15/2019 01:39 PM, srol...@vmware.com wrote: From: Roland Scheidegger 0 is a valid value as max index, and the code handles it fine. This isn't commonly seen, as it will only happen with array declarations of size 1. The assert was introduced with a3c898dc97ec5f0e0b93b2ee180bdf8ca3bab14c. Fixes piglit tests/shaders/complex-loop-analysis-bug.shader_test Bugzilla: https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.freedesktop.org%2Fshow_bug.cgi%3Fid%3D110441data=02%7C01%7Cbrianp%40vmware.com%7Cc4b58aeaf4c245f7794e08d6c1da2226%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C636909539954259111sdata=l%2BScozK4SM92MrI4bIo7CBa1HujD0OFeKDz9ixvUdI8%3Dreserved=0 --- src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c b/src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c index 0f5b3d9acb7..d6af1d84471 100644 --- a/src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c +++ b/src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c @@ -1108,7 +1108,7 @@ get_indirect_index(struct lp_build_tgsi_soa_context *bld, * larger than the declared size but smaller than the buffer size. */ if (reg_file != TGSI_FILE_CONSTANT) { - assert(index_limit > 0); + assert(index_limit >= 0); max_index = lp_build_const_int_vec(bld->bld_base.base.gallivm, uint_bld->type, index_limit); Reviewed-by: Brian Paul ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] [rfc] st/mesa: don't update fb state is raster discard is set.
On 04/10/2019 12:10 AM, Dave Airlie wrote: From: Dave Airlie This avoid softpipe trying to get image when no window has ever been exposed, and no image will be exposed. I'm not entirely sure this is correct or useful, but it definitely helps with some softpipe get images when we haven't got a window. --- src/mesa/state_tracker/st_atom.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/src/mesa/state_tracker/st_atom.c b/src/mesa/state_tracker/st_atom.c index 49f79ad9d49..3aeb526e56b 100644 --- a/src/mesa/state_tracker/st_atom.c +++ b/src/mesa/state_tracker/st_atom.c @@ -246,6 +246,9 @@ void st_validate_state( struct st_context *st, enum st_pipeline pipeline ) unreachable("Invalid pipeline specified"); } + if (ctx->RasterDiscard) + st->dirty &= ~ST_NEW_FB_STATE; + dirty = st->dirty & pipeline_mask; if (!dirty) return; Yeah, this looks a little questionable. Couldn't you add a check for ctx->RasterDiscard in st_update_framebuffer_state() and no-op most of that function there? I think you'd at least want to do this after flushing the bitmap and readpix cache. -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] haiku: Fix hgl dispatch build. Tested under meson/scons.
On Sat, Mar 30, 2019 at 6:30 PM Alexander von Gluck IV < kallis...@unixzen.com> wrote: > --- > src/hgl/GLDispatcher.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/src/hgl/GLDispatcher.h b/src/hgl/GLDispatcher.h > index 8aaf58a6237..7a4bcd33299 100644 > --- a/src/hgl/GLDispatcher.h > +++ b/src/hgl/GLDispatcher.h > @@ -15,7 +15,7 @@ > #include > #include > > -#include "glheader.h" > +#include "main/glheader.h" > > #include "glapi/glapi.h" > > -- Looks OK to me. Reviewed-by: Brian Paul ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] util: no-op __builtin_types_compatible_p() for non-GCC compilers
On 03/29/2019 12:58 PM, Ian Romanick wrote: On 3/29/19 9:57 AM, Brian Paul wrote: __builtin_types_compatible_p() is GCC-specific and breaks the MSVC build. This intrinsic has been in u_vector_foreach() for a long time, but that macro has only recently been used in code (nir/nir_opt_comparison_pre.c) that's built with MSVC. Fixes: 2cf59861a ("nir: Add partial redundancy elimination for compares") --- src/util/u_vector.h | 4 1 file changed, 4 insertions(+) diff --git a/src/util/u_vector.h b/src/util/u_vector.h index cd8a95d..6807748 100644 --- a/src/util/u_vector.h +++ b/src/util/u_vector.h @@ -80,6 +80,10 @@ u_vector_finish(struct u_vector *queue) free(queue->data); } +#ifndef __GNUC__ +#define __builtin_types_compatible_p(x) 1 +#endif + #define u_vector_foreach(elem, queue) \ STATIC_ASSERT(__builtin_types_compatible_p(__typeof__(queue), struct u_vector *)); \ The way this is GCC builtin is used here, this should be fine. However, in case it's begin used elsewhere, we should #undef it afterwards. That doesn't seem to work. When u_vector_foreach() is instantiated later, __builtin_types_compatible_p is undefined and we error out. -Brian I'd hate to mask some other kind of bug that may be introduced later. for (uint32_t __u_vector_offset = (queue)->tail; \ ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] util: no-op __builtin_types_compatible_p() for non-GCC compilers
__builtin_types_compatible_p() is GCC-specific and breaks the MSVC build. This intrinsic has been in u_vector_foreach() for a long time, but that macro has only recently been used in code (nir/nir_opt_comparison_pre.c) that's built with MSVC. Fixes: 2cf59861a ("nir: Add partial redundancy elimination for compares") --- src/util/u_vector.h | 4 1 file changed, 4 insertions(+) diff --git a/src/util/u_vector.h b/src/util/u_vector.h index cd8a95d..6807748 100644 --- a/src/util/u_vector.h +++ b/src/util/u_vector.h @@ -80,6 +80,10 @@ u_vector_finish(struct u_vector *queue) free(queue->data); } +#ifndef __GNUC__ +#define __builtin_types_compatible_p(x) 1 +#endif + #define u_vector_foreach(elem, queue) \ STATIC_ASSERT(__builtin_types_compatible_p(__typeof__(queue), struct u_vector *)); \ for (uint32_t __u_vector_offset = (queue)->tail; \ -- 1.8.5.6 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] softpipe: fix clears to only clear specified color buffers.
On 03/26/2019 12:44 AM, Dave Airlie wrote: From: Dave Airlie This fixes piglit clearbuffer-mixed-format --- src/gallium/drivers/softpipe/sp_clear.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/gallium/drivers/softpipe/sp_clear.c b/src/gallium/drivers/softpipe/sp_clear.c index ba04fd0aa87..d2626a24333 100644 --- a/src/gallium/drivers/softpipe/sp_clear.c +++ b/src/gallium/drivers/softpipe/sp_clear.c @@ -68,7 +68,8 @@ softpipe_clear(struct pipe_context *pipe, unsigned buffers, if (buffers & PIPE_CLEAR_COLOR) { for (i = 0; i < softpipe->framebuffer.nr_cbufs; i++) { - sp_tile_cache_clear(softpipe->cbuf_cache[i], color, 0); + if (buffers & (PIPE_CLEAR_COLOR0 << i)) +sp_tile_cache_clear(softpipe->cbuf_cache[i], color, 0); } } Reviewed-by: Brian Paul ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] [rfc] draw/vs: partly fix basevertex/vertex id
On 03/25/2019 06:47 PM, Dave Airlie wrote: From: Dave Airlie This gets the basevertex from the draw depending on whether it's an indexed or non-indexed draw. We still fail a transform feedback test for vertex id, as the vertex id actually an index id, and isn't getting translated properly to a vertex id, suggestions on how/where to fix that welcome. --- src/gallium/auxiliary/draw/draw_vs_exec.c | 7 +++ 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/src/gallium/auxiliary/draw/draw_vs_exec.c b/src/gallium/auxiliary/draw/draw_vs_exec.c index 4f11ac7506c..dbd7aa551eb 100644 --- a/src/gallium/auxiliary/draw/draw_vs_exec.c +++ b/src/gallium/auxiliary/draw/draw_vs_exec.c @@ -128,18 +128,17 @@ vs_exec_run_linear(struct draw_vertex_shader *shader, input[slot][3]); } #endif +int basevertex = shader->draw->pt.user.eltSize ? shader->draw->pt.user.eltBias : shader->draw->start_index; if (shader->info.uses_vertexid) { unsigned vid = machine->SysSemanticToIndex[TGSI_SEMANTIC_VERTEXID]; assert(vid < ARRAY_SIZE(machine->SystemValue)); -machine->SystemValue[vid].xyzw[0].i[j] = i + j; -/* XXX this should include base vertex. Where to get it??? */ +machine->SystemValue[vid].xyzw[0].i[j] = i + j + basevertex; } if (shader->info.uses_basevertex) { unsigned vid = machine->SysSemanticToIndex[TGSI_SEMANTIC_BASEVERTEX]; assert(vid < ARRAY_SIZE(machine->SystemValue)); -machine->SystemValue[vid].xyzw[0].i[j] = 0; -/* XXX Where to get it??? */ +machine->SystemValue[vid].xyzw[0].i[j] = basevertex; } if (shader->info.uses_vertexid_nobase) { unsigned vid = machine->SysSemanticToIndex[TGSI_SEMANTIC_VERTEXID_NOBASE]; Reviewed-by: Brian Paul ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] st/mesa: fix texture deletion context mix-up issues (v2)
On 03/23/2019 10:49 AM, Jose Fonseca wrote: Looks good to me. Reviewed-by: Jose Fonseca Though I wonder if this could happen also when not destroying the current context. (Ie, if we need zoombie textures too?) If we're not destroying the thread's current context, this patch temporarily binds the context as the current one. If the contexts textures are not shared, they'll be deleted. If they are shared, they won't be deleted. I think that part is fairly straight-forward. -Brian Jose *From:* Brian Paul *Sent:* Friday, March 22, 2019 19:51 *To:* mesa-dev@lists.freedesktop.org *Cc:* Jose Fonseca; Neha Bhende *Subject:* [PATCH] st/mesa: fix texture deletion context mix-up issues (v2) When we destroy a context, we need to temporarily make that context the current one for the thread. That's because during context tear-down we make many calls to _mesa_reference_texobj(, NULL). Note there's no context parameter. If the texture's refcount goes to zero and we need to delete it, we use the thread's current context. But if that context isn't the context we're tearing down, we get into trouble when deallocating sampler views. See patch 593e36f956 ("st/mesa: implement "zombie" sampler views (v2)") for background information. Also, we need to release any sampler views attached to the fallback textures. Fixes a crash on exit with a glretrace of the Nobel Clinician application. v2: at end of st_destroy_context(), check if save_ctx == ctx and unbind the context if so. --- src/mesa/state_tracker/st_context.c | 51 - 1 file changed, 39 insertions(+), 12 deletions(-) diff --git a/src/mesa/state_tracker/st_context.c b/src/mesa/state_tracker/st_context.c index f037384..09d467a 100644 --- a/src/mesa/state_tracker/st_context.c +++ b/src/mesa/state_tracker/st_context.c @@ -917,15 +917,39 @@ st_destroy_context(struct st_context *st) { struct gl_context *ctx = st->ctx; struct st_framebuffer *stfb, *next; + struct gl_framebuffer *save_drawbuffer; + struct gl_framebuffer *save_readbuffer; + + /* Save the current context and draw/read buffers*/ + GET_CURRENT_CONTEXT(save_ctx); + if (save_ctx) { + save_drawbuffer = save_ctx->WinSysDrawBuffer; + save_readbuffer = save_ctx->WinSysReadBuffer; + } else { + save_drawbuffer = save_readbuffer = NULL; + } - GET_CURRENT_CONTEXT(curctx); + /* + * We need to bind the context we're deleting so that + * _mesa_reference_texobj_() uses this context when deleting textures. + * Similarly for framebuffer objects, etc. + */ + _mesa_make_current(ctx, NULL, NULL); - if (curctx == NULL) { - /* No current context, but we need one to release - * renderbuffer surface when we release framebuffer. - * So temporarily bind the context. - */ - _mesa_make_current(ctx, NULL, NULL); + /* This must be called first so that glthread has a chance to finish */ + _mesa_glthread_destroy(ctx); + + _mesa_HashWalk(ctx->Shared->TexObjects, destroy_tex_sampler_cb, st); + + /* For the fallback textures, free any sampler views belonging to this + * context. + */ + for (unsigned i = 0; i < NUM_TEXTURE_TARGETS; i++) { + struct st_texture_object *stObj = + st_texture_object(ctx->Shared->FallbackTex[i]); + if (stObj) { + st_texture_release_context_sampler_view(st, stObj); + } } st_context_free_zombie_objects(st); @@ -933,11 +957,6 @@ st_destroy_context(struct st_context *st) mtx_destroy(>zombie_sampler_views.mutex); mtx_destroy(>zombie_shaders.mutex); - /* This must be called first so that glthread has a chance to finish */ - _mesa_glthread_destroy(ctx); - - _mesa_HashWalk(ctx->Shared->TexObjects, destroy_tex_sampler_cb, st); - st_reference_fragprog(st, >fp, NULL); st_reference_prog(st, >gp, NULL); st_reference_vertprog(st, >vp, NULL); @@ -965,4 +984,12 @@ st_destroy_context(struct st_context *st) st = NULL; free(ctx); + + if (save_ctx == ctx) { + /* unbind the context we just deleted */ + _mesa_make_current(NULL, NULL, NULL); + } else { + /* Restore the current context and draw/read buffers (may be NULL) */ + _mesa_make_current(save_ctx, save_drawbuffer, save_readbuffer); + } } -- 1.8.5.6 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] draw/gs: fix point size outputs from geometry shader.
On 03/24/2019 11:14 PM, Dave Airlie wrote: From: Dave Airlie If the geom shader emits a point size we failed to find it here, use the correct API to look it up. Fixes: tests/spec/glsl-1.50/execution/geometry/point-size-out.shader_test --- src/gallium/auxiliary/draw/draw_pipe_wide_point.c | 9 + 1 file changed, 1 insertion(+), 8 deletions(-) diff --git a/src/gallium/auxiliary/draw/draw_pipe_wide_point.c b/src/gallium/auxiliary/draw/draw_pipe_wide_point.c index 1329ab4e7c0..e9bbb67a958 100644 --- a/src/gallium/auxiliary/draw/draw_pipe_wide_point.c +++ b/src/gallium/auxiliary/draw/draw_pipe_wide_point.c @@ -266,14 +266,7 @@ widepoint_first_point(struct draw_stage *stage, wide->psize_slot = -1; if (rast->point_size_per_vertex) { /* find PSIZ vertex output */ - const struct draw_vertex_shader *vs = draw->vs.vertex_shader; - uint i; - for (i = 0; i < vs->info.num_outputs; i++) { - if (vs->info.output_semantic_name[i] == TGSI_SEMANTIC_PSIZE) { -wide->psize_slot = i; -break; - } - } + wide->psize_slot = draw_find_shader_output(draw, TGSI_SEMANTIC_PSIZE, 0); } stage->point( stage, header ); Reviewed-by: Brian Paul ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] draw: bail instead of assert on instance count (v2)
On 03/24/2019 09:41 PM, Dave Airlie wrote: From: Dave Airlie With indirect rendering it's fine to set the instance count parameter to 0, and expect the rendering to be ignored. Fixes assert in KHR-GLES31.core.compute_shader.pipeline-gen-draw-commands on softpipe v2: return earlier before changing fpstate --- src/gallium/auxiliary/draw/draw_pt.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/src/gallium/auxiliary/draw/draw_pt.c b/src/gallium/auxiliary/draw/draw_pt.c index be76a30f97c..50286149cd4 100644 --- a/src/gallium/auxiliary/draw/draw_pt.c +++ b/src/gallium/auxiliary/draw/draw_pt.c @@ -464,6 +464,9 @@ draw_vbo(struct draw_context *draw, unsigned fpstate = util_fpstate_get(); struct pipe_draw_info resolved_info; + if (info->instance_count == 0) + return; + /* Make sure that denorms are treated like zeros. This is * the behavior required by D3D10. OpenGL doesn't care. */ @@ -472,7 +475,6 @@ draw_vbo(struct draw_context *draw, resolve_draw_info(info, _info, &(draw->pt.vertex_buffer[0])); info = _info; - assert(info->instance_count > 0); if (info->index_size) assert(draw->pt.user.elts); Reviewed-by: Brian Paul ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] st/mesa: fix texture deletion context mix-up issues (v2)
When we destroy a context, we need to temporarily make that context the current one for the thread. That's because during context tear-down we make many calls to _mesa_reference_texobj(, NULL). Note there's no context parameter. If the texture's refcount goes to zero and we need to delete it, we use the thread's current context. But if that context isn't the context we're tearing down, we get into trouble when deallocating sampler views. See patch 593e36f956 ("st/mesa: implement "zombie" sampler views (v2)") for background information. Also, we need to release any sampler views attached to the fallback textures. Fixes a crash on exit with a glretrace of the Nobel Clinician application. v2: at end of st_destroy_context(), check if save_ctx == ctx and unbind the context if so. --- src/mesa/state_tracker/st_context.c | 51 - 1 file changed, 39 insertions(+), 12 deletions(-) diff --git a/src/mesa/state_tracker/st_context.c b/src/mesa/state_tracker/st_context.c index f037384..09d467a 100644 --- a/src/mesa/state_tracker/st_context.c +++ b/src/mesa/state_tracker/st_context.c @@ -917,15 +917,39 @@ st_destroy_context(struct st_context *st) { struct gl_context *ctx = st->ctx; struct st_framebuffer *stfb, *next; + struct gl_framebuffer *save_drawbuffer; + struct gl_framebuffer *save_readbuffer; + + /* Save the current context and draw/read buffers*/ + GET_CURRENT_CONTEXT(save_ctx); + if (save_ctx) { + save_drawbuffer = save_ctx->WinSysDrawBuffer; + save_readbuffer = save_ctx->WinSysReadBuffer; + } else { + save_drawbuffer = save_readbuffer = NULL; + } - GET_CURRENT_CONTEXT(curctx); + /* +* We need to bind the context we're deleting so that +* _mesa_reference_texobj_() uses this context when deleting textures. +* Similarly for framebuffer objects, etc. +*/ + _mesa_make_current(ctx, NULL, NULL); - if (curctx == NULL) { - /* No current context, but we need one to release - * renderbuffer surface when we release framebuffer. - * So temporarily bind the context. - */ - _mesa_make_current(ctx, NULL, NULL); + /* This must be called first so that glthread has a chance to finish */ + _mesa_glthread_destroy(ctx); + + _mesa_HashWalk(ctx->Shared->TexObjects, destroy_tex_sampler_cb, st); + + /* For the fallback textures, free any sampler views belonging to this +* context. +*/ + for (unsigned i = 0; i < NUM_TEXTURE_TARGETS; i++) { + struct st_texture_object *stObj = + st_texture_object(ctx->Shared->FallbackTex[i]); + if (stObj) { + st_texture_release_context_sampler_view(st, stObj); + } } st_context_free_zombie_objects(st); @@ -933,11 +957,6 @@ st_destroy_context(struct st_context *st) mtx_destroy(>zombie_sampler_views.mutex); mtx_destroy(>zombie_shaders.mutex); - /* This must be called first so that glthread has a chance to finish */ - _mesa_glthread_destroy(ctx); - - _mesa_HashWalk(ctx->Shared->TexObjects, destroy_tex_sampler_cb, st); - st_reference_fragprog(st, >fp, NULL); st_reference_prog(st, >gp, NULL); st_reference_vertprog(st, >vp, NULL); @@ -965,4 +984,12 @@ st_destroy_context(struct st_context *st) st = NULL; free(ctx); + + if (save_ctx == ctx) { + /* unbind the context we just deleted */ + _mesa_make_current(NULL, NULL, NULL); + } else { + /* Restore the current context and draw/read buffers (may be NULL) */ + _mesa_make_current(save_ctx, save_drawbuffer, save_readbuffer); + } } -- 1.8.5.6 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] nir: fix a few signed/unsigned comparison warnings
--- src/compiler/nir_types.cpp | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/compiler/nir_types.cpp b/src/compiler/nir_types.cpp index aff575c..3bf93c5 100644 --- a/src/compiler/nir_types.cpp +++ b/src/compiler/nir_types.cpp @@ -690,7 +690,7 @@ glsl_type_get_sampler_count(const struct glsl_type *type) if (glsl_type_is_struct_or_ifc(type)) { unsigned count = 0; - for (int i = 0; i < glsl_get_length(type); i++) + for (unsigned i = 0; i < glsl_get_length(type); i++) count += glsl_type_get_sampler_count(glsl_get_struct_field(type, i)); return count; } @@ -711,7 +711,7 @@ glsl_type_get_image_count(const struct glsl_type *type) if (glsl_type_is_struct_or_ifc(type)) { unsigned count = 0; - for (int i = 0; i < glsl_get_length(type); i++) + for (unsigned i = 0; i < glsl_get_length(type); i++) count += glsl_type_get_image_count(glsl_get_struct_field(type, i)); return count; } -- 1.8.5.6 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] st/mesa: fix texture deletion context mix-up issues
When we destroy a context, we need to temporarily make that context the current one for the thread. That's because during context tear-down we make many calls to _mesa_reference_texobj(, NULL). Note there's no context parameter. If the texture's refcount goes to zero and we need to delete it, we use the thread's current context. But if that context isn't the context we're tearing down, we get into trouble when deallocating sampler views. See patch 593e36f956 ("st/mesa: implement "zombie" sampler views (v2)") for background information. Also, we need to release any sampler views attached to the fallback textures. Fixes a crash on exit with a glretrace of the Nobel Clinician application. --- src/mesa/state_tracker/st_context.c | 46 +++-- 1 file changed, 34 insertions(+), 12 deletions(-) diff --git a/src/mesa/state_tracker/st_context.c b/src/mesa/state_tracker/st_context.c index f037384..9b23d75 100644 --- a/src/mesa/state_tracker/st_context.c +++ b/src/mesa/state_tracker/st_context.c @@ -917,15 +917,39 @@ st_destroy_context(struct st_context *st) { struct gl_context *ctx = st->ctx; struct st_framebuffer *stfb, *next; + struct gl_framebuffer *save_drawbuffer; + struct gl_framebuffer *save_readbuffer; + + /* Save the current context and draw/read buffers*/ + GET_CURRENT_CONTEXT(save_ctx); + if (save_ctx) { + save_drawbuffer = save_ctx->WinSysDrawBuffer; + save_readbuffer = save_ctx->WinSysReadBuffer; + } else { + save_drawbuffer = save_readbuffer = NULL; + } - GET_CURRENT_CONTEXT(curctx); + /* +* We need to bind the context we're deleting so that +* _mesa_reference_texobj_() uses this context when deleting textures. +* Similarly for framebuffer objects, etc. +*/ + _mesa_make_current(ctx, NULL, NULL); - if (curctx == NULL) { - /* No current context, but we need one to release - * renderbuffer surface when we release framebuffer. - * So temporarily bind the context. - */ - _mesa_make_current(ctx, NULL, NULL); + /* This must be called first so that glthread has a chance to finish */ + _mesa_glthread_destroy(ctx); + + _mesa_HashWalk(ctx->Shared->TexObjects, destroy_tex_sampler_cb, st); + + /* For the fallback textures, free any sampler views belonging to this +* context. +*/ + for (unsigned i = 0; i < NUM_TEXTURE_TARGETS; i++) { + struct st_texture_object *stObj = + st_texture_object(ctx->Shared->FallbackTex[i]); + if (stObj) { + st_texture_release_context_sampler_view(st, stObj); + } } st_context_free_zombie_objects(st); @@ -933,11 +957,6 @@ st_destroy_context(struct st_context *st) mtx_destroy(>zombie_sampler_views.mutex); mtx_destroy(>zombie_shaders.mutex); - /* This must be called first so that glthread has a chance to finish */ - _mesa_glthread_destroy(ctx); - - _mesa_HashWalk(ctx->Shared->TexObjects, destroy_tex_sampler_cb, st); - st_reference_fragprog(st, >fp, NULL); st_reference_prog(st, >gp, NULL); st_reference_vertprog(st, >vp, NULL); @@ -965,4 +984,7 @@ st_destroy_context(struct st_context *st) st = NULL; free(ctx); + + /* Restore the current context and draw/read buffers */ + _mesa_make_current(save_ctx, save_drawbuffer, save_readbuffer); } -- 1.8.5.6 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] softpipe: fix 32-bit bitfield extract
All four patches look good to me Reviewed-by: Brian Paul On 03/20/2019 10:16 PM, Dave Airlie wrote: From: Dave Airlie These didn't deal with the width == 32 case that TGSI is defined with. Fixes piglit tests if ARB_gpu_shader5 is enabled. --- src/gallium/auxiliary/tgsi/tgsi_exec.c | 14 -- 1 file changed, 12 insertions(+), 2 deletions(-) diff --git a/src/gallium/auxiliary/tgsi/tgsi_exec.c b/src/gallium/auxiliary/tgsi/tgsi_exec.c index e1181aa1932..c93e4e26e40 100644 --- a/src/gallium/auxiliary/tgsi/tgsi_exec.c +++ b/src/gallium/auxiliary/tgsi/tgsi_exec.c @@ -4944,8 +4944,13 @@ micro_ibfe(union tgsi_exec_channel *dst, { int i; for (i = 0; i < 4; i++) { - int width = src2->i[i] & 0x1f; + int width = src2->i[i]; int offset = src1->i[i] & 0x1f; + if (width == 32 && offset == 0) { + dst->i[i] = src0->i[i]; + continue; + } + width &= 0x1f; if (width == 0) dst->i[i] = 0; else if (width + offset < 32) @@ -4966,8 +4971,13 @@ micro_ubfe(union tgsi_exec_channel *dst, { int i; for (i = 0; i < 4; i++) { - int width = src2->u[i] & 0x1f; + int width = src2->u[i]; int offset = src1->u[i] & 0x1f; + if (width == 32 && offset == 0) { + dst->u[i] = src0->u[i]; + continue; + } + width &= 0x1f; if (width == 0) dst->u[i] = 0; else if (width + offset < 32) ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] softpipe: fix texture view crashes
On 03/19/2019 09:13 PM, Dave Airlie wrote: From: Dave Airlie I noticed we crashed piglit arb_texture_view-rendering-formats when run on softpipe. This fixes the clear tiles to use the surface format not the underlying storage format. This fixes a bunch of srgb piglits as well. --- src/gallium/drivers/softpipe/sp_tile_cache.c | 11 ++- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/src/gallium/drivers/softpipe/sp_tile_cache.c b/src/gallium/drivers/softpipe/sp_tile_cache.c index 351736ee421..998939bdf30 100644 --- a/src/gallium/drivers/softpipe/sp_tile_cache.c +++ b/src/gallium/drivers/softpipe/sp_tile_cache.c @@ -373,17 +373,18 @@ sp_tile_cache_flush_clear(struct softpipe_tile_cache *tc, int layer) if (util_format_is_pure_uint(tc->surface->format)) { pipe_put_tile_ui_format(pt, tc->transfer_map[layer], x, y, TILE_SIZE, TILE_SIZE, - pt->resource->format, + tc->surface->format, (unsigned *) tc->tile->data.colorui128); } else if (util_format_is_pure_sint(tc->surface->format)) { pipe_put_tile_i_format(pt, tc->transfer_map[layer], x, y, TILE_SIZE, TILE_SIZE, - pt->resource->format, + tc->surface->format, (int *) tc->tile->data.colori128); } else { - pipe_put_tile_rgba(pt, tc->transfer_map[layer], - x, y, TILE_SIZE, TILE_SIZE, - (float *) tc->tile->data.color); + pipe_put_tile_rgba_format(pt, tc->transfer_map[layer], +x, y, TILE_SIZE, TILE_SIZE, +tc->surface->format, +(float *) tc->tile->data.color); } } numCleared++; Reviewed-by: Brian Paul ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] st/mesa: implement "zombie" sampler views (v2)
When st_texture_release_all_sampler_views() is called the texture may have sampler views belonging to several contexts. If we unreference a sampler view and its refcount hits zero, we need to be sure to destroy the sampler view with the same context which created it. This was not the case with the previous code which used pipe_sampler_view_release(). That function could end up freeing a sampler view with a context different than the one which created it. In the case of the VMware svga driver, we detected this but leaked the sampler view. This led to a crash with google-chrome when the kernel module had too many sampler views. VMware bug 2274734. Alternately, if we try to delete a sampler view with the correct context, we may be "reaching into" a context which is active on another thread. That's not safe. To fix these issues this patch adds a per-context list of "zombie" sampler views. These are views which are to be freed at some point when the context is active. Other contexts may safely add sampler views to the zombie list at any time (it's mutex protected). This avoids the context/view ownership mix-ups we had before. Tested with: google-chrome, google earth, Redway3D Watch/Turbine demos a few Linux games. If anyone can recomment some other multi-threaded, multi-context GL apps to test, please let me know. v2: avoid potential race issue by always adding sampler views to the zombie list if the view's context doesn't match the current context, ignoring the refcount. Reviewed-by: Roland Scheidegger Reviewed-by: Neha Bhende Reviewed-by: Mathias Fröhlich Reviewed-By: Jose Fonseca --- src/mesa/state_tracker/st_cb_flush.c | 6 +++ src/mesa/state_tracker/st_context.c | 80 src/mesa/state_tracker/st_context.h | 25 ++ src/mesa/state_tracker/st_sampler_view.c | 21 +++-- src/mesa/state_tracker/st_texture.h | 3 ++ 5 files changed, 131 insertions(+), 4 deletions(-) diff --git a/src/mesa/state_tracker/st_cb_flush.c b/src/mesa/state_tracker/st_cb_flush.c index 5b3188c..81e5338 100644 --- a/src/mesa/state_tracker/st_cb_flush.c +++ b/src/mesa/state_tracker/st_cb_flush.c @@ -39,6 +39,7 @@ #include "st_cb_flush.h" #include "st_cb_clear.h" #include "st_cb_fbo.h" +#include "st_context.h" #include "st_manager.h" #include "pipe/p_context.h" #include "pipe/p_defines.h" @@ -53,6 +54,11 @@ st_flush(struct st_context *st, { st_flush_bitmap_cache(st); + /* We want to call this function periodically. +* Typically, it has nothing to do so it shouldn't be expensive. +*/ + st_context_free_zombie_objects(st); + st->pipe->flush(st->pipe, fence, flags); } diff --git a/src/mesa/state_tracker/st_context.c b/src/mesa/state_tracker/st_context.c index 2898279..c38f8e5 100644 --- a/src/mesa/state_tracker/st_context.c +++ b/src/mesa/state_tracker/st_context.c @@ -261,6 +261,79 @@ st_invalidate_state(struct gl_context *ctx) } +/* + * In some circumstances (such as running google-chrome) the state + * tracker may try to delete a resource view from a context different + * than when it was created. We don't want to do that. + * + * In that situation, st_texture_release_all_sampler_views() calls this + * function to transfer the sampler view reference to this context (expected + * to be the context which created the view.) + */ +void +st_save_zombie_sampler_view(struct st_context *st, +struct pipe_sampler_view *view) +{ + struct st_zombie_sampler_view_node *entry; + + assert(view->context == st->pipe); + + entry = MALLOC_STRUCT(st_zombie_sampler_view_node); + if (!entry) + return; + + entry->view = view; + + /* We need a mutex since this function may be called from one thread +* while free_zombie_resource_views() is called from another. +*/ + mtx_lock(>zombie_sampler_views.mutex); + LIST_ADDTAIL(>node, >zombie_sampler_views.list.node); + mtx_unlock(>zombie_sampler_views.mutex); +} + + +/* + * Free any zombie sampler views that may be attached to this context. + */ +static void +free_zombie_sampler_views(struct st_context *st) +{ + struct st_zombie_sampler_view_node *entry, *next; + + if (LIST_IS_EMPTY(>zombie_sampler_views.list.node)) { + return; + } + + mtx_lock(>zombie_sampler_views.mutex); + + LIST_FOR_EACH_ENTRY_SAFE(entry, next, +>zombie_sampler_views.list.node, node) { + LIST_DEL(>node); // remove this entry from the list + + assert(entry->view->context == st->pipe); + pipe_sampler_view_reference(>view, NULL); + + free(entry); + } + + assert(LIST_IS_EMPTY(>zombie_sampler_views.list.node)); + + mtx_unlock(>zombie_sampler_views.mutex); +} + + +/* + * This function is called periodically to free any zombie objects + * which are attached to this context. + */ +void +st_context_free_zombie_objects(struct st_context *st) +{ + free_zombie_sampler_views(st); +} + + static void
Re: [Mesa-dev] [PATCH 1/8] st/mesa: implement "zombie" sampler views
On 03/15/2019 09:54 AM, Jose Fonseca wrote: On 14/03/2019 19:37, Brian Paul wrote: When st_texture_release_all_sampler_views() is called the texture may have sampler views belonging to several contexts. If we unreference a sampler view and its refcount hits zero, we need to be sure to destroy the sampler view with the same context which created it. This was not the case with the previous code which used pipe_sampler_view_release(). That function could end up freeing a sampler view with a context different than the one which created it. In the case of the VMware svga driver, we detected this but leaked the sampler view. This led to a crash with google-chrome when the kernel module had too many sampler views. VMware bug 2274734. Alternately, if we try to delete a sampler view with the correct context, we may be "reaching into" a context which is active on another thread. That's not safe. To fix these issues this patch adds a per-context list of "zombie" sampler views. These are views which are to be freed at some point when the context is active. Other contexts may safely add sampler views to the zombie list at any time (it's mutex protected). This avoids the context/view ownership mix-ups we had before. Tested with: google-chrome, google earth, Redway3D Watch/Turbine demos a few Linux games. If anyone can recomment some other multi-threaded, multi-context GL apps to test, please let me know. --- src/mesa/state_tracker/st_cb_flush.c | 6 +++ src/mesa/state_tracker/st_context.c | 81 src/mesa/state_tracker/st_context.h | 25 ++ src/mesa/state_tracker/st_sampler_view.c | 27 +-- src/mesa/state_tracker/st_texture.h | 3 ++ 5 files changed, 138 insertions(+), 4 deletions(-) diff --git a/src/mesa/state_tracker/st_cb_flush.c b/src/mesa/state_tracker/st_cb_flush.c index 5b3188c..81e5338 100644 --- a/src/mesa/state_tracker/st_cb_flush.c +++ b/src/mesa/state_tracker/st_cb_flush.c @@ -39,6 +39,7 @@ #include "st_cb_flush.h" #include "st_cb_clear.h" #include "st_cb_fbo.h" +#include "st_context.h" #include "st_manager.h" #include "pipe/p_context.h" #include "pipe/p_defines.h" @@ -53,6 +54,11 @@ st_flush(struct st_context *st, { st_flush_bitmap_cache(st); + /* We want to call this function periodically. + * Typically, it has nothing to do so it shouldn't be expensive. + */ + st_context_free_zombie_objects(st); + st->pipe->flush(st->pipe, fence, flags); } diff --git a/src/mesa/state_tracker/st_context.c b/src/mesa/state_tracker/st_context.c index 2898279..bd919da 100644 --- a/src/mesa/state_tracker/st_context.c +++ b/src/mesa/state_tracker/st_context.c @@ -261,6 +261,80 @@ st_invalidate_state(struct gl_context *ctx) } +/* + * In some circumstances (such as running google-chrome) the state + * tracker may try to delete a resource view from a context different + * than when it was created. We don't want to do that. + * In that situation, st_texture_release_all_sampler_views() calls this + * function to save the view for later deletion. The context here is + * expected to be the context which created the view. + */ +void +st_save_zombie_sampler_view(struct st_context *st, + struct pipe_sampler_view *view) +{ + struct st_zombie_sampler_view_node *entry; + + assert(view->context == st->pipe); + assert(view->reference.count == 1); + + entry = MALLOC_STRUCT(st_zombie_sampler_view_node); + if (!entry) + return; + + entry->view = view; + + /* We need a mutex since this function may be called from one thread + * while free_zombie_resource_views() is called from another. + */ + mtx_lock(>zombie_sampler_views.mutex); + LIST_ADDTAIL(>node, >zombie_sampler_views.list.node); + mtx_unlock(>zombie_sampler_views.mutex); +} + + +/* + * Free any zombie sampler views that may be attached to this context. + */ +static void +free_zombie_sampler_views(struct st_context *st) +{ + struct st_zombie_sampler_view_node *entry, *next; + + if (LIST_IS_EMPTY(>zombie_sampler_views.list.node)) { + return; + } + + mtx_lock(>zombie_sampler_views.mutex); + + LIST_FOR_EACH_ENTRY_SAFE(entry, next, + >zombie_sampler_views.list.node, node) { + LIST_DEL(>node); // remove this entry from the list + + assert(entry->view->context == st->pipe); + assert(entry->view->reference.count == 1); + pipe_sampler_view_reference(>view, NULL); + + free(entry); + } + + assert(LIST_IS_EMPTY(>zombie_sampler_views.list.node)); + + mtx_unlock(>zombie_sampler_views.mutex); +} + + +/* + * This function is called periodically to free any zombie objects + * which are attached to this context. + */ +void +st_context_free_zombie_objects(struct st_c