diff options
| -rw-r--r-- | .github/workflows/claude.yml | 33 | ||||
| -rwxr-xr-x | CLAUDE.md | 20 |
2 files changed, 40 insertions, 13 deletions
diff --git a/.github/workflows/claude.yml b/.github/workflows/claude.yml index 53143d0e8..89c740d36 100644 --- a/.github/workflows/claude.yml +++ b/.github/workflows/claude.yml @@ -193,7 +193,7 @@ jobs: with: # Direct Prompt is for testing. We shall use the triggers (on) which shall trigger this part on runtime custom_instructions: | - Build system information: + # Build system information: - OS: Ubuntu Linux - Build commands: * Configure: `cmake --preset default` @@ -203,17 +203,26 @@ jobs: - Project is pre-built and ready for development tasks - Run formatting script before committing changes - CRITICAL: You have access to the mcp__deepwiki__ask_question tool for deep repository knowledge. + # CRITICAL: You have access to the mcp__deepwiki__ask_question tool for deep repository knowledge. - **How to use this tool effectively:** - - Use repoName: "shader-slang/slang" for all queries - - Ask specific technical questions about architecture, patterns, or implementation approaches - - Examples: "How does the IR optimization system work?" or "What's the pattern for adding new code generation targets?" - - Use responses to understand existing patterns before implementing changes + **How to use this tool effectively:** + - Use repoName: "shader-slang/slang" for all queries + - Ask specific technical questions about architecture, patterns, or implementation approaches + - Examples: "What does the type legalization pass do?" or "What's the pattern for adding new code generation targets?" + - Use responses to understand existing patterns before implementing changes + + **Implementation Guidelines:** + - Always follow existing code patterns and architectural decisions discovered through deepwiki + - Consult the tool when you need context about unfamiliar parts of the codebase + + # Debugging backend crashes or invalid downstream code: + + Note that any issues in the generated target code could stem from IR passes or even the front-end type checking + early in the pipeline, and you need to focus on tracking the root cause that breaks the consistency/invariants/assumptions + of the IR instead of putting in band-aid fixes in the later passes or in the emit logic. The philosphy of the compiler is to + keep the target code emission logic as simple and direct as possible, and most of the heavy lifting code transform is done + in the IR passes. - **Implementation Guidelines:** - - Always follow existing code patterns and architectural decisions discovered through deepwiki - - Consult the tool when you need context about unfamiliar parts of the codebase mcp_config: | { "mcpServers": { @@ -226,11 +235,11 @@ jobs: allowed_tools: "Bash,View,GlobTool,GrepTool,BatchTool,Write,mcp__deepwiki__ask_question" trigger_phrase: "@claude" assignee_trigger: "claude" - timeout_minutes: "25" + timeout_minutes: "90" github_token: ${{ steps.auth-config.outputs.github-token }} use_bedrock: "true" model: ${{ vars.ANTHROPIC_MODEL }} - max_turns: "100" + max_turns: "500" # Use claude_env for custom environment variables claude_env: | ANTHROPIC_BEDROCK_BASE_URL: ${{ vars.ANTHROPIC_BEDROCK_BASE_URL }} @@ -1,4 +1,4 @@ -# CLAUDE.md ++# CLAUDE.md This file provides guidance to Claude Code (claude.ai/code) when working with code in this repository. @@ -39,6 +39,16 @@ slang-test must run from repository root ./build/Release/bin/slang-test slang-unit-test-tool/ ``` +Many of the Slang tests requires a GPU to run. However your local environment may not have a GPU. Prefer crafting the +test that runs on the CPU with `//TEST:COMPARE_COMPUTE(filecheck=CHECK): -cpu -output-using-type`, or with +`//TEST:INTERPRET(filecheck=CHECK):`. Prefer creating executable tests over compile-only tests, unless the test is to +check for a specific form of downstream code or diagnostics output. + +When using `slangc` to produce SPIRV, you should set the `SLANG_RUN_SPIRV_VALIDATION` environment variable to `1` to ensure +that slangc runs SPIRV validation on the generated SPIRV. If you don't see any errors you are good. +Don't use the system's `spirv-val` tool to validate the SPIRV because it is not up-to-date. + + ### Slang Command Line Usage **IMPORTANT:** Slang uses single dashes for multi-character options (not double dashes like most tools): - Use `-help` (not `--help`) @@ -122,6 +132,14 @@ The dump prints multiple sections which of each is separated by `### ` header. Each section visualizes the IR state on multiple steps during the compilation. It is necessary to differentiate the information on one section from one section, because the issue might be observed at a specific section. +You can also modify Slang code and insert a call to `dumpIRToString()` at any point of interest to dump any part of the IR +to string. You can then write that string to a temp file with `File::writeAllText()` to analyze what is going on. + +When checking the IR dump, look for type consistency or logical errors in the IR to locate the potential transformation +pass at fault. Focus on passes that makes significant and systematic changes to the IR, such as specialization, inlining, +type legalization, and buffer lowering passes. You may iterate this process multiple times to narrow down the issue. + + #### slangc with `-target spirv-asm` slangc with `-target spirv-asm` is the most common way to see how the given slang shader is compiled into spirv code. |