@typegpu/gl: builtin.position in fragment shaders has a bottom-left origin (gl_FragCoord)
メンテナーはふだん 2 日以内に返信
まだ誰も着手していません。
評価
- 難易度
- 4/5
- 見積もり時間
- 3〜5日
- 初心者へのやさしさ
- 45/100
- issue の種類
- バグ
- 明瞭さ
- おおむね明確
- 活発さ
- 活発
- 技術スタック
- typescript
- 領域
- backend
調査の方向性
Start by reading packages/typegpu-gl/src/glslGenerator.ts, especially glslInputForBuiltin, and trace how fragment position is translated for the GL fallback. Compare the coordinate behavior with WebGPU and inspect how draw targets expose their height; the proposal leaves the implementation choice open. Done means fragment position has consistent top-left coordinates across both backends, with coverage for the reported top-band repro.
索引モデルが issue の本文から書いたものです。
説明
Description
In a fragment shader, d.builtin.position is translated directly to gl_FragCoord (glslInputForBuiltin in packages/typegpu-gl/src/glslGenerator.ts). The two use different origins:
- WGSL
@builtin(position): (0, 0) is the top-left of the framebuffer, +y down. - GLSL
gl_FragCoord: (0, 0) is the bottom-left, +y up.
So any shader that works in pixel coordinates (dithering, pixel grids, textureLoad with the fragment position, screen-space effects) renders vertically flipped on the GL fallback compared to WebGPU.
Repro
const fragment = tgpu.fragmentFn({ in: { pos: d.builtin.position }, out: d.vec4f })(({ pos }) => {
'use gpu';
// Red band along the top 10 pixels.
return std.select(d.vec4f(0, 0, 0, 1), d.vec4f(1, 0, 0, 1), pos.y < 10);
});
- WebGPU root: the red band is at the top.
initWithGL()root: the red band is at the bottom.
Proposal
Emit a flipped coordinate, e.g. vec4(gl_FragCoord.x, u_targetHeight - gl_FragCoord.y, gl_FragCoord.zw). The target height would be a uniform set per draw from the color attachment. Alternatively, render upside down and flip on presentation, so the builtins and texture orientation match WebGPU everywhere.
Workaround
Derive pixel coordinates from an interpolated UV varying instead of the position builtin.
Found in @typegpu/gl 0.12.6. Related: #1637.
- 主要言語
- TypeScript
- スター
- 3.3k
- フォーク
- 135
- 平均マージ
- 4日 1時間
- マージ済み PR（30日）
- 64
環境構築
- Dockerfile・Docker Compose ファイルなし
- プルリクエストのテンプレートなし
- コントリビューションガイドを読む
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
software-mansion/TypeGPU のほかの issue
-
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100
software-mansion/TypeGPU#3219 · コメント 1 件 ·
メンテナーはふだん 2 日以内に返信
-
bug
難易度 2/5 1〜3時間 初心者へのやさしさ 74/100
software-mansion/TypeGPU#3213 · コメント 1 件 ·
メンテナーはふだん 2 日以内に返信
-
enhancement
難易度 2/5 1〜3時間 初心者へのやさしさ 65/100
software-mansion/TypeGPU#3008 · コメント 1 件 ·
メンテナーはふだん 2 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 68/100
software-mansion/TypeGPU#2948 · コメント 2 件 ·
メンテナーはふだん 2 日以内に返信
-
docs: Fix camera orientation in "Monocular Light Injection" example対応中かも @pullfrog が 60 日前に担当しました。 オープン
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100
software-mansion/TypeGPU#2890 · コメント 1 件 ·
メンテナーはふだん 2 日以内に返信
software-mansion/TypeGPU の issue をすべて見る
似ている issue
-
docs(api): openapi.yaml still documents gif-tools optimize colors as 2-256 instead of 2, 4, 16, 256オープンarea: backend documentation priority: low
難易度 2/5 1〜3時間 初心者へのやさしさ 84/100
snapotter-hq/SnapOtter#2919 ·
メンテナーはふだん 1 日以内に返信
-
accepted :+1: bug db/redis
難易度 2/5 1〜3時間 初心者へのやさしさ 76/100
beekeeper-studio/beekeeper-studio#4882 · コメント 1 件 ·
メンテナーはふだん 1 日以内に返信
-
ready-for-triage
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100
konflux-ci/konflux-ui#1630 · コメント 1 件 ·
メンテナーはふだん 2 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 67/100
ahmedkhaleel2004/gitdiagram#233 ·
-
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100
simkimsia/netlify-axi#19 ·
メンテナーはふだん 1 日以内に返信