vello_hybrid: Avoid unnecessarily allocating `Uint32Array`s by laurenz-canva · Pull Request #1498 · linebender/vello

laurenz-canva · 2026-03-10T14:24:40Z

For the GhostScript tiger scene:

Before: texImage2D as well as UInt32Array::copy_from_slice are visible in the profile.

After: Only texImage2D is visibile in the profile.

laurenz-canva · 2026-03-10T14:31:43Z

+            // See also: https://wikis.khronos.org/opengl/Synchronization
+            // >> There are several OpenGL functions that can pull data directly from client-side memory,
+            // >> or push data directly into client-side memory. Functions like `glTexSubImage2D`,
+            // >> `glReadPixels`, `glBufferSubData` and so forth.
+            //
+            // >> Because OpenGL is defined to be synchronous, when any of these functions have
+            // >> returned, they must have finished with the client memory. When `glReadPixels` returns,
+            // >> the pixel data is in your client memory (unless you are reading into a buffer object).
+            // >> When `glBufferSubData` returns, you can immediately modify or delete whatever memory
+            // >> pointer you gave it, as OpenGL has already read as much as it wants.


I presume this applies to WebGL too, then, right?

taj-p

LGTM!

LaurenzV · 2026-03-10T20:24:40Z

Would you like to have this soon or shall I wait for Alex's review as well?

taj-p · 2026-03-10T20:40:17Z

Would you like to have this soon or shall I wait for Alex's review as well?

Thanks for asking 🙏 . I'll see how we go today building our feature branch and either cherry-pick this in or ask @grebmeg for a review. I believe we might cherry-pick #1493 in too (those gains look so good!)

grebmeg · 2026-03-16T09:28:23Z

+fn upload_data_to_rgba32_texture(
+    gl: &WebGl2RenderingContext,
+    data: &[u32],
+    texture_width: u32,
+    texture_height: u32,
+) {
+    // Safety: This calling `Uint32Array::view` is unsafe because it provides a view into
+    // WASM linear memory, and any additional allocations might invalidate that view.
+    // In our case, this is not an issue because we only use this view once for uploading
+    // data to the GPU below, and no allocations happen between that.
+    // The `tex_image_2d` method is synchronous in the sense that once it returns, it is guaranteed
+    // that all necessary data has already been read, so any allocations that happen
+    // after this block don't affect this anymore.
+    //
+    // See also: https://wikis.khronos.org/opengl/Synchronization
+    // >> There are several OpenGL functions that can pull data directly from client-side memory,
+    // >> or push data directly into client-side memory. Functions like `glTexSubImage2D`,
+    // >> `glReadPixels`, `glBufferSubData` and so forth.
+    //
+    // >> Because OpenGL is defined to be synchronous, when any of these functions have
+    // >> returned, they must have finished with the client memory. When `glReadPixels` returns,
+    // >> the pixel data is in your client memory (unless you are reading into a buffer object).
+    // >> When `glBufferSubData` returns, you can immediately modify or delete whatever memory
+    // >> pointer you gave it, as OpenGL has already read as much as it wants.
+    let packed_array = unsafe { js_sys::Uint32Array::view(data) };
+
+    gl.tex_image_2d_with_i32_and_i32_and_i32_and_format_and_type_and_opt_array_buffer_view(
+        WebGl2RenderingContext::TEXTURE_2D,
+        0,
+        WebGl2RenderingContext::RGBA32UI as i32,
+        texture_width as i32,
+        texture_height as i32,
+        0,
+        WebGl2RenderingContext::RGBA_INTEGER,
+        WebGl2RenderingContext::UNSIGNED_INT,
+        Some(&packed_array),
+    )
+    .unwrap();
+}


One thought: I think maybe you can avoid the unsafe entirely by using the _opt_u8_array overload instead. As I understand it when web-sys receives a &[u8] parameter, wasm-bindgen passes it as a zero-copy Uint8Array view into wasm linear memory, same perf as the manual Uint32Array::view(). WebGL interprets the raw bytes according to the type parameter (UNSIGNED_INT), not the JS typed array type, so a Uint8Array view works correctly for RGBA32UI textures.

This would simplify the helper to:

fn upload_data_to_rgba32_texture( gl: &WebGl2RenderingContext, data: &[u8], texture_width: u32, texture_height: u32, ) { gl.tex_image_2d_with_i32_and_i32_and_i32_and_format_and_type_and_opt_u8_array( WebGl2RenderingContext::TEXTURE_2D, 0, WebGl2RenderingContext::RGBA32UI as i32, texture_width as i32, texture_height as i32, 0, WebGl2RenderingContext::RGBA_INTEGER, WebGl2RenderingContext::UNSIGNED_INT, Some(data), ) .unwrap(); }

Oh! Lemme try this out!

Unfortunately, that doesn't seem to work correctly due to the fact that we are using RGBA32 textures.

Got it, thanks for checking! I think the next option might work, but I’m not sure that making two calls is better than the current approach.

fn upload_data_to_rgba32_texture( gl: &WebGl2RenderingContext, data: &[u8], texture_width: u32, texture_height: u32, pixel_unpack_buffer: &WebGlBuffer, ) { gl.bind_buffer( WebGl2RenderingContext::PIXEL_UNPACK_BUFFER, Some(pixel_unpack_buffer), ); gl.buffer_data_with_u8_array( WebGl2RenderingContext::PIXEL_UNPACK_BUFFER, data, WebGl2RenderingContext::STREAM_DRAW, ); gl.tex_image_2d_with_i32_and_i32_and_i32_and_format_and_type_and_f64( WebGl2RenderingContext::TEXTURE_2D, 0, WebGl2RenderingContext::RGBA32UI as i32, texture_width as i32, texture_height as i32, 0, WebGl2RenderingContext::RGBA_INTEGER, WebGl2RenderingContext::UNSIGNED_INT, 0.0, ) .unwrap(); gl.bind_buffer(WebGl2RenderingContext::PIXEL_UNPACK_BUFFER, None); }

Hmm, but wouldn't this still invoke another copy to the unpack buffer first before copying it to the GPU, whch is what we've been trying to avoid?

Since you both approved I think I'll merge it in its current state, but let me know if you would like to see adjustments.

grebmeg · 2026-03-16T23:30:17Z

+fn upload_data_to_rgba32_texture(
+    gl: &WebGl2RenderingContext,
+    data: &[u32],
+    texture_width: u32,
+    texture_height: u32,
+) {
+    // Safety: This calling `Uint32Array::view` is unsafe because it provides a view into
+    // WASM linear memory, and any additional allocations might invalidate that view.
+    // In our case, this is not an issue because we only use this view once for uploading
+    // data to the GPU below, and no allocations happen between that.
+    // The `tex_image_2d` method is synchronous in the sense that once it returns, it is guaranteed
+    // that all necessary data has already been read, so any allocations that happen
+    // after this block don't affect this anymore.
+    //
+    // See also: https://wikis.khronos.org/opengl/Synchronization
+    // >> There are several OpenGL functions that can pull data directly from client-side memory,
+    // >> or push data directly into client-side memory. Functions like `glTexSubImage2D`,
+    // >> `glReadPixels`, `glBufferSubData` and so forth.
+    //
+    // >> Because OpenGL is defined to be synchronous, when any of these functions have
+    // >> returned, they must have finished with the client memory. When `glReadPixels` returns,
+    // >> the pixel data is in your client memory (unless you are reading into a buffer object).
+    // >> When `glBufferSubData` returns, you can immediately modify or delete whatever memory
+    // >> pointer you gave it, as OpenGL has already read as much as it wants.
+    let packed_array = unsafe { js_sys::Uint32Array::view(data) };
+
+    gl.tex_image_2d_with_i32_and_i32_and_i32_and_format_and_type_and_opt_array_buffer_view(
+        WebGl2RenderingContext::TEXTURE_2D,
+        0,
+        WebGl2RenderingContext::RGBA32UI as i32,
+        texture_width as i32,
+        texture_height as i32,
+        0,
+        WebGl2RenderingContext::RGBA_INTEGER,
+        WebGl2RenderingContext::UNSIGNED_INT,
+        Some(&packed_array),
+    )
+    .unwrap();
+}


Got it, thanks for checking! I think the next option might work, but I’m not sure that making two calls is better than the current approach.

fn upload_data_to_rgba32_texture( gl: &WebGl2RenderingContext, data: &[u8], texture_width: u32, texture_height: u32, pixel_unpack_buffer: &WebGlBuffer, ) { gl.bind_buffer( WebGl2RenderingContext::PIXEL_UNPACK_BUFFER, Some(pixel_unpack_buffer), ); gl.buffer_data_with_u8_array( WebGl2RenderingContext::PIXEL_UNPACK_BUFFER, data, WebGl2RenderingContext::STREAM_DRAW, ); gl.tex_image_2d_with_i32_and_i32_and_i32_and_format_and_type_and_f64( WebGl2RenderingContext::TEXTURE_2D, 0, WebGl2RenderingContext::RGBA32UI as i32, texture_width as i32, texture_height as i32, 0, WebGl2RenderingContext::RGBA_INTEGER, WebGl2RenderingContext::UNSIGNED_INT, 0.0, ) .unwrap(); gl.bind_buffer(WebGl2RenderingContext::PIXEL_UNPACK_BUFFER, None); }

vello_hybrid: Avoid unnecessarily allocating Uint32Arrays

33f83ff

laurenz-canva requested review from grebmeg and taj-p and removed request for taj-p March 10, 2026 14:24

laurenz-canva commented Mar 10, 2026

View reviewed changes

taj-p approved these changes Mar 10, 2026

View reviewed changes

nicoburns added the C-hybrid Applies to the vello_hybrid crate label Mar 11, 2026

Encapsulate

aa190ba

grebmeg reviewed Mar 16, 2026

View reviewed changes

grebmeg approved these changes Mar 16, 2026

View reviewed changes

laurenz-canva added this pull request to the merge queue Mar 18, 2026

Merged via the queue into main with commit 8f2782f Mar 18, 2026
17 checks passed

laurenz-canva deleted the laurenz/copy branch March 18, 2026 07:59

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

vello_hybrid: Avoid unnecessarily allocating `Uint32Array`s#1498

vello_hybrid: Avoid unnecessarily allocating `Uint32Array`s#1498
laurenz-canva merged 2 commits into
mainfrom
laurenz/copy

laurenz-canva commented Mar 10, 2026

Uh oh!

laurenz-canva Mar 10, 2026

Uh oh!

taj-p left a comment

Uh oh!

LaurenzV commented Mar 10, 2026

Uh oh!

taj-p commented Mar 10, 2026

Uh oh!

grebmeg Mar 16, 2026

Uh oh!

laurenz-canva Mar 16, 2026

Uh oh!

LaurenzV Mar 16, 2026

Uh oh!

grebmeg Mar 16, 2026

Uh oh!

laurenz-canva Mar 18, 2026

Uh oh!

grebmeg Mar 16, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

Conversation

laurenz-canva commented Mar 10, 2026

Uh oh!

laurenz-canva Mar 10, 2026

Choose a reason for hiding this comment

Uh oh!

taj-p left a comment

Choose a reason for hiding this comment

Uh oh!

LaurenzV commented Mar 10, 2026

Uh oh!

taj-p commented Mar 10, 2026

Uh oh!

grebmeg Mar 16, 2026

Choose a reason for hiding this comment

Uh oh!

laurenz-canva Mar 16, 2026

Choose a reason for hiding this comment

Uh oh!

LaurenzV Mar 16, 2026

Choose a reason for hiding this comment

Uh oh!

grebmeg Mar 16, 2026

Choose a reason for hiding this comment

Uh oh!

laurenz-canva Mar 18, 2026

Choose a reason for hiding this comment

Uh oh!

grebmeg Mar 16, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants