Improve new user experience #1
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters
Update README and hctstart.cmd tools to help new developers. Update README * Add instructions on how to setup the build environment from the command line. * Add note to install common tools for c++ to get the atl headers. * Change cmake download to point to cmake 3.4.3. Version 3.4 did not work for me (it could not find the Visual Studio compiler tools). Modify hctstart.cmd * Explicitly check for the d3d12.h header from the 10240 windows kit. Without this early check we get a build error much later. * Check for cmake version 3.4.3 and warn if not found. Update gitignore for visual studio code temporary files.
| Hi @dmpots, I'm your friendly neighborhood Microsoft Pull Request Bot (You can call me MSBOT). Thanks for your contribution!
TTYL, MSBOT; |
tex3d reviewed Jan 4, 2017
utils/hct/hctstart.cmd Outdated
| setlocal | ||
| cmake --version | findstr 3.4.3 1>nul 2>nul | ||
| if errorlevel 1 ( | ||
| echo CMake 3.4 is the currently supported version - your installed cmake is not supported. |
There was a problem hiding this comment.
If findstr looks for 3.4.3 specifically, the comment should reflect this exact version number, otherwise someone with 3.4.2 or some other variant of 3.4 will be confused.
There was a problem hiding this comment.
Good find. Updated the message.
tex3d approved these changes Jan 4, 2017
Make the error message match the exact version checked for (3.4.3 vs. 3.4).
yurido1 pushed a commit to yurido1/DirectXShaderCompiler that referenced this pull request Feb 3, 2017
Adding options for dxc
MarijnS95 added a commit to MarijnS95/DirectXShaderCompiler that referenced this pull request Jan 24, 2022
Program received signal SIGSEGV, Segmentation fault. 0x00007ffff68b37e1 in DxcInitThreadMalloc () at ../lib/DxcSupport/dxcmem.cpp:32 warning: Source file is more recent than executable. 32 hlsl::GetGlobalHeapMalloc()->Alloc(10); (gdb) bt #0 0x00007ffff68b37e1 in DxcInitThreadMalloc () at ../lib/DxcSupport/dxcmem.cpp:32 microsoft#1 0x00007ffff67d1597 in DllMain() () from ./libdxcompiler.so (gdb) info vtbl g_HeapMalloc vtable for 'HeapMalloc' @ 0x0 (subobject @ 0x7ffff7d75c18): [0]: <error: Cannot access memory at address 0x0> [1]: <error: Cannot access memory at address 0x8> [2]: <error: Cannot access memory at address 0x10> [3]: <error: Cannot access memory at address 0x18> [4]: <error: Cannot access memory at address 0x20> [5]: <error: Cannot access memory at address 0x28> [6]: <error: Cannot access memory at address 0x30> [7]: <error: Cannot access memory at address 0x38> [8]: <error: Cannot access memory at address 0x40>
damyanp pushed a commit to damyanp/DirectXShaderCompiler that referenced this pull request Mar 22, 2025
This feature proposes moving built-in objects and functions to a new `hlsl` namespace. The primary motivation is to avoid name conflicts.
jimblandy pushed a commit to jimblandy/DirectXShaderCompiler that referenced this pull request Apr 29, 2025
Rebase mozilla's patches on top of upstream version 1.8.2502
jimblandy added a commit to jimblandy/DirectXShaderCompiler that referenced this pull request Apr 30, 2025
Change the definition of the HLSL `dot4add_i8packed` and `dot4add_u8packed` intrinsics in `utils/hct/gen_intrin_main.txt` to simply spell out the return types, rather than saying that their return type is determined by their third argument. This prevents DXC from trying to give those functions declarations like declare i64 @"\01?dot4add_u8packed@hlsl@@YA_JII_J@Z"(i32, i32, i64 signext) microsoft#1 which seems to expect a 64-bit third argument and return value. These functions are not generic, and they have only one overload, so there is no need to use interesting `uComponentTypeId` values to get the right effects, and `HLSLExternalSource::MatchArguments` seems to get confused about how to treat argument types that affect the return types.
jimblandy added a commit to jimblandy/DirectXShaderCompiler that referenced this pull request Apr 30, 2025
Change the definition of the HLSL `dot4add_i8packed` and `dot4add_u8packed` intrinsics in `utils/hct/gen_intrin_main.txt` to simply spell out the return types, rather than saying that their return type is determined by their third argument. This prevents DXC from trying to give those functions declarations like declare i64 @"\01?dot4add_u8packed@hlsl@@YA_JII_J@Z"(i32, i32, i64 signext) microsoft#1 which seems to expect a 64-bit third argument and return value. These functions are not generic, and they have only one overload, so there is no need to use interesting `uComponentTypeId` values to get the right effects, and `HLSLExternalSource::MatchArguments` seems to get confused about how to treat argument types that affect the return types.
jimblandy added a commit to jimblandy/DirectXShaderCompiler that referenced this pull request Apr 30, 2025
Change the definition of the HLSL `dot4add_i8packed` and `dot4add_u8packed` intrinsics in `utils/hct/gen_intrin_main.txt` to simply spell out the return types, rather than saying that their return type is determined by their third argument. This prevents DXC from trying to give those functions declarations like declare i64 @"\01?dot4add_u8packed@hlsl@@YA_JII_J@Z"(i32, i32, i64 signext) microsoft#1 which seems to expect a 64-bit third argument and return value. These functions are not generic, and they have only one overload, so there is no need to use interesting `uComponentTypeId` values to get the right effects, and `HLSLExternalSource::MatchArguments` seems to get confused about how to treat argument types that affect the return types. Fixes microsoft#7400.
jimblandy added a commit to jimblandy/DirectXShaderCompiler that referenced this pull request May 2, 2025
Change the definition of the HLSL `dot4add_i8packed` and `dot4add_u8packed` intrinsics in `utils/hct/gen_intrin_main.txt` to simply spell out the return types, rather than saying that their return type is determined by their third argument. This prevents DXC from trying to give those functions declarations like declare i64 @"\01?dot4add_u8packed@hlsl@@YA_JII_J@Z"(i32, i32, i64 signext) microsoft#1 which seems to expect a 64-bit third argument and return value. These functions are not generic, and they have only one overload, so there is no need to use interesting `uComponentTypeId` values to get the right effects, and `HLSLExternalSource::MatchArguments` seems to get confused about how to treat argument types that affect the return types. Fixes microsoft#7400.
jimblandy added a commit to jimblandy/DirectXShaderCompiler that referenced this pull request May 2, 2025
Change the definition of the HLSL `dot4add_i8packed` and `dot4add_u8packed` intrinsics in `utils/hct/gen_intrin_main.txt` to simply spell out the return types, rather than saying that their return type is determined by their third argument. This prevents DXC from trying to give those functions declarations like declare i64 @"\01?dot4add_u8packed@hlsl@@YA_JII_J@Z"(i32, i32, i64 signext) microsoft#1 which seems to expect a 64-bit third argument and return value. These functions are not generic, and they have only one overload, so there is no need to use interesting `uComponentTypeId` values to get the right effects, and `HLSLExternalSource::MatchArguments` seems to get confused about how to treat argument types that affect the return types. Fixes microsoft#7400.
jimblandy added a commit to jimblandy/DirectXShaderCompiler that referenced this pull request May 8, 2025
Change the definition of the HLSL `dot4add_i8packed`, `dot4add_u8packed`, and `dot2add` intrinsics in `utils/hct/gen_intrin_main.txt` to simply spell out the return types, rather than saying that their return type is determined by their third argument. This prevents DXC from trying to give those functions declarations like declare i64 @"\01?dot4add_u8packed@hlsl@@YA_JII_J@Z"(i32, i32, i64 signext) microsoft#1 which seems to expect a 64-bit third argument and return value. `HLSLExternalSource::MatchArguments` assumes that functions whose return type depends on their arguments' types will get cleaned up by `TryEvalInstrinsic`. Unfortunately, the `dot4add` variants cannot be constant expressions, so this cleanup does not happen for them. But these functions are not generic, and they have only one overload, so there is no need to use interesting `uComponentTypeId` values to get the right effects in the first place. Fixes microsoft#7400.
jimblandy added a commit to jimblandy/DirectXShaderCompiler that referenced this pull request May 8, 2025
Change the definition of the HLSL `dot4add_i8packed`, `dot4add_u8packed`, and `dot2add` intrinsics in `utils/hct/gen_intrin_main.txt` to simply spell out the return types, rather than saying that their return type is determined by their third argument. This prevents DXC from trying to give those functions declarations like declare i64 @"\01?dot4add_u8packed@hlsl@@YA_JII_J@Z"(i32, i32, i64 signext) microsoft#1 which seems to expect a 64-bit third argument and return value. `HLSLExternalSource::MatchArguments` assumes that functions whose return type depends on their arguments' types will get cleaned up by `TryEvalInstrinsic`. Unfortunately, the `dot4add` variants cannot be constant expressions, so this cleanup does not happen for them. But these functions are not generic, and they have only one overload, so there is no need to use interesting `uComponentTypeId` values to get the right effects in the first place. Fixes microsoft#7400.
pow2clk pushed a commit that referenced this pull request May 12, 2025
…7401) Change the definition of the HLSL `dot4add_i8packed` and `dot4add_u8packed` intrinsics in `utils/hct/gen_intrin_main.txt` to simply spell out the return types, rather than saying that their return type is determined by their third argument. This prevents DXC from trying to give those functions declarations like declare i64 @"\01?dot4add_u8packed@hlsl@@YA_JII_J@Z"(i32, i32, i64 signext) #1 which seems to expect a 64-bit third argument and return value. These functions are not generic, and they have only one overload, so there is no need to use interesting `uComponentTypeId` values to get the right effects, and `HLSLExternalSource::MatchArguments` seems to get confused about how to treat argument types that affect the return types. Fixes #7400.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit. This suggestion is invalid because no changes were made to the code. Suggestions cannot be applied while the pull request is closed. Suggestions cannot be applied while viewing a subset of changes. Only one suggestion per line can be applied in a batch. Add this suggestion to a batch that can be applied as a single commit. Applying suggestions on deleted lines is not supported. You must change the existing code in this line in order to create a valid suggestion. Outdated suggestions cannot be applied. This suggestion has been applied or marked resolved. Suggestions cannot be applied from pending reviews. Suggestions cannot be applied on multi-line comments. Suggestions cannot be applied while the pull request is queued to merge. Suggestion cannot be applied right now. Please check back later.
Update README and hctstart.cmd to help with issues I found when trying to build the first time.