bilinear texture sampling with textureSample instead of textureLoad

[harley-canva]

No description provided.

[LaurenzV]

Will take a look on Monday, thanks for the prototype!!

[LaurenzV]

Unfortunately, my benchmarks seem to suggest that the saved ops from not applying the extend matter, especially on low-tier devices. :( Your PR does help with the performance of bilinear for the current API and also a bit for non-bilinear, but draw_image still seems to give a pretty large speed boost.

I tested this on my M4 Max, iPhone 16 Pro Max and Samsung Galaxy Tab A6 (for the last one I only have 200 images instead of 10k, otherwise it would explode :D).

TLDR, for bilinear draw image I get:

• M4: 8.92 ms vs 10.53
• iPhone: 60.75ms vs 72.21
• A6: 224.90ms vs 270.65

M4 Max

With my draw_image:

With your PR (in this case, 3) and 5) as well as 4) and 6) are the same):

iPhone

With my draw_image:

With your PR (in this case, 3) and 5) as well as 4) and 6) are the same):

Samsung

With my draw_image:

With your PR (in this case, 3) and 5) as well as 4) and 6) are the same):

[harley-canva]

@LaurenzV thank you for benchmarking!

So I wonder if we can find a middle ground. The main concern I have is the API concern of having a "fast path" and the reuse of existing fields in that fast branch. One thing I didn't explore was moving the UV calculation to the vertex stage, as you have done. It might be valuable to test moving calculations to the vertex stage to reduce the per-fragment ops. I also am not familiar with how textureDimensions works in terms of performance characteristics (I have a lot more experience with GLSL ES where I would pass that as a uniform).

If we can get comparable performance without splitting the API, I think that would be the best path forward. Unfortunately I'm about to go on holiday this week, so I doubt I will have time to test it.

[taj-p]

Please see #1517 (comment) 🙏