In defense of NIR

Shortly after I joined the Mesa team at Intel in the summer of 2014, I was sitting in the cube area asking Ken questions, trying to figure out how Mesa was put together, and I asked, “Why don’t you use LLVM?” Suddenly, all eyes turned towards Ken and myself and I realized I’d poked a bear. Ken calmly explained a bunch of the packaging/shipping issues around having your compiler in a different project as well as issues radeonsi had run into with apps bundling their own LLVM that didn’t work. But for the more technical question of whether or not it was a good idea, his answer was something about trade-offs and how it’s really not clear if LLVM would really gain them much. That same summer, Connor Abbott showed up as our intern and started developing NIR. By the end of the summer, he had a bunch of data structures a few mostly untested passes, and a validator. He also had most of a GLSL IR to NIR pass which mostly passed validation. Later that year, after Connor had gone off to school, I took over NIR, finished the Intel scalar back-end NIR consumer, fixed piles of bugs, and wrote out-of-SSA and a bunch of optimization passes to get it to the point where we could finally land it in the tree at the end of 2014. Initially, it was only a few Intel folks and Emma Anholt (Broadcom, at the time) who were all that interested in NIR. Today, it’s integral to the Mesa project and at the core of every driver that’s still seeing active development. Over the past seven years, we (the Mesa community) have poured thousands of man hours (probably millions of engineering dollars) into NIR and it’s gone from something only capable of handling fragment shaders to supporting full Vulkan 1.2 plus ray-tracing (task and mesh are coming) along with OpenCL 1.2 compute. Was it worth it? That’s the multi-million dollar (literally) question. 2014 was a simpler time. Compute shaders were still newish and people didn’t use them for all that much more than they would have used a fancy fragment shader for a couple years earlier. More advanced features like Vulkan’s variable pointers weren’t even on the horizon. Had I known at the time how much work we’d have to put into NIR to keep up, I may have said, “Nah, this is too much effort; let’s just use LLVM.” If I had, I think it would have made the wrong call.

Databases: MongoDB/NoSQL, Firebird, and Rqlite/SQLite

• Top 10 features of MongoDB Atlas | FOSS Linux

  MongoDB is a NoSQL general-purpose document-oriented database that is free to use. It is a scalable, versatile NoSQL document database platform built to overcome the constraints of previous NoSQL solutions and the approach of relational databases. It helps the user store and deals with an enormous amount of data. MongoDB’s horizontal scaling and load balancing capabilities have given application developers unprecedented flexibility and scalability. There are different MongoDB editions; however, we will focus on MongoDB Atlas in this article. MongoDB Atlas is a multi-cloud database service created by the MongoDB team. Atlas makes it easy to deploy and manage databases while also giving users the flexibility they need to develop scalable, high-performance global applications on the cloud providers of their choice. It is the world’s most popular cloud database for modern applications. Developers can use Atlas to deploy fully managed cloud databases on AWS, Azure, or Google Cloud. Developers can relax easily knowing that they have rapid access to the availability, scalability, and compliance they need for enterprise-level application development.

• Node-firebird-driver-native version 2.4.0 has been released with a few features added.

  Node-firebird-driver-native version 2.4.0 has been released with a few features added.

• Rqlite 7.0 Released For Distributed Relational Database Built Atop SQLite - Phoronix

  Rqlite 7.0 is now available as a lightweight, distributed relational database. This open-source database system for cluster setups is built atop SQLite while aiming to be easy-to-use and fault-tolerant.

Writing an open source GPU driver – without the hardware

After six months of reverse-engineering, the new Arm “Valhall” GPUs (Mali-G57, Mali-G78) are getting free and open source Panfrost drivers. With a new compiler, driver patches, and some kernel hacking, these new GPUs are almost ready for upstream. In 2021, there were no Valhall devices running mainline Linux. While a lack of devices poses an obvious obstacle to device driver development, there is no better time to write drivers than before hardware reaches end-users. Developing and distributing production-quality drivers takes time, and we don’t want users to be reliant on closed source blobs. If development doesn’t start until a device hits shelves, that device could reach “end-of-life” by the time there are mature open drivers. But with a head start, we can have drivers ready by the time devices reach end users. Let’s see how. Also: Rosenzweig: Writing an open source GPU driver – without the hardware And related: Graphics Driver Changes Begin Lining Up For Linux 5.18