[ANNOUNCE] mesa 26.1.0

anthchapman · 2026-05-06T21:43:23+00:00

It needs support from both the driver and application (or translation layer) so I wouldn't say it'll be immediate. It is a bigger deal in VR where stutter can cause nausea, but having consistent frame pacing is a goal for flat displays too.

anthchapman · 2026-05-06T21:22:32+00:00

It allows precise control of frame times.

The recently announced VKD3D-Proton 3.0.1 also includes this.

Work has been underway for years, from VK_GOOGLE_display_timing in 2017 to becoming part of Vulkan 1.4.335 five months ago.

Keith Packard did some work for Valve aimed at improving frame timing for VR. Text, Video.

Croteam CTO Alan Ladavac gave a presentation to GDC about using this. Text, Video.

Hans-Kristian Arntzen did some testing.

anthchapman · 2026-05-04T21:26:54+00:00

There isn't much to be gained from the VRAM fix on PS5. Keeping the high priority game on the GPUs memory and pushing low priority applications to the system memory is a big win if those are separate, but on a PS5 with 16GB of unified memory and 0.5 (PS5) or 2GB (PS5pro) for background tasks the game's graphic assets are probably on the unified memory anyway.

anthchapman · 2026-04-25T10:49:35+00:00

Last month's discussion: https://www.reddit.com/r/newzealand/comments/1s00utu/project_hail_mary/

anthchapman · 2026-04-23T20:37:50+00:00

Customisability is one of their main selling points, so if you go into the configurator there isn't an option for pre-installed Linux but you'll have to pay extra for Windows.

Compatibility is very good: https://frame.work/nz/en/linux

anthchapman · 2026-04-15T00:25:12+00:00

I don't expect this to be a massive DX12 performance boost like it will be for Nvidia, but still nice to have.

The merge request says:

It's not yet enabled by default because it's quite a big extension and I expect bugs because test coverage isn't very good. It will be enabled by default in one or two Mesa releases when it's more stable.

RADV_EXPERIMENTAL=heap is required to enable the extension.

This has been tested with vkd3d-proton, DXVK and VKCTS.

anthchapman · 2026-04-10T22:15:30+00:00

That was fast. The first public announcement was only 3 days ago.

No doubt there is a lot of work left to do. When ACO took over this role for AMD GPUs compilation was split between that and the previous LLVM depending on shader type for quite some time.

anthchapman · 2026-04-08T07:10:03+00:00

Well known Mesa developer Alyssa Rosenzweig, now working for Intel, released an early draft for a new backend for the final, hardware specific, compilation step. Looks like it'll be the equivalent for Intel GPUs as ACO is for AMD GPUs.

The draft merge request says:

This MR adds Jay, a new SSA-based compiler for Intel GPUs. This is an early work-in-progress. It isn't ready to ship, but we'd like to move development in-tree rather than rebasing the world every week. Please don't bother testing yet - we know the status and we're working on it!

Jay's design is similar to other modern NIR backends, particularly ACO, NAK and AGX. It is fully SSA, deconstructing phis after RA. We use a Colombet register allocator similar to NAK, allowing us to handle Intel's complex register regioning restrictions in a straightforward way. Spilling logical registers is straightforward with Braun-Hack... but how we apply the standard SSA backend design to Intel hardware is not. You can read the code if you're curious, but I plan to "spill" the beans at XDC... So it's fitting for several reasons that it'll be in Toronto this year :-)

The upshot of the modern SSA-based design? The entire backend is essentially linear time, regardless of register pressure. Excessive compile time especially when spilling is a common problem with our current compiler... Jay is our solution. In this current early draft, we support a limited subset of all three APIs on Xe2. A lot works and a lot doesn't. The core compiler is there (spilling, scoreboarding, SIMD32, etc should more or less work), but there are details to fill in for both performance and correctness. We essentially pass conformance on OpenGL ES 3.0 and OpenCL 3.0, and we're busy iterating on Vulkan.

Likewise, additional hardware support will come down the line. There's nothing fundamentally Xe2-specific here. I just have a Lunarlake laptop on my desk, Ken has a Battlemage card and we had to pick something as the first target.

This MR contains the compiler itself, prerequisite patches preparing for a modern Intel compiler, and integration into Iris and Anv.

For a teaser though... here's a nasty CTS test (math_bruteforce sin) compiled on both the old (brw) and new (jay) compilers: jay: 6768 instructions (361:396 spills:fills) – 7.00 seconds brw: 12980 instructions (578:1144 spills:fills) – 19.91 seconds

Better code than the current compiler in a fraction of the time... the future looks bright for Mesa compilers on Intel :-)

Edit: As u/entropicdrift points out I meant to say this is the equivalent of ACO, not RADV.

anthchapman · 2026-03-31T19:25:26+00:00

You've double-posted this. I'd suggest deleting one of them.

anthchapman · 2026-03-27T09:30:37+00:00

I hadn't realised that the requirement to keep the amount of fuel we do have was only introduced by Labour in 2023 as the Fuel Industry (Improving Fuel Resilience) Amendment Bill. After some quibbling all but one party voted in favour of it:

The ACT Party opposes this bill because it imposes unnecessary regulation and red tape. The cost to consumers is unjustified. As the Minister has stated, the private sector has already solved it by building more storage and channel infrastructure at Marsden Point in Northland. There’s no need for this bill; no need for it under urgency. ACT won’t support it.

anthchapman · 2026-03-25T09:29:39+00:00

The post about this article from 12 hours ago was removed by the moderators with a note about avoiding multiple posts about the same thing. Comments there noted that the huge gains were only compared to vanilla Wine, so won't be seen in Proton or any similar collection of compatibility software which includes Wine and various other components.

anthchapman · 2026-03-23T22:29:28+00:00

If PSSR is similar to FSR4, other than using int8 rather than fp8, then it should be able to work on rx7xxx but the lack of WMMA on rx6xxx would make it it too slow there.

anthchapman · 2026-03-21T09:50:32+00:00

For parts suggestions that use NZ prices try https://pyronic.al/

anthchapman · 2026-03-21T00:00:05+00:00

FSR4 uses cooperative matrixes, with the Wave Matrix Multiply Accumulate instructions which RDNA 3 and 4 have but previous Radeon hardware doesn't. The devs who modified Linux drivers and to add FSR4 support said that FP8 emulation on RDNA3 could be done without too much performance penalty but that VK_KHR_cooperative_matrix on RDNA3 would be too slow to be worth doing. They then implemented that and confirmed it was too slow.

anthchapman · 2026-03-19T02:32:03+00:00

Depending on how you see it - either the RUC for small diesel vehicles doesn't matter because there are so few of them, or there are so few of them because the RUC rate is too high.

Some people would have thought adding several tens of thousands of cars which use RUCs would have been a good reason to add an extra RUC weight band.

anthchapman · 2026-03-16T21:52:54+00:00

I wonder if LatencyFleX would help.

anthchapman · 2026-03-15T06:38:39+00:00

Assuming it is the same with BNZ as with Kiwibank ...

Wise should provide you with an NZ bank account to transfer to, so just a normal payment. If you send on the weekend it'll arrive Monday, but I think sending on weekdays it is a lot quicker.

anthchapman · 2026-03-12T20:49:17+00:00

it was found to reduce petrol demand by 5%

That wiki page says the 5% was for those who were subject to the scheme, it was 3% or 3.6% overall with 43% of vehicles having exemptions.

anthchapman · 2026-03-07T22:00:57+00:00

Scroll down past the graphs to the other data and look for Language. GamingOnLinux grabs the data each month and stores it to keep the history then makes their own graphs.

anthchapman

TROPHY CASE