Optimize texture attachment access by relaxing atomic memory ordering

[CrazyRoka]

Objective

• The objective of this PR is to improve the performance of texture attachment retrieval within the rendering pipeline.
• It addresses unnecessary overhead caused by strict atomic synchronization when tracking the "first call" state of attachments.

Solution

• Changed the memory ordering for is_first_call atomic operations from Ordering::SeqCst to Ordering::Relaxed.

Rationale: is_first_call is only used to answer a simple question: "Am I the first thread to request this attachment for a render pass?". Because the surrounding data (the texture view, format, clear color) is already fully initialized and completely immutable by the time this is called, there is no dependent memory that requires synchronization. The fetch_and(false) itself is atomic, meaning it will safely return true exactly once, no matter how many threads call it concurrently. Relaxed memory ordering is correct for given scenario.

Testing

• Added benchmarks comparing the previous SeqCst implementation against the Relaxed implementation.

cargo bench -p benches --bench render -- texture_attachment

---

texture_attachment/color_attachment_get
                        time:   [1.7758 ns 1.7833 ns 1.7909 ns]
                        change: [−45.886% −44.975% −44.042%] (p = 0.00 < 0.05)
                        Performance has improved.
texture_attachment/depth_attachment_get
                        time:   [2.3377 ns 2.3486 ns 2.3602 ns]
                        change: [−1.9965% −1.0377% −0.1363%] (p = 0.03 < 0.05)
                        Change within noise threshold.
Found 2 outliers among 100 measurements (2.00%)
  2 (2.00%) high mild
texture_attachment/output_color_attachment_get
                        time:   [1.7992 ns 1.8058 ns 1.8125 ns]
                        change: [−1.5831% −0.9112% −0.2491%] (p = 0.01 < 0.05)
                        Change within noise threshold.
texture_attachment/color_attachment_new_and_get
                        time:   [56.642 ns 57.698 ns 58.719 ns]
                        change: [+0.0036% +1.6169% +3.3741%] (p = 0.05 < 0.05)
                        Change within noise threshold.