Replies: 3 comments 8 replies
-
@konsoletyper I'm willing to implement this ASAP if you don't currently think it's a priority, I'll do my best but of course it might take a little while since none of the WASM backend is documented and there aren't many comments in the source code of TeaVM either. If you plan to just wait for a more efficient method to become available for copying the contents of a WASM GC array to a JavaScript typed array then I will definitely implement support for linear memory in the WASM GC backend since I don't see why we must copy data at all when linear memory access for ByteBuffers would make it so we don't need to. |
Beta Was this translation helpful? Give feedback.
-
Alright now that I'm not at work trying to read and write all this on my phone, I see you have plans for a JSO extension where NIO buffers are backed by ArrayBuffers. In my app I created my own lightweight buffer classes to replace NIO a long time ago specifically for this purpose because the existing NIO buffers had too many features that didn't make sense on the web. In my opinion an optimal implementation of "direct buffers" in the WASM backend would be to make them slices of a conventional |
Beta Was this translation helpful? Give feedback.
-
It's nothing more than your opinion
First, it's opinionated. Second, there are use cases beyond both "responsive HTML based applications" and "involve rendering to a canvas"
Yes, it's a shame on WebAssembly committee. BUT! Copying data between main memory and GPU memory is anyway is a slow operation and should be performed as rare as possible. If you send gigabytes of data to GPU every frame, you'll get troubles without WebAssembly
No, copy instruction is a bad solution. A good solution is either a way to represent Wasm GC array as
I think it was like one or two years.
Sure, that's exactly what I was going to do, which I made perfectly clear in my post.
There's nothing difficult, it just requires some time, which right now I don't have.
No, please, just don't
I do think it's a priority for TeaVM, but for my personal life TeaVM is not priority right now. I must pass B1 Deutsch exam to be able to stay in Germany without visiting every couple years to Ausländerbehörde, as well as doing some paperwork.
Did you read my post carefuly? I never claimed I'm going to use any imported functions. |
Beta Was this translation helpful? Give feedback.
-
The more I think about it, there’s really not many practical uses for WASM that don’t also somehow involve rendering to a canvas. Using WASM in place of JavaScript for some responsive HTML based application is basically just a dumb gimmick, there’s no reason you’d actually want to use it instead of regular JavaScript for those kinds of applications besides to obfuscate the code more than you can achieve just using closure compiler, or of course to use the SIMD instructions to quietly mine cryptocurrency.
After looking into the WASM spec though, it’s clear that WASM GC in its current state isn’t gonna do much to help any sort of application that uses WebGL to render to a canvas. You can create byte arrays, but there’s no way to copy data between them besides using a
for
loop, and if you want to actually pass one to WebGL you gotta copy it one byte at a time into a typed array using an imported function, which is honestly embarrassing.The easiest way to at least escape the overhead of calling an imported JavaScript once per byte of data you’re streaming to the GPU would be to still allow the WASM GC backend to import a
WebAssembly.Memory
object, with some simple malloc/free style allocator and the TeaVMAddress
class to actually load/store values to it. Allocations could then be wrapped with an NIO directByteBuffer
, which is basically already how efficiently passing data to OpenGL via JNI on a regular JVM is done, so existing multi-platform TeaVM programs that render graphics using OpenGL/WebGL already probably store data meant to be passed to the GPU inside of aByteBuffer
instead of primitive arrays.Of course we can also just wait around for WASM GC to get a copy instruction that can efficiently transfer data from a WASM GC array into a JavaScript typed array. However, considering it took 10 years for them to get around to just adding a copy instruction for conventional WASM to copy data efficiently in a memory, I wouldn’t get my hopes up that we’re even gonna see instructions for copying data efficiently between two WASM GC arrays soon, much less than efficiently copying data from a WASM GC array into a JavaScript typed array.
So the quickest way to remedy this using the functionality currently available would just be to allow WASM GC to have linear memory access, that
ByteBuffer
objects can use to store data that must be able to efficiently be transferred from WASM to WebGL without the overhead of calling an imported function once per byte that needs to be copied.I don’t see any reason this would be hard to implement through recycling a few features from TeaVM’s existing legacy WASM backend.
Beta Was this translation helpful? Give feedback.
All reactions