render: ask the device for the adapter's own limits #444

Merged

natsukium merged 4 commits from render/request-adapter-limits into main 2026-09-25 12:34:06 +09:00

Conversation 0 Commits 4 Files changed 4 +36 -3

natsukium commented 2026-09-25 12:21:19 +09:00

Owner

Copy link

request_device required wgpu::Limits::default() (8192 texture side and the other WebGPU defaults), so an adapter below any of them (GLES 3.1 / D3D11 downlevel adapters report 2048) refused the device and the atlas clamp of REQ-1005 / REQ-1006 never ran.

• request_device asks for adapter.limits(). The warm-start path (warmup.rs) calls the same function, so both routes change.
• The atlas clamp reads the device's 2D limit, the bound textures are validated against.
• Limits::downlevel_defaults().using_resolution(adapter.limits()) was rejected: it would still refuse adapters under the GLES 3.1 compute/storage floors the staged path never uses, and it would lower uniform/storage limits on ordinary hardware.
• A window larger than the device's 2D limit is still refused. That limit applies on every adapter (8192 today), and making window, grid, framebuffer and pointer agree past it is a separate change. The CHANGELOG entry says so.
• The spec wording ("REQ-1005 and REQ-1006 clamp to the adapter's reported limit") is now accurate, so it is unchanged.

Verification: a test uses wgpu's noop backend (dev-dependency feature) reporting Limits::downlevel_defaults(). It fails against the old request and passes now. A real window with an isolated daemon also opened on NVIDIA Vulkan (staged uploads) and on lavapipe (mapped uploads). No local adapter reports under 8192.

Closes #387

`request_device` required `wgpu::Limits::default()` (8192 texture side and the other WebGPU defaults), so an adapter below any of them (GLES 3.1 / D3D11 downlevel adapters report 2048) refused the device and the atlas clamp of REQ-1005 / REQ-1006 never ran. - `request_device` asks for `adapter.limits()`. The warm-start path (`warmup.rs`) calls the same function, so both routes change. - The atlas clamp reads the device's 2D limit, the bound textures are validated against. - `Limits::downlevel_defaults().using_resolution(adapter.limits())` was rejected: it would still refuse adapters under the GLES 3.1 compute/storage floors the staged path never uses, and it would lower uniform/storage limits on ordinary hardware. - A window larger than the device's 2D limit is still refused. That limit applies on every adapter (8192 today), and making window, grid, framebuffer and pointer agree past it is a separate change. The CHANGELOG entry says so. - The spec wording ("REQ-1005 and REQ-1006 clamp to the adapter's reported limit") is now accurate, so it is unchanged. Verification: a test uses wgpu's noop backend (dev-dependency feature) reporting `Limits::downlevel_defaults()`. It fails against the old request and passes now. A real window with an isolated daemon also opened on NVIDIA Vulkan (staged uploads) and on lavapipe (mapped uploads). No local adapter reports under 8192. Closes #387

natsukium added 2 commits 2026-09-25 12:21:19 +09:00

render: ask the device for the adapter's own limits ... 36f447f635

request_device required Limits::default(), so an adapter below any of
those defaults (a GLES 3.1 or D3D11 downlevel adapter reports a 2048
texture side) refused the device and felis never opened a window; the
atlas clamp REQ-1005 and REQ-1006 describe could not run. Requesting
adapter.limits() never asks for more than the adapter offers, and the
clamp now reads the device's limit, which is the bound textures are
validated against. The warm-start path shares request_device, so both
routes change together. Limits::downlevel_defaults() with the adapter's
resolution was rejected: it would still refuse an adapter below the
GLES 3.1 compute and storage floors that the staged upload path never
uses, and it would lower the uniform and storage limits a user post
shader may rely on on ordinary hardware.

On such an adapter a surface larger than the 2D limit is itself a
validation error, and common window sizes exceed 2048, so the surface
is clamped to the limit on creation and resize.

The test drives request_device against wgpu's noop backend reporting
downlevel limits; it fails against the previous request. A window also
opened on NVIDIA Vulkan (staged uploads) and on lavapipe (mapped
uploads) with the adapter limits requested.

Assisted-by: Claude Code

render: leave the surface at the window's size past the 2D limit ... 38677e0e24

Clamping the surface to the device's 2D limit kept wgpu from refusing a
window larger than a downlevel adapter's 2048, but the client still
sizes the grid and reports its geometry from the whole window, so the
framebuffer would show fewer columns than the program was told it has,
and a platform that stretches the framebuffer would map the pointer to
the wrong cells. Making window, grid, framebuffer and pointer agree
past the limit is its own change, and the limit already bounds windows
on every adapter (8192 on ordinary hardware), so the surface goes back
to the window's size and the changelog says a window past the limit
still cannot be drawn. What the device request fixes stands: a
downlevel adapter gets a device and the atlas clamp runs.

Assisted-by: Claude Code

natsukium added 1 commit 2026-09-25 12:31:10 +09:00

Merge remote-tracking branch 'origin/main' into render/request-adapter-limits ... 4216da5568

# Conflicts:
#	CHANGELOG.md

natsukium added 1 commit 2026-09-25 12:33:32 +09:00

Merge remote-tracking branch 'origin/main' into render/request-adapter-limits ... 60c9e5740e

# Conflicts:
#	CHANGELOG.md

natsukium merged commit 6300a3b4c8 into main 2026-09-25 12:34:06 +09:00

natsukium deleted branch render/request-adapter-limits 2026-09-25 12:34:06 +09:00

natsukium referenced this pull request from a commit 2026-09-25 12:34:08 +09:00

render: ask the device for the adapter's own limits (#444)

Commenting is not possible because the repository is archived.

Reviewers

No reviewers

Labels

Clear labels   

priority/P0

Must be resolved before the v0.1.0 tag

  

priority/P1

Must be settled before the first public contract freezes

  

priority/P2

Explicitly deferred until after v0.1.0

  

release/v0.1.0

Work tracked for the first tagged release

  

status/blocked

Cannot start now: waits on an upstream release, another issue, or a recorded revisit trigger

  

status/planned

Triaged with a source-grounded plan and a passed pi review; ready to implement

  

type/bug

Shipped behavior that contradicts the docs or the code's own intent; needs a product code change

  

type/design

An open scope or trade-off question; needs a recorded decision in the owning explanation doc before code

  

type/test-gap

Documented or reviewed behavior that no test pins; usually split from a review finding, needs no product code change

  

type/tracker

Parent issue that tracks child work

No labels

priority/P0

priority/P1

priority/P2

release/v0.1.0

status/blocked

status/planned

type/bug

type/design

type/test-gap

type/tracker

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

1 participant

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference

natsukium/felis!444

No description provided.