[rlgl] Add Software Rendering Support

[Bigfoot71]

This PR aims to work on the integration of software rendering support into rlgl, through an external header rlsw.h

I give to @raysan5 the privilege of choosing the name if rlsw doesn't suit him.

Additionally, the header is delivered with an MIT license in my name. I also leave the choice of the license to @raysan5. Consider this project as a donation to the community; I will not redistribute it on my side.

This header rlsw.h is intended to provide, for now, all the functionalities offered by rlgl.h for OpenGL 1.1.

Currently, rendering is done to a 32-bit RGBA buffer (8 bits per component) and a 16-bit depth buffer. The color buffer and its dimensions can be obtained via a function, and the resolution of the internal framebuffer is specified during initialization.

For the rest, I'll leave you to check the checklist.

If you notice any features that should be implemented and are missing from the checklist, please mention them or edit the post if you can.

note: This PR currently only contains the header. I will work on the integration once the checklist is complete and a decision has been made on how to integrate it into raylib.

---

Feature Checklist

Clipping

• Point Clipping
• Line Clipping
• Triangle Clipping
• Quad Clipping

Rendering

• Point Rendering
• Line Rendering
• Triangle Rendering
• Quad Rendering

Texture Support

• All Uncompressed Texture Formats Supported by Raylib
• Texture Minification / Magnification Checks
• Bilinear Filtering
• Texture Wrap Modes with Separate Support for S/T

Vertex Arrays

• Vertex Arrays Support
• Direct Primitive Drawing Mode
• Matrix Stack Support

Misc

• GL-like Getter Functions
• Framebuffer Resizing
• Perspective Correct
• Polygon Modes
• Depth Testing
• Blend Modes
• Face Culling

[Bigfoot71]

Here is a quick video example of some of the current capabilities. Note that the texture is rendered with bilinear filtering, although I agree that it may not be noticeable as it is.

simplescreenrecorder-2025-03-12_01.34.46.mp4

[ColleagueRiley]

This repeats a lot of code that RLGL does for you.

RLGL already handles the OpenGL 1 like abstraction and the marxies, so I think it would make more sense to build from the modern opengl setup and render everything in rlDrawRenderBatch.

[Bigfoot71]

Additionally, I chose to implement triangle rasterization using the scanline method rather than barycentric interpolation method.

Barycentric interpolation can be much more efficient when implemented with SIMD optimizations and is also conceptually simpler (excluding SIMD considerations).

However, I assumed that the goal here is not to achieve maximum performance on a modern desktop CPU but rather to enable raylib to run on platforms that lack OpenGL support, including software rendering.

When properly implemented, the scanline method requires fewer computational resources and offers better cache locality, making it a more suitable choice for embedded systems and older hardware.

[Bigfoot71]

This repeats a lot of code that RLGL does for you.

RLGL already handles the OpenGL 1 like abstraction and the marxies, so I think it would make more sense to build from the modern opengl setup and render everything in rlDrawRenderBatch.

@ColleagueRiley Yes, I know, and it is a deliberate choice for several reasons.

The first is that we will be able to integrate its implementation directly into the parts currently dedicated only to OpenGL 1.1 only, we can therefore also be sure that it does not generate any duplication during the build.

The second reason is that if we ever want to implement lighting support, the current matrix stack system in rlgl for OpenGL 2+ could be problematic, especially when computing the normal matrix.

[ColleagueRiley]

@Bigfoot71 I'm also not sure if the dedicated legacy OpenGL backend makes sense, when it can easily be integrated.

[Bigfoot71]

@Bigfoot71 I'm also not sure if the dedicated legacy OpenGL backend makes sense, when it can easily be integrated.

@ColleagueRiley Do you also want to add shader support? Reinvent the Mesa driver for raylib? No one is going to do that.

Unless we use function pointers or something like that, but it's simply not compatible.

Anyway, the goal of this implementation is to enable raylib to run on machines that don't even have a software driver for OpenGL. We’re not going to implement what hasn’t been done for these machines ourselves, it would be absurd to think that.

[ColleagueRiley]

I meant it can be integrated into the modern API. I think it's more important RLGL is refactored to support additional backends. Not only to make this software rendering backend, but it would help users that want to add custom support for the native graphics API.

[Bigfoot71]

TL;DR: Adding support for modern APIs will require abandoning OpenGL, and in such a case, adding software rendering support for platforms that don't support OpenGL would then be strange.

---

Ah, excuse me, I see, but there would be several problems with that.

Relying on the batch system would just be a waste of memory in this specific case, unless we attempt very specific software rendering architectures, which wouldn't necessarily be relevant for the target devices (where memory is limited).

There is also the issue of the current management of matrices by rlgl, as I mentioned before.

Moreover, this could become increasingly confusing as to which features are implemented or not for each backend.

---

Also, I’ve reconsidered what you said about refactoring rlgl to allow the implementation of different backends.

If this is with the intention of implementing Vulkan, Metal, and D3D12, there will be many other problems that will arise, such as, for example, one of the most obvious that comes in my mind: VAOs.

Not to mention the specific implementations that will be needed to support OpenGL in order to align with the principles of immutable pipelines.

Implementing a modern API in the right way will require sacrifices for older APIs.

And here we are talking about a hypothesis that, if chosen, will take a very long time to materialize. I am ultimately quite skeptical.

Favoring modern APIs, neglecting OpenGL, but still adding support for software rendering seems like a somewhat obscure decision.

Anyway, this restructuring is a good idea in itself, but if it's done, then I find adding software rendering support quite strange.

In any case, I am just offering a potential solution to Raysan's long-standing request; it's up to him to decide.

[ColleagueRiley]

@Bigfoot71 It wouldn't require too many changes, it would be more of a reorganization effort. I don't think there's much benefit for direct support for DirectX or Vulkan, but it would be nice to be able to support native APIs.

This would not involve neglecting Legacy OpenGL, it could be implemented like any other custom backend.

As for memory usage, I'm unsure how much that would be a problem.

[Bigfoot71]

@ColleagueRiley There will inevitably be a choice to make regarding which APIs to prioritize.

For example, with Metal, if OpenGL is favored, it requires some consideration because if the Metal support is poorly suited to work with OpenGL, then wouldn’t ANGLE already do a better job?

Creating a low-level abstraction for multiple APIs, including both old and modern ones, will inevitably mean neglecting some, that's unavoidable...

So, my opinion is that:

• Either we prioritize modern APIs going forward, in which case software rendering support is irrelevant
• Or we decide to prioritize OpenGL, but I think projects like ANGLE will always do a better job than what we can achieve here

[ColleagueRiley]

The purpose of software rendering is to support certain platforms that do not support OpenGL, but many of those platforms would support GPU rendering via alternative APIs, for example, the Wii has its graphics API.

I don't think RLGL should be implementing these, but making it easier for users to implement their own would be nice.

[Bigfoot71]

Mhh I see, but creating a basic API that we can only judge as being adapted to the maximum number of possible APIs, including proprietary ones, seems like a bad idea to me.

[raysan5]

@Bigfoot71 thank you very much for this fantastic header! From my point of view, simplicity is key.

Being able to support some basic software rendering option for platforms with no OpenGL driver support with minimal changes in current raylib implementation seems a very valid reason to me. I specially have in mind the upcoming range of RISC-V micro-computers we will be probably seeing soon in the market (most of them with no GPU).

About the implementation into raylib, I see most rlsw functions map directly to OpenGL 1.1 counter-parts so it would be nice that the OpenGL1.1-mapping was done directly in the rlsw header, so in rlgl it can be simply implemented using:

#if defined(GRAPHICS_API_OPENGL_11_SOFTWARE)
    #define RLSW_IMPL
    #include <rlsw.h>          // OpenGL 1.1 software implementation

    #define GRAPHICS_API_OPENGL_11
#endif

Beside that, some platform layer (RGFW?) should support a raw color framebuffer initialization and screen blitting.

[Bigfoot71]

Okay, no problem, I'll continue writing right away.

Since some features of GL 1.1 related to certain function parameters are not used in RLGL, I will simply write a binding using macros and omit these parameters.

I will also create macros to generate functions based on rendering parameters and add line rasterization and blend modes.

This could go very fast!

[ColleagueRiley]

This doesn't make much sense to me. If you're going to add a software rendering backend, then it makes more sense to implement it as a custom backend rather than working around the legacy OpenGL framework, as it could be more performant and useful.

If you do not care about the performance, the legacy OpenGL backend can already easily do software rendering. Without any modifications to Raylib at all.

If you wanted to ensure it's rendering to a pixel buffer, you could use OSMesa. That wouldn't require any changes to RLGL.

[Bigfoot71]

as it could be more performant and useful.

@ColleagueRiley Explain why not implementing it through legacy OpenGL would be more efficient? Especially if you say "more useful", then what features would be missing? Knowing that any added feature will inevitably make it less efficient in some way.

you could use OSMesa

We have already talked about it: #3928 (comment)

And this may not be suitable for all scenarios considered by Ray.

[Bigfoot71]

No matter what, what we are doing here is not incompatible with your suggestion to refactor rlgl in the future.

And even if we implement the possibility of using different backends with rlgl, it does not solve the problem that each platform requires specific implementations for copying color buffers to the screen.

[raysan5]

@Bigfoot71 Just to clarify some points in case I missed something:

1. rlsw is a single-file header-only self-contained portable partial-OpenGL 1.1 implementation, that draws into an RGBA RAM memory buffer, right?
2. The required "OpenGL context" is actually sw_data_t, a global variable contained in rlsw implementation.
3. swFunctionName() are a direct mapping/implementation of the OpenGL glFunctionName()
4. The "only" requirements on raylib side for basic software rendering functionality would be:
   • InitWindow() - Provide a system (double)framebuffer to flip rlsw generated frames.
   • CloseWindow() - Free the provided (double)framebuffer and rlsw loaded "context resources"
   • SwapScreenBuffer() - Copy data and swap buffers, back to front
5. This implementation (plus some extra platform logic) would allow raylib running on no-GPU devices like RaspberryPi Pico 2 or similar RISC-V alternatives, is that correct?
6. In terms of performance, what is the performance hit in comparison to a GPU-accelerated implementation? Maybe 10% performance?
7. Is there any other single-file header-only portable alternative to accomplish the same?

Thanks for your answers! 😄

[Bigfoot71]

@raysan5

---

1. rlsw is a single-file header-only self-contained portable partial-OpenGL 1.1 implementation, that draws into an RGBA RAM memory buffer, right?

Yes

---

2. The required "OpenGL context" is actually sw_data_t, a global variable contained in rlsw implementation.

Yes

---

3. swFunctionName() are a direct mapping/implementation of the OpenGL glFunctionName()

Not exactly, I made a few simplifications compared to what rlgl does with GL 1.1, but I will add a binding corresponding to the OpenGL API that handles these small differences. It will be done through macros, and there will be no overhead.

---

4. The "only" requirements on raylib side for basic software rendering functionality would be:

* `InitWindow()` - Provide a system (double)framebuffer to flip `rlsw` generated frames.

* `CloseWindow()` - Free the provided (double)framebuffer and `rlsw` loaded "context resources"

* `SwapScreenBuffer()` - Copy data and swap buffers, back to front

That's exactly it, in the end, nothing more should be necessary.

---

5. This implementation (plus some extra platform logic) would allow raylib running on no-GPU devices like RaspberryPi Pico 2 or similar RISC-V alternatives, is that correct?

Exactly!

---

6. In terms of performance, what is the performance hit in comparison to a GPU-accelerated implementation? Maybe 10% performance?

It’s a bit early to say, the first video I presented wasn’t optimized yet.

I just added function generation based on the state (whether textures are being sampled or not, depth test on or off, etc.)

With this new addition, I now see the counter going above 2000 FPS for the same example, so I would say an improvement of around ~x1.5 roughly.

But it’s still early, other optimizations are still possible, and I will do thorough testing at the end.

---

7. Is there any other single-file header-only portable alternative to accomplish the same?

Contained in a single header with the same functionalities, no, at least not to my knowledge.

Edit: Aside from PortableGL, but it's different, as it aims to support more modern versions of OpenGL.
But, for example, shaders are managed via function pointers, which is problematic in our case.

[ColleagueRiley]

OpenGL 1.0 will already use software rendering by default if there is no GPU. I don't think this is fixing a clearly defined problem.

[Bigfoot71]

OpenGL 1.0 will already use software rendering by default if there is no GPU. I don't think this is fixing a clearly defined problem.

This depends on the platform and the driver

See for example:

• Raspberry Pi Pico (RP2040)
• Arduino Zero
• Arduino Nano 33 BLE

[raysan5]

@ColleagueRiley Actually it will allow this:

5. This implementation (plus some extra platform logic) would allow raylib running on no-GPU devices like RaspberryPi Pico 2 or similar RISC-V alternatives, is that correct?

For me this is the most notable achievement and step towards the future. Afaik, no other alternative allows that, at least in a simple way.

Note that this will expand raylib to low-level embedded devices and microcontrollers.

[ColleagueRiley]

Ok, I think I've said most of what I want to say on this.

I can help with the platform part.

[Bigfoot71]

I can help with the platform part.

Cool, as soon as I have done the OpenGL binding macros, we can start this. I'll mention it when it's ready.

[Bigfoot71]

@raysan5 Also, I wanted to know, AFAIK OpenGL 1.1 supported trilinear filtering but did not yet provide mipmap generation in the API.

Should we then postpone trilinear filtering and implement mipmap generation on the CPU for Image directly in raylib before?

---

By the way, I accidentally implemented the texture wrap modes GL_CLAMP_TO_EDGE and GL_MIRRORED_REPEAT, even though they don't seem to be available in GL 1.1 ...

[raysan5]

@Bigfoot71 OpenGL 1.1 has no mipmap auto-generation, actually old raylib versions implemented mipmaps generation but it was removed to simplify code some time ago.

Personally, I think trilinear filtering is not a priority for software rendering and also an added performance cost.

Considering this software renderer alternative is mostly focused to no-GPU devices, probably low-end, I'd minimize advance costly features.

[Bigfoot71]

I just ran a quick test with a sphere that has 64 rings and slices, rendered in immediate mode, at a resolution of 800x600 (with color and depth buffer cleared). I then wrote a version using rlgl.

• With rlsw, I get an average of 308 FPS over 1 minute
• With rlgl, I get an average of 1654 FPS over 1 minute

This means, for now, about 18.62% of the performance of the GPU

With this setup:

• CPU: AMD Ryzen 5 3600
• GPU: Nvidia GTX 980

There are of course many other factors that could influence this, and I didn’t conduct these tests under the most rigorous conditions.

But for 3D rendering without SIMD or parallelization, this seems like a good start to me.

This is just a quick overview, I will perform more in-depth tests later, knowing that several other optimizations are possible

---

Here is the example in question in video:

out.mp4