# igalia Published articles for igalia. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## Proposal Raised To Finally Standardize Video Memory Stats Reporting Under Linux DevFeed: [Proposal Raised To Finally Standardize Video Memory Stats Reporting Under Linux]() Original publisher: [Read original article]() Author: Michael Larabel Published: 2026-09-17T15:17:24Z Content type: news Language: en Sources: [Phoronix]() Topics: [Linux Kernel](), [Linux](), [Kernel](), [Graphics]() Tags: [desktop-linux](), [drm](), [graphics](), [igalia](), [kernel](), [linux](), [linux-benchmarking](), [linux-hardware-benchmarks](), [linux-hardware-reviews](), [linux-how-to](), [linux-performance](), [linux-server-benchmarks](), [open-source-graphics](), [phoronix](), [phoronix-test-suite](), [rfc](), [ubuntu-benchmarks](), [ubuntu-hardware](), [vram]() ### AI overview A proposal led by Tvrtko Ursulin of Igalia would standardize cross-vendor video memory statistics reporting for Linux DRM drivers. The proposed sysfs interface would expose total and used memory for regions such as vRAM and GTT, with an AMDGPU implementation included for discussion. ### Source excerpt The idea has been talked about before but in 2026 still hasn't made it to the mainline Linux kernel.... Standardized reporting of video memory statistics that would work across different vendors / kernel graphics drivers. A new proposal was raised today in an effort to get a standardized interface established... ## Wastrel Compiles Hoot Scheme-to-WebAssembly Output DevFeed: [Wastrel Compiles Hoot Scheme-to-WebAssembly Output]() Original publisher: [Read original article]() Author: Andy Wingo Published: 2026-03-31T20:34:23Z Content type: article Language: en Sources: [wingolog]() Topics: [WebAssembly](), [Compiler](), [scheme]() Tags: [accidentally-quadratic](), [aot](), [bigint](), [bignums](), [compiler](), [compilers](), [exception-handling](), [exceptions](), [gc](), [gcc](), [gmp](), [hoot](), [igalia](), [library](), [maps](), [precision](), [scheme](), [standard](), [tail-calls](), [wasm](), [wastrel](), [webassembly](), [whippet]() ### AI overview The article describes recent work on Wastrel, an ahead-of-time WebAssembly compiler, including compiling output from the Hoot Scheme-to-Wasm compiler. It covers implementing bignum operations with mini-gmp and updating Hoot to use standardized WebAssembly exception handling. ### Source excerpt Good day! Today (tonight), some notes on the last couple months of Wastrel, my ahead-of-time WebAssembly compiler. Back in the beginning of February, I showed Wastrel running programs that use garbage collection, using an embedded copy of the Whippet collector, specialized to the types present in the Wasm program. But, the two synthetic GC-using programs I tested on were just ported microbenchmarks, and didn't reflect the output of any real toolchain. In this cycle I worked on compiling the output from the Hoot Scheme-to-Wasm compiler. There were some interesting challenges! bignums When I originally wrote the Hoot compiler, it targetted the browser, which already has a bignum implementation in the form of BigInt, which I worked on back in the day. Hoot-generated Wasm files use host bigints via externref (though wrapped in structs to allow for hashing and identity). In Wastrel, then, I implemented the imports that implement bignum operations: addition, multiplication, and so on. I did so using mini-gmp, a stripped-down implementation of the workhorse GNU multi-precision library. At some point if bignums become important, this gives me the option to link to the full GMP instead. Bignums were the first managed data type in Wastrel that wasn't defined as part of the Wasm module itself, instead hiding behind externref, so I had to add a facility to allocate type codes to these "host" data types. More types will come in time: weak maps, ephemerons, and so on. I think bignums would be a great proposal for the Wasm standard, similar to stringref ideally (sniff!), possibly in an attenuated form. exception handling Hoot used to emit a pre-standardization form of exception handling, and hadn't gotten around to updating to the newer version that was standardized last July. I updated Hoot to emit the newer kind of exceptions, as it was easier to implement them in Wastrel that way. Some of the problems Chris Fallin contended with in Wasmtime don't apply in the Wastrel case: sinc ## nominal types in webassembly DevFeed: [nominal types in webassembly]() Original publisher: [Read original article]() Author: Andy Wingo Published: 2026-03-10T08:19:34Z Content type: article Language: en Sources: [wingolog]() Topics: [WebAssembly](), [wasm]() Tags: [exceptions](), [hoot](), [igalia](), [isorecursive-types](), [nominal-types](), [structural-types](), [type-equality](), [types](), [wasm](), [wastrel](), [webassembly]() ### AI overview This article explains WebAssembly's structural type equality, how recursive type groups approximate nominal typing within a module, and how the nominal typing proposal adds nominal types for stronger separation between types across modules. ### Source excerpt Before the managed data types extension to WebAssembly was incorporated in the standard, there was a huge debate about type equality. The end result is that if you have two types in a Wasm module that look the same, like this: (type $t (struct i32)) (type $u (struct i32)) Then they are for all intents and purposes equivalent. When a Wasm implementation loads up a module, it has to partition the module's types into equivalence classes. When the Wasm program references a given type by name, as in (struct.get $t 0) which would get the first field of type $t, it maps $t to the equivalence class containing $t and $u. See the spec, for more details. This is a form of structural type equality. Sometimes this is what you want. But not always! Sometimes you want nominal types, in which no type declaration is equivalent to any other. WebAssembly doesn't have that, but it has something close: recursive type groups. In fact, the type declarations above are equivalent to these: (rec (type $t (struct i32))) (rec (type $u (struct i32))) Which is to say, each type is in a group containing just itself. One thing that this allows is self-recursion, as in: (type $succ (struct (ref null $succ))) Here the struct's field is itself a reference to a $succ struct, or null (because it's ref null and not just ref). To allow for mutual recursion between types, you put them in the same rec group, instead of each having its own: (rec (type $t (struct i32)) (type $u (struct i32))) Between $t and $u we don't have mutual recursion though, so why bother? Well rec groups have another role, which is that they are the unit of structural type equivalence. In this case, types $t and $u are not in the same equivalence class, because they are part of the same rec group. Again, see the spec. Within a Wasm module, rec gives you an approximation of nominal typing. But what about between modules? Let's imagine that $t carries important capabilities, and you don't want another module to be able to forge those c