mesa

Discover this repository through its Hacker News conversations.

Explore on GitHub Read Hacker News discussions

8Distinct people

8Mentions

0Explicit recommenders

REPOSITORY AT A GLANCE

What to know before exploring

What it is

A public description has not been verified.

Where it is used

No documented product use has been verified yet.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

No other repository is repeatedly linked in the same discussions.

This week on Hacker News

Nov 8–Nov 15 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/15/2026, 2:59:58 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year8 dated mentions

Observed mentions: 2017-08-26 09:33:15 UTC to 2023-02-03 04:08:05 UTC.

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges

UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
Period	Start (UTC)	End (exclusive, UTC)	Mentions	Comments
2017	2017-01-01 00:00:00 UTC	2018-01-01 00:00:00 UTC	1	1
2018	2018-01-01 00:00:00 UTC	2019-01-01 00:00:00 UTC	0	0
2019	2019-01-01 00:00:00 UTC	2020-01-01 00:00:00 UTC	0	0
2020	2020-01-01 00:00:00 UTC	2021-01-01 00:00:00 UTC	3	3
2021	2021-01-01 00:00:00 UTC	2022-01-01 00:00:00 UTC	3	3
2022	2022-01-01 00:00:00 UTC	2023-01-01 00:00:00 UTC	0	0
2023	2023-01-01 00:00:00 UTC	2024-01-01 00:00:00 UTC	1	1

What Hacker News says

3 sources

magic_quotes·Feb 1, 2021

> Closed source GPU drivers are not ordinary drivers. They have a lot of quirks and workarounds for programs, especially games. The quirks part is a bit of a meme. Mesa contains a few application-specific overrides here and there: https://github.com/mesa3d/mesa/blob/c62996796cc46f1a1406f365..., https://github.com/mesa3d/mesa/blob/a678ec9b8c057311ed7e9697.... The reason Linux drivers, including the one from Nvidia, have fewer quirks is simply that Linux has fewer 3d applications overall. Those quirks also reside in userspace driver parts and should not affect system stability. > When you try to port these drivers as-is to another platforms, things get awry. Again, quirks are a property of a relatively high-level userspace part of the driver. There is nothing hazardous about porting them.

In AMD vs. Intel vs. Nvidia: How Users Are Switching

rektide·Jan 13, 2021

$1.4 billion. Wow. That's a lot of dough. I feel like 202x might be another decade where no new chip making companies emerge. I had great hopes for Nuvia becoming one of them. My first most primitive reaction is that this is like another PA Semi[1]: great talent & new prospects, fresh air, vanishing into one of the super-massive existing players. Qualcomm does some open source work, but most of the support comes from outside engineers reverse engineering their products or otherwise doing the work[2]. The Freedreno graphics driver for example allows their gpu to be used (OpenGL, Vulkan drivers), & has been a huge effort. That work mostly comes from Google engineers like Rob Clark (who started Freedreno iirc), Eric Anholt, Igalia engineers like Danil, & countless others[3]. In the wifi-router world, where Qualcomm also has a huge presence,

Read the rest

we rely on hunting around for open-source code drops of what usually seems like pretty old but better than we've got code, such as this recent find[4], which is hopefully going to help us catch a couple years up in support level to what Qualcomm is doing today. Nuvia explicitly stated they wanted to chase hyperscaler market. And I think a lot of this was positioning. That hyper-scalers wanted good tech, would use good tech. Where-as a lot of the world, they want what they have but better, a lot of legacy concerns, hand holding. Nuvia wanted to build a new platform, a good, well supported platform, with next-gen technologies. We were all expecting open-source perhaps Rust-based firmwares & management systems, pursuant to latest OpenCompute Project specs &c. They were clear about targetting hyper-scalers, & big chips, but somehow the hope always was that they'd help reform & reshape computing & what was available to everyone. They certainly talked the good game, sounded real good on Twitter. Ah well. [1] https://venturebeat.com/2012/09/18/more-details-shake-loose-... [2] https://www.phoronix.com/scan.php?page=search&q=Qualcomm [3] https://github.com/mesa3d/mesa/commits/master/src/freedreno [4] https://forum.openwrt.org/t/adding-openwrt-support-for-xiaom...

In Qualcomm to Acquire Nuvia: A CPU Magnitude Shift

mechanical_berk·Jan 9, 2021

While I do not believe Broadcom has released any documentation on the 3D hardware in the Raspberry Pi 4, you can figure out a fair amount by looking at the Mesa driver. In particular see the shader processor instruction packing code (https://github.com/mesa3d/mesa/blob/master/src/broadcom/qpu/...). For vertex arrays, while in theory the driver could load vec2/vec4 F16 attributes into the vertex shader as-is, AFAICT the Mesa driver does not attempt to do this; they get converted to F32 as they are loaded from main memory. There would be downsides to getting rid of this conversion... in particular the hardware does not support F32->F16 conversions when loading attributes, so the driver would have to recompile the shader if you switched the vertex arrays to F32 (or perhaps more likely recompile the shader when it realises you are using F16 v

Read the rest

ertex arrays rather than F32). In any case, the hardware does support zero overhead F16->F32 conversions when loading attributes, so you should not see a performance drop when switching vertex arrays to F16! The performance should go up slightly as less data needs to be loaded from main memory. If you're seeing an 80% performance drop something has gone terribly wrong!

In Dissecting the Apple M1 GPU, part I