Skip to content

Conversation

@ecoskey
Copy link
Contributor

@ecoskey ecoskey commented Dec 9, 2025

Objective

  • Migrate TAA to spec_v2

Testing

  • Ran anti_aliasing example, seems fine

@ecoskey ecoskey added A-Rendering Drawing game state to the screen C-Code-Quality A section of code that is hard to understand or change D-Modest A "normal" level of difficulty; suitable for simple features or challenging fixes S-Needs-Review Needs reviewer attention (from anyone!) to move forward labels Dec 9, 2025
@ecoskey ecoskey force-pushed the refactor/spec_v2/taa branch from 54d7976 to 96bd298 Compare December 9, 2025 06:17
@ecoskey ecoskey force-pushed the refactor/spec_v2/taa branch from 96bd298 to 643cc6a Compare December 9, 2025 06:18
Copy link
Contributor

@NicoZweifel NicoZweifel left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Tested the anti_aliasing example locally and it worked fine.

I took a look a the spec_v2 issues and understand that it is about splitting creation and modification of descriptors. However, in this specific example the shader expects:

struct Output {
    @location(0) view_target: vec4<f32>,
    @location(1) history: vec4<f32>,
};

Currently, these targets are set later in specialize using raw indices. But from what I understand about the reasoning behind spec_v2, shouldn't it already have the defaults set, which specialize then modifies?

For the index access I would prefer constants (or an enum), e.g.

const TARGET_VIEW: usize = 0;  
const TARGET_HISTORY: usize = 1;

and

fragment.set_target(TARGET_VIEW, color_target_state.clone());
fragment.set_target(TARGET_HISTORY, color_target_state);

since otherwise it's not exactly clear which target it is without looking at the shader.

This is just a minor nit imo and the example works, so approving.

@pablo-lua pablo-lua added S-Ready-For-Final-Review This PR has been approved by the community. It's ready for a maintainer to consider merging it and removed S-Needs-Review Needs reviewer attention (from anyone!) to move forward labels Dec 13, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

A-Rendering Drawing game state to the screen C-Code-Quality A section of code that is hard to understand or change D-Modest A "normal" level of difficulty; suitable for simple features or challenging fixes S-Ready-For-Final-Review This PR has been approved by the community. It's ready for a maintainer to consider merging it

Projects

Status: No status

Development

Successfully merging this pull request may close these issues.

3 participants