Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

speed up texture builin tests #3975

Open
greggman opened this issue Oct 2, 2024 · 0 comments
Open

speed up texture builin tests #3975

greggman opened this issue Oct 2, 2024 · 0 comments

Comments

@greggman
Copy link
Contributor

greggman commented Oct 2, 2024

Putting this here (1) as a TODO (2) to get input from others (3) a place to keep some notes

Profiling the texture builtin tests the majority of time is spent in TexelView.fromTexelsAsColors making a texture with random data with a generator and, at a glance, most of the speed is going small typedarray creation (in Chrome) per texel and/or per component and small JS object creation (lots and lots of temps).

There are at least 2 issues

  1. The code takes the u32 hash, divides by 0xFFFFFFFF to get a number from 0.0 to 1.0 and uses that to multiply by the test range for the texture format (0 to 1 for a unorm, -1 to 1 for snorm, 0 to 65535 for 16uint, etc...). It then passes the result to quantize which goes through a kind of deep path of temporaries of creating a texel of the given format in binary and then pulling it back out. So for example a 2bit alpha value should be quantized for 4 values.

    const quantize = (texel: PerTexelComponent<number>, rep: TexelRepresentationInfo) => {
      return rep.bitsToNumber(rep.unpackBits(new Uint8Array(rep.pack(rep.encode(texel)))));
    };

    The reason the quantization is needed is because the software renderer references the TexelViews so it needs to see the same values as the GPU will see.

  2. It calls whatever code is in fromTexelsAsColors to convert the texel to the binary format.

These are both slow.

Some ideas for speeding it up.

I tried optimizing the quantization by adding custom, per format, quantizers. That's easy for snorm/unorm/uint/sint formats. That made it 40% faster. (1000->600) That still leaves it slow for the remaining formats.

Commenting out the quantizing step takes it from (1000->440)

That effectively leaves the rest to fromTexelAsColors

Ideas:

  1. For snorm/unorm/sint/uint formats we can just use random binary data. All values are valid so there's no reason to do the quantization. We can use TexelView.fromTextureDataByReference to make the TexelViews for the software renderer.

  2. For formats that need quantization (if any) it might be faster to just put the values in and then read them back from the GPU (f16, ufloat, ...)?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant