Mesa (split from Screen Shots thread)

[Octacone]

@nakst
That is very cool looking!
Is that rendered on the GPU or what?
What is the purpose of Mesa?

[bzt]

Is that rendered on the GPU or what?

I don't think so, he said softpipe backend. This is still cool and a big achievement!

What is the purpose of Mesa?

It is a library that wraps low-level functions as well as driver interfaces, and provides a common interface on all platforms. Just like libc, which hides syscalls and provides a common API, but for 3D applications.

These days Mesa is considered obsolete (by 3D developers, the project is still active), and people use GLFW instead, however Mesa has a big advantage for hobby OS developers that it has a CPU only backend, which is easier to port. Porting GLFW is several magnitudes harder, not only because you'll need a working OpenGL or Vulkan driver with GLSL3 shader and SPIR-V bytecode interpreter support, but also because it includes wrapping windowing environments and user interface events. (And with this by no means I want to little @nakst's efforts, please don't get this wrong! GLFW is just more advanced therefore it is a lot harder to port, that's all.)

Cheers,
bzt

[nakst]

That is very cool looking!

Thanks!

Is that rendered on the GPU or what?

No. This is using the softpipe backend of Mesa, which runs on the CPU.

What is the purpose of Mesa?

In the FOSS graphics stack, Mesa is the userland implementer of OpenGL and Vulkan. Programs call OpenGL/Vulkan functions, which get passed to Mesa. Internally, Mesa sends these to one of its backends, such as softpipe, or a graphics card specific driver (which may be working in tandem with a kernel driver module).
There can be some additional steps interacting with window managers at this point, but I don't really understand what they are (because of the evolution of X, it's a bit of a mess). But currently I bypass all this by requesting Mesa to render to a buffer in memory, which I then manually blit to the window.

These days Mesa is considered obsolete (by 3D developers, the project is still active), and people use GLFW instead, however Mesa has a big advantage for hobby OS developers that it has a CPU only backend, which is easier to port. Porting GLFW is several magnitudes harder, not only because you'll need a working OpenGL or Vulkan driver with GLSL3 shader and SPIR-V bytecode interpreter support, but also because it includes wrapping windowing environments and user interface events

I believe this is incorrect. Mesa is still in common use on Linux (unless you are using Nvidia's proprietary drivers), and supports hardware acceleration and modern OpenGL. GLFW appears to be a platform independent wrapper for setting up a window that calls into OpenGL/Vulkan (which, if using the FOSS graphics stack, will call into Mesa).

[bzt]

These days Mesa is considered obsolete (by 3D developers, the project is still active), and people use GLFW instead, however Mesa has a big advantage for hobby OS developers that it has a CPU only backend, which is easier to port. Porting GLFW is several magnitudes harder, not only because you'll need a working OpenGL or Vulkan driver with GLSL3 shader and SPIR-V bytecode interpreter support, but also because it includes wrapping windowing environments and user interface events

I believe this is incorrect. Mesa is still in common use on Linux (unless you are using Nvidia's proprietary drivers), and supports hardware acceleration and modern OpenGL. GLFW appears to be a platform independent wrapper for setting up a window that calls into OpenGL/Vulkan (which, if using the FOSS graphics stack, will call into Mesa).

What I meant that 3D developers are not using the Mesa API any more, they prefer GLFW since OpenGL3 (there was a big change in the pipeline with that version, one could say a new paradigm).

If you take a look at the 3D tutorials, you'll see that ten years ago there were lots of GL tutorials built on Mesa (like NeHe), but these days there are mostly GLFW ones (like NeHe rewritten for GLFW, or this or this, and this has GLFW too). It is true that Mesa is still actively developed, and (although GLFW has its native Vulkan, GLX, and Direct3D backends which are very mature) you can still compile GLFW with Mesa support up to this day. But I have a feeling that native Vulkan drivers and library will take over pretty soon, if they haven't already.

Cheers,
bzt

[klange]

GLFW is a replacement for GLUT and plays a similar role to SDL, it is not an implementation of OpenGL or Vulkan - it is just a thin wrapper for creating window/rendering contexts across multiple platforms and backends. Neither OpenGL nor Vulkan provide this functionality directly, so you always need some other way to construct the necessary platform-specific rendering context in order to have something to draw into, and that's where these utility libraries come into play. GLFW's own website even describes it as a simple API for creating windows, contexts and surfaces, receiving input and events.

Mesa is an implementation of OpenGL and Vulkan. It's the implementation on Linux if you are using Intel GPUs, or AMD GPUs with the newer device drivers, or the nouveau driver for nvidia GPUs. Mesa also includes software backends, such as softpipe and the newer llvmpipe.

Mesa also packages a library that allows rendering into offscreen buffers, OSMesa, but this isn't "the Mesa API". You do not write code to "target Mesa" - you write code to target OpenGL or Vulkan, and Mesa quietly provides these in the background.

Porting GLFW is several magnitudes harder, not only because you'll need a working OpenGL or Vulkan driver with GLSL3 shader and SPIR-V bytecode interpreter support, but also because it includes wrapping windowing environments and user interface events.

That's what Mesa is.

[klange]

If you take a look at the 3D tutorials, you'll see that ten years ago there were lots of GL tutorials built on Mesa (like NeHe)

NeHe is a tutorial for Windows, it uses the Windows libraries to generate a context and then just uses OpenGL calls directly. None of this has anything to do with Mesa because the OpenGL implementation on Windows is provided directly by the GPU drivers. No tutorials for OpenGL have ever been "built on Mesa" - they were typically built against GLUT, which is widely considered outdated, and some of them are built on SDL, which is still very popular. But when you run any of these on Linux, unless you're using the proprietary nvidia driver, you are using Mesa - whether it's OpenGL 2, 3, GLES, or Vulkan.

[moonchild]

These days Mesa is considered obsolete (by 3D developers, the project is still active), and people use GLFW instead

Am a sometime 3d developer. This is incorrect.

Mesa comprises the rendering parts of a graphics stack. It can perform this rendering on a GPU, or on the CPU. It is the favoured solution on most unix-like operating systems for non-nvidia GPUs.

Generally, when an application wants to render something on the screen, it will talk to a display server (which is something like xorg). From the display server it will acquire a window handle (with arbitrary form, depending on the server) and, if it want to use 3d acceleration, a gpu framebuffer handle and a graphics context. The app uses both of these last two when talking to the system implementation of (opengl/vulkan/etc.)—which may be implemented by mesa—to draw things.

Glfw is an abstraction over display servers. Macos, windows, and linux all have different APIs for their display servers, and linux can even have two! Glfw provides a unified api implemented on top of all of these (which also handles input), so you don't have to recode your app's windowing code for every platform. It is orthogonal to the implementation of the graphics APIs. (Incidentally, I happen to prefer sdl's windowing abstraction over glfw's, but that's beside the point.)

[bzt]

Why do I have a feeling that you are just arguing l'art pour l'art?

GLFW is a replacement for GLUT and plays a similar role to SDL, it is not an implementation of OpenGL or Vulkan

Nobody said it is a direct OpenGL or Vulkan implementation (neither is Mesa btw, except for the CPU pipeline). As a matter of fact, I've explicitly stated that you'll need to port a separate driver. What I said was, that GLFW's Vulkan interface is mature and links directly to the Vulkan library (look at vulkan.c lines 53 - 64), without using Mesa at all. I've also wrote that for backward compatibility you *can* use with Mesa too.

Brief history on the trend in 3D tutorials:
1. GLUT + Mesa
2. GLFW + Mesa
3. GLFW + Mesa + Vulkan (did anyone really used this?)
4. GLFW + Vulkan (bye bye Mesa)

No tutorials for OpenGL have ever been "built on Mesa" - they were typically built against GLUT

NeHe has one. I gave that example for a good reason. (Yes, it also has a GLUT example too.)

NeHe is a tutorial for Windows, it uses the Windows libraries to generate a context

Absolutely NOT! NeHe contains dozens of environments for every single tutorial! There are Linux native, SDL, GLX, GLUT, what's more MacOS Cocoa and even Solaris and BeOS versions of the tutorials!
(Or used to be, the links are dead it seems. FYI the Win VC++ link is just as dead too. That's a pity.)

The app uses both of these last two when talking to the system implementation of (opengl/vulkan/etc.)—which may be implemented by mesa—to draw things.

Exactly. The key being here is "which may be". Unlike GLUT, which was dependent to Mesa on Linux unavoidably, GLFW isn't. That's the point!

Incidentally, I happen to prefer sdl's windowing abstraction over glfw's

I have the opposite experience. I've used both, and I still have some projects that provide wrappers for GLFW, GLUT and SDL as well. Every time GLFW turned out to be more lightweighted, much faster to start and I could achieve more FPS with the same rendering function (the framework independent code is in viewer.c). But you're right, this is truly beside the point.

Back to the point and putting and end to this conversation, according to Khronos Group, Mesa is obsolete, as well as all of OpenGL is obsolete. They said Vulkan is the successor, period.

All mainstream video cards already have a Vulkan driver (not requiring Mesa), and there are Open Source drivers too AMD, Intel, and for the RPi. Nvidia has binary only drivers, just like for OpenGL, no change there.

Cheers,
bzt

[klange]

You have absolutely no idea what you are talking about.

Nobody said it is a direct OpenGL or Vulkan implementation (neither is Mesa btw, except for the CPU pipeline). As a matter of fact, I've explicitly stated that you'll need to port a separate driver. What I said was, that GLFW's Vulkan interface is mature and links directly to the Vulkan library (look at vulkan.c lines 53 - 64), without using Mesa at all. I've also wrote that for backward compatibility you *can* use with Mesa too.

Mesa is what provides "libvulkan.so.1" on appropriate setups in Linux.

Brief history on the trend in 3D tutorials:
1. GLUT + Mesa
2. GLFW + Mesa
3. GLFW + Mesa + Vulkan (did anyone really used this?)
4. GLFW + Vulkan (bye bye Mesa)

Mesa has never been part of 3D tutorials! You never do anything that is specific to Mesa when writing OpenGL code, or Vulkan code. The history of OpenGL tutorials has always been GLUT, then SDL, then GFLW. Mesa never comes into play as an element application developers are concerned with.

NeHe has one. I gave that example for a good reason. (Yes, it also has a GLUT example too.)

Absolutely NOT! NeHe contains dozens of environments for every single tutorial! There are Linux native, SDL, GLX, GLUT, what's more MacOS Cocoa and even Solaris and BeOS versions of the tutorials!
(Or used to be, the links are dead it seems. FYI the Win VC++ link is just as dead too. That's a pity.)

NeHe is an absolute mess and a relic of the past and all that's available anymore on their website is this. I challenge you to actually find references to Mesa beyond installation instructions for header files in any of their remnant historic Linux tutorials.

Unlike GLUT, which was dependent to Mesa on Linux unavoidably

No it absolutely is not, as evidenced by the fact that it works with Nvidia GPUs just fine. There isn't even any code references to Mesa in FreeGLUT - just a README note about installing the Mesa dev package because it provides the OpenGL function headers.

Nobody said it is a direct OpenGL or Vulkan implementation (neither is Mesa btw, except for the CPU pipeline).

Mesa is a complete implementation of every function in the OpenGL API, backed either by its own drivers for Intel, AMD, and NVidia cards (through the open-source nouveau driver - which is part of mesa), or through the softpipe/llvmpipe CPU implementations, and is also the same for Vulkan. That is exactly what Mesa is.

Back to the point and putting and end to this conversation, according to Khronos Group, Mesa is obsolete, as well as all of OpenGL is obsolete. They said Vulkan is the successor, period.

Khronos has made no such comment on Mesa, but their hope was that Vulkan would allow for GPU manufacturers to provide their own drivers easily. Intel chose to continue to provide their Vulkan driver for Linux as part of Mesa.

All mainstream video cards already have a Vulkan driver (not requiring Mesa), and there are Open Source drivers too AMD, Intel, and for the RPi. Nvidia has binary only drivers, just like for OpenGL, no change there.

Mesa is the "open source Intel Vulkan driver" for Linux. Intel has been one of the primary contributors to Mesa for years, as they've never provided a proprietary driver separate from the one in Mesa. If you click through your own link you can see that plain as day.

It's also one of the AMD Vulkan drivers for Linux.

[reapersms]

All of that is true and correct.

For context, the NeHe tutorials make the Molloy Kernel tutorial look like a shining example of how to do things. They should not be considered representative of anything useful at all, and were less than great examples of how to use the API 20 years ago. Today, that entire end of the API is asking for a terrible software compatability fallback.

GLUT was the helper toolkit SGI made to wrap around simple demos, back as part of GL 1.0, before Linux even existed. FreeGLUT is just an implementation of that API.

[Octacone]

We have a discussion going, nice.
I'm still confused with all of these concepts.

When you make a 3D game, you either target OpenGL or DirectX.
If I want to port that game to my OS, I would have to implement OpenGL/DirectX and write a proprietary GPU driver.
Now, when I want to open that game, I would have to load it into memory, then the game would call some OpenGL/DirectX stuff from my OS, then that stuff would call the driver???
Why do you need Mesa (OpenGL?) if you don't have a GPU? Isn't its job to translate complicated instructions to GPU language?
Like, why do I need Mesa to draw that colorful triangle? Can't I just do some vertex math and draw to a framebuffer directly without any overhead? I'd be faster and less code.
I don't see the purpose of that library, or any library as a matter of fact.
Can't I just tell my game engine to draw directly to the GPUs framebuffer?
But, most of the code should be ran on the GPU not the CPU, so how do you actually access your GPU in order for it to act as a CPU (not talking about MMIO or modesetting)?
If there is a person willing to explain, I'd be grateful.

[reapersms]

Mesa would be a way to provide that OpenGL implementation. You could implement your own, from scratch, but that will be a significant undertaking. If the card(s) you want to target are already supported by Mesa, you may be able to use it for them as well, but it is probably going to be somewhat dependent on the particular linux DRI interface.

Mesa began as an open source implementation of the OpenGL specification. For a rather long time, you couldn't actually call it OpenGL, as that required some official testing ($$$). OpenGL itself was built to abstract away some of the hardware details, so you could just write to the spec, and it would work anywhere that had an implementation. How fast it ran would depend on how much of the rendering was handled by hardware.

A game could target a flat GPU framebuffer, but that means it needs to do all of its own rasterization (deciding which pixels the triangle needs to modify), texturing, etc. That part is certainly not trivial. It also bypasses most, if not all, of the acceleration capabilities of the GPU. Before about 1999, this was absolutely the only feasible approach for games without 3D hardware. Most/all of them were specialized for their particular needs, and applied various limitations to make it feasible. Additionally, Mesa was fairly Unix only, and nobody made 3D games for Linux at the time.

Since then, CPUs and software rendering technology have caught up a bit to the point where it isn't completely out of the question to have a software OpenGL implementation that can run a game, though you'll probably still have significant resolution limitations.

Since those times, Mesa has integrated hardware acceleration as the details get sussed out. The game speaks OpenGL, those calls go to Mesa (as the installed libGL.so or equivalent for the system), and layers inside Mesa determine how to configure the GPU to render things as requested, or routes to the software renderer.

As for the nuts and bolts of how, the short answer is "it depends on which hardware". A longer answer would be that, generally, you have a command buffer of some sort in memory, and you hammer on some MMIO registers to tell the GPU where it is, and make sure all the memory and such is mapped correctly. The contents of that command buffer will be fairly proprietary, and specific to the card model. It's going to reference buffers of vertex data, textures, and shader code, all of which will need to be laid out in ways specific to the card model. The shader code will be in a proprietary instruction set, so any shader code the game has will need to be compiled for the specific card.

What Mesa provides there is all of the API state tracking involved (legacy matrix stacks, etc), including converting that into whatever card specific structures are needed. It also provides a GLSL compiler, for converting text based GLSL shader code into the machine ISA for either the card, or generating CPU code to do the equivalent. These days it also has a SPIR-V frontend for the compiler, to accept and translate the intermediate bytecode to the concrete platform specific ISA. Lastly it will also take care of the memory and buffer management needed to feed all of that to the GPU, adhering to whatever restrictions and requirements it might have (alignment, management of the on-card memory, DMA regions, fencing, etc)

You could build your engine to talk directly to the particular card, or close to it. This is essentially what games for the various consoles (PS4, XB1, Switch, etc) do, though they are usually largely working through a proprietary API specific to each console. Those tend to provide a bit more direct access to the various hardware bits than OpenGL or DirectX normally provide. This allows for less bureaucratic overhead, but does restrict you to that platform. It is also a rather large undertaking in most cases.