The Khronos® Group, an open consortium of industry-leading companies creating advanced interoperability standards, announces the immediate availability of the OpenXR™ 1.1 specification. This release evolves the widely adopted OpenXR open API standard for high-performance, cross-platform access to VR, AR, and mixed reality (MR) — collectively known as XR—platforms and devices. OpenXR 1.1 consolidates widely used API extensions into the core specification to reduce fragmentation and adds new functionality to streamline the development of more powerful and efficient XR applications.

In particular, OpenXR 1.1 consolidates multiple vendor extensions for key functionality to reduce differences in application code across multiple platforms, while still remaining flexible and extensible to foster innovation in a rapidly growing and evolving market. The OpenXR Working Group will focus on managing a pipeline of extensions to develop and seek feedback on new functionality, while proactively integrating proven technology into the core specification to provide developers with robust cross-platform XR capabilities.

Today, most major XR platforms have transitioned to using OpenXR to expose current and future device capabilities. Vendors with conformant OpenXR implementations include Acer, ByteDance, Canon, HTC, Magic Leap, Meta, Microsoft, Sony, XREAL, Qualcomm, Valve, Varjo, and Collabora’s Monado open source runtime. OpenXR is also supported by all the major game and rendering engines, including Autodesk VRED, Blender, Godot, NVIDIA’s Omniverse, StereoKit, Unreal Engine, and Unity.

The OpenXR 1.1 specification can be found on the Khronos website and on GitHub OpenXR Registry.

While the task of writing a brand new standard-compliant browser engine is infamous as being almost unachievable nowadays (and certainly so with Chromium coming in at 31 million lines of code), the Rust ecosystem has been brewing up a new web rendering engine called Servo. Initially created by Mozilla in 2012, Servo is still being developed today, now under the stewardship of the Linux Foundation.

At KDAB they managed to embed the Servo web engine inside Qt, by using their CXX-Qt library as a bridge between Rust and C++. This means that we can now use Servo as an alternative to Chromium for webviews in Qt applications.

Qt 6.7 is out with lots of large and small improvements for all of us who like to have fun when building modern applications and user experiences. Several additions are released as technology previews, and we are looking forward to your feedback so that we can get everything ready for the next LTS release!

AMD's HIP Ray-Tracing library "HIP RT" has been one of the few projects under the GPUOpen umbrella that starts off as closed-source software but then is eventually open-sourced... That happened now with the HIP ray-tracing code becoming publicly available.

If you've found yourself manually crafting complex Docker images or repeatedly installing tools, I've got something for you 😁

Check out "fusions" in bdockerimg project (https://github.com/bahmanm/bdockerimg).

With fusions, you merge base images into powerful composite images.

Currently there are:

• sdkman.bmakelib
• quicklisp.bmakelib

Let me know what other fusions would make your Docker life easier 🙏

There’s been a lot of noise recently about contributing to Open Source. Many developers contribute to Open Source projects for various reasons, including building their commit history for recruiters or gaining visibility through badges. However, experienced Open Source contributors have observed a troubling trend: contributing is seen as an obligation and a badge of honor, leading to frustration when it’s not straightforward.

Andrzej Janik has released ZLUDA 3, a new version of his open-source project that enables GPU-based applications designed for NVIDIA GPUs to run on other manufacturers’ hardware. The wrapper technology is designed to enable existing applications to run on new hardware unmodified, without the need for any work on their developers’ part.

I've been working on a small project called bdockerimg.

It's a collection of pre-built Docker images for some less common development tools (currently bmakelib, QuickLisp, and SDKMAN).

The idea is to streamline setup, especially for CI/CD pipelines, where I found myself repeating the same Dockerfile steps a lot. Basic functionality tests are included for a bit of extra peace of mind.

👀 Here's the repo if you're interested: https://github.com/bahmanm/bdockerimg
🗣 And here's the the Matrix room: https://matrix.to/#/#bdockerimg:matrix.org

I'm curious:

• Does this seem like something you might find useful?
• Are there any specific tools you'd love to see as easy-to-use Docker images?

This project is still in its early stages, so any feedback or contributions are much appreciated 🙏

Release 14.2 of GDB, the GNU Debugger, is now available. GDB is a source-level debugger for Ada, C, C++, Fortran, Go, Rust, and many other languages. GDB can target (i.e., debug programs running on) more than a dozen different processor architectures, and GDB itself can run on most popular GNU/Linux, Unix and Microsoft Windows variants. GDB is free (libre) software.

GDB 14.2 brings the following fixes and enhancements over GDB 14.1:

• PR symtab/31112 (DLL export forwarding is broken)
• PR c++/31128 (gdb crashes when trying to print a global variable stub without a running inferior)
• PR tdep/31254 ([gdb/tdep, arm] FAIL: gdb.threads/staticthreads.exp: up 10)
• PR gdb/31256 (Crash with basic 'list .')
• PR python/31366 (Frame.static_link() segfaults)

Vulkan 1.3.279 debuted on Friday with many fixes/clarifications to the specifications plus one new extension. The VK_NV_raw_access_chains extemsion should allow for more efficient shaders compiled from HLSL sources.

Extensions available in RISC-V enable the customizations that make it ideal as a basis for open innovation. Here’s the extension situation as it stands today.

This tutorial will teach you how to use the OpenXR API. OpenXR is an API managed by the Khronos Group which provides a cross-platform way for applications to interact with immersive devices. This includes virtual reality (VR) headsets, augmented reality (AR) devices, motion controllers and more.

Eight years after launching the Vulkan database to the public, it’s approaching 30,000 uploaded reports from more than 3,300 different devices across Windows, Linux, Android, MacOS and iOS. With that much data available, good filtering capabilities are crucial.

We are excited to announce that with the latest release of Steam Audio, the complete source code of the Steam Audio SDK is now available as open source. With this release, our goal is to provide more control to developers, which will lead to better experiences for their users, and hopefully valuable contributions back to the wider community of developers using Steam Audio.

I'm planning on creating an AI tournament as a project to test out some of the potential AI performance in a game, eg tic-tac-toe.

I'd like the AI to know the full history of a game instead of the instantaneous game-state because I might want some AI that use the historical data, eg AI that always put in the opposite cell of it's previous move if possible.

The question I am wondering is, what is the best way to setup the tournament.

I have a few options in my headspace:

1. Write everything in Rust (since I also am semi-interested in getting experience with the language)
2. Write everything in Python
3. Write the AI's in anything I want, but interact using stdin/stdout. Connect the AI using some shell script.

There are a few nice things I want to have:

1. able to run AI ad hoc against each other, or easily modify the tourney. ie I might want to add a new AI that runs against each of the previous AI instead of having the re-run the whole tourney
   • Rust would require a re-compile of the tourney code each time which may not be convenient
   • Options 2 and 3 would be much more convenient since it wouldn't require a full compilation and I can easily write a throwaway script
2. be able to run it in a somewhat performant way since I might want to simulate many rounds
   • Rust AI would be fast, but to avoid the issue in (1), I might go with solution 3 with the underlying AI being in Rust. But I'm not sure how significant the speed of piping IO between programs compare to if I had wrote everything as a Python program

Any advice on this would be great, cause there might be some options that I might have omitted.