I am trying to get emcc to compile a cpp file which works fine under blazor...

[BradChase2011]

I am seeking some help here to try to get over a hurdle using Uno.Wasm.Bootstrap instead of blazor to test out debugging and threading. That said, I have this repository which works fine and compiles the cpp and js into the correct library:

https://github.com/BradChase2011/CSharpBlazorWebGPUExample

So what Ive done is switch the flags and such from these which work under blazor:

<EmccExtraLDFlags>-s USE_WEBGPU=1 -s NO_EXIT_RUNTIME=1 --js-library '.\lib\lib_webgpu.js'</EmccExtraLDFlags>
<NativeFileReference Include="lib\lib_webgpu_cpp20.cpp" />

and one of the calls is used like so:

int test = navigator_gpu_get_preferred_canvas_format();

into:

[DllImport("*")]
public static extern int navigator_gpu_get_preferred_canvas_format();

I have it compiling under Uno.Wasm.Bootstrap with these flags:

<WasmShellExtraEmccFlags Include="-s USE_WEBGPU=1 -s NO_EXIT_RUNTIME=1 --js-library '$(ProjectDir)\lib\lib_webgpu.js'" />
<WasmShellNativeCompile Include=".\lib\lib_webgpu_cpp20.cpp" />

Problem is when I go to call the imported function at run time it fails. Under WSL its looking for an .so file by the same name (which doesnt exist anywhere) and running it outside of WSL just gives a generic error of failure. So I guess my question is, how can I get that functionality that works under the blazor example app to run under uno wasm bootstrap, am I missing a setting or is this not possible? If not possible, what would be the correct way?

Thanks much!

[jeromelaban]

Thanks for the report! Could you share your uno example as well?

[jeromelaban]

I see. So debugging is not supported at all for debugging at this time (it will be improved with when the bootstrapper moves to net9). As for WSL, if it shows in the debuger window, it's likely that it's running on your linux directly and not in the browser. The impression that it gives it that debugger is better is because it uses the full .NET debugger, not the one specific to WebAssembly.

Which error do you get when running on windows, in the browser logs specifically? Try running without the debugger, it may give more information.

[BradChase2011]

Yea at this point ive been trying a ton of things to get around it. The example app that I setup under .net 9 and blazor runs fine. So the idea was to try and use the uno bootloader to try and see if threading or debugging was any better. If you want to try and update the Uno example repository I put up and run that, it should fail quickly.

I get now with the changes you recommended on the example down to where it calls navigator_gpu_request_adapter_async, which fails. Basically anything that uses an unmanaged delegate for a callback fails, which I moved the blazor example back to .net 8 and it actually makes it through that section after changing to IntPtrs.

We have a 3d engine and a multithreaded xaml engine(DirectX 12 and Vulkan) that we are trying to port to WebGPU. Basically we are trying to prove each step, can we use C#, .NET, WASM, WebGPU, threading, and debugging. We have the engine side written but cannot test due to failures at each stage of the tests. Under blazor .net 9 we got the farthest but Microsoft has stated multithreading wont work until the earliest now .NET 10 and their debugging is completely broken at this point after the last update. I guess thats the explanation of why we would love to get the Uno.Wasm.Bootloader working for us. So the furthest we have been able to get is to the StartCalls() function of the Program, we are able to get the simple int returned from navigator_gpu_get_preferred_canvas_format but then it fails on the next call which uses an unmanaged delegate. If we are able to get through that test in the example app, the next stage would be to test threading.

If we turn on threading using WSL we actually hit the break points but fail because it cant find the library with the previous error. If we dont use WSL with threading turned on, the debugger breaks. So just trying to take it a step at a time and will worry about threading once we get the unmanaged callbacks working. Currently when we call a function with an unmanaged callback like "navigator_gpu_request_adapter_async" it fails with this error:

Uncaught ManagedError
at marshal_exception_to_js (d:\a\Uno.DotnetRuntime.WebAssembly\Uno.DotnetRuntime.WebAssembly\runtime\src\mono\wasm\runtime\marshal-to-js.ts:349:18)
at invoke_method_and_handle_exception (d:\a\Uno.DotnetRuntime.WebAssembly\Uno.DotnetRuntime.WebAssembly\runtime\src\mono\wasm\runtime\invoke-cs.ts:277:19)
at runtimeHelpers.javaScriptExports.call_entry_point (d:\a\Uno.DotnetRuntime.WebAssembly\Uno.DotnetRuntime.WebAssembly\runtime\src\mono\wasm\runtime\managed-exports.ts:60:13)
at mono_run_main (d:\a\Uno.DotnetRuntime.WebAssembly\Uno.DotnetRuntime.WebAssembly\runtime\src\mono\wasm\runtime\run.ts:44:45)
at mainInit (localhost꞉50193/package_446f0aba010eaaef2687fe60cb3490713063d363/uno-bootstrap.js:363:30)

Forgive me as again I am new to the web stuff, so how should I check the browser logs? I tried running without any debugger attached and chrome just shows the red background of the example, it doesnt show anything immediately seen as an error. I setup a simple function with an unmanaged call back called test_case and the chrome developer tools show this only:

I really do appreciate the help, I wish I could do more.

EDIT: I wanted to add the simple JS call (test_Case) I made that uses a callback that works under blazor but not Uno that i referenced:

JS:
test_case__deps: [],
test_case: function(callback) {
{{{ makeDynCall('vii', 'callback') }}}(1, 2);
return 3;
},

CS:
[DllImport(_DllPath)]
public static extern int test_case(delegate* unmanaged<int, int, void> callback);

int test = test_case(&TestCASE);

    [UnmanagedCallersOnly]
    static unsafe void TestCASE(int result, int userData)
    {
        int res = result;
    }

[jeromelaban]

I see. At this time, function pointers are not supported by p/invoke, this message is emitted silently here:

[00:00:01.2281004] [] Skipping pinvoke 'WebGpu.Interop::navigator_gpu_request_adapter_async' because 'Parsing function pointer types in signatures is not supported.'.

This may be supported by .NET 9, and the bootstrapper is not using it yet.

Stil, it's possible work around it, even if it's not pretty, it allows for callback handlers to be called:

You need to change the interop for this:

public unsafe struct WGpuRequestAdapterCallbackWrapper
{
    public WGpuRequestAdapterCallback cb;
}

public delegate void WGpuRequestAdapterCallback(WGpuAdapter* adapter, int userData);

[DlImport("__Native")]
/* EM_BOOL */
public static extern int navigator_gpu_request_adapter_async(ref WGpuRequestAdapterOptions options, WGpuRequestAdapterCallbackWrapper adapterCallback, IntPtr userData);

Then add this attribute, somewhere in your assemb;y:

[AttributeUsage(AttributeTargets.Method)]
internal sealed class MonoPInvokeCallbackAttribute : Attribute
{
    public MonoPInvokeCallbackAttribute(Type type)
    {
        Type = type;
    }

    public Type Type { get; private set; }
}

then modify your call back to be:

[MonoPInvokeCallback(typeof(WGpuRequestAdapterCallback))]
static unsafe void ObtainedWebGpuAdapter(WGpuAdapter* result, int userData)

then modify your invocation to be:

navigator_gpu_request_adapter_async(ref options, new() { cb = ObtainedWebGpuAdapter }, IntPtr.Zero);

Note that I changed ObtainedWebGpuAdapter to take a pointer, since WGpuAdapter is a pointer itself:

typedef int WGpuObjectBase;

All of this is required for now because UnmanagedCallers has semantics that requires function pointers, and .NET 8 does not support it properly.

[BradChase2011]

Thanks much for the update! I had no idea that was only supported in .net 9, which explains why the blazor side works with the latest pre releases but not the uno side which is .net 8. Man wish I had known that, ok so Ill try to implement this stuff and rewrite all the callbacks after a test. Wish I had seen that error face palm haha.

[BradChase2011]

All the callbacks work great so far! I have another issue that has come up though dealing with Structs. In the blazor example, I can send back a struct marshalled correctly but when I go to return the struct from the uno side with .net 8 I can only return a one field size struct, anything larger It fails. I presume this has to deal with some sort of marshalling or maybe the location of the memory? Here is a quick setup of a test struct I made. Im sure I am missing something again that exists in .net 9 blazor that isnt available in .net 8, Anything up front you see as not acceptable?

Here is the example:

cpp:

`typedef struct TestStruct
{
int first;
int second;
} TestStruct;

TestStruct GetTestStruct()
{
TestStruct ret;
ret.first = 1;
ret.second = 2;
return ret;
}`

C# Interop:

` [StructLayout(LayoutKind.Sequential)]
public struct TestStruct
{
public int first;
public int second;
}

    [DllImport(_DllPath)]
    public static extern TestStruct GetTestStruct();`

C# Call:

TestStruct testStruct = GetTestStruct();

I have tried setting the size manually, explicitly, types, I cant seem to get it to pass through. The final error I get is "Uncaught RuntimeError RuntimeError: null function or function signature mismatch". This seems to be the last hold out as of yet so the webgpu side can provide the defaults back to the client. Thanks again, I really appreciate all the help you have provided.

EDIT: I forgot to add, I can pass them as a ref as input to the function and that works just fine setting it there in the cpp side but I would like to know if maybe there is something small I missed to be able to actually return the struct rather than setting the memory from reference. Maybe something like a mono flag or attribute? For reference the UNO example is checked in and working with the latest changes showing webgpu running.