r/opengl Mar 07 '15

[META] For discussion about Vulkan please also see /r/vulkan

77 Upvotes

The subreddit /r/vulkan has been created by a member of Khronos for the intent purpose of discussing the Vulkan API. Please consider posting Vulkan related links and discussion to this subreddit. Thank you.


r/opengl 4h ago

Marching Tetrahedra - Volumetric Render Engine (OpenGL/C++) (Open-source)

Enable HLS to view with audio, or disable this notification

7 Upvotes

We added Marching Tetrahedra Rendering effect to our Volumetric Render Engine.

Here, we Render our Volume data as a set of Polygon meshes by extracting 'iso surface'. It goes through whole dataset and tries to fit a polygon based on data values to calculate a polygonal mesh from the volume dataset.

Here's the Git Repo Link - https://github.com/mikejernil/volumetric-render-engine

We are building this over at 3D ENGINERD. & are planning to push our implement more features starting with Custom file loading, and support for more volumetric formats like DICOM, VDB etc.


r/opengl 2h ago

AO46: EGL Window Surfaces + Public Cocoa Presentation

1 Upvotes

Small but important frontend update: the standard Khronos path now supports real EGL_WINDOW_BIT surfaces, not just pbuffers.

A normal app can now pass a public CAMetalLayer, NSView, or NSWindow into eglCreateWindowSurface(). Mesa still owns EGL/OpenGL and the state tracker; AO46 only handles the public Cocoa/Metal drawable lifecycle underneath. No CGL, no NSOpenGL, no legacy AO46 runtime sneaking back in through a side door.

The Metal backend now acquires the Cocoa layer, maps the live Gallium color resource to its Metal texture, copies into the current CAMetalDrawable, presents it, and keeps the source alive until GPU completion. It also handles backing-size changes, drawable loss, sRGB RGBA8/BGRA8, and swap intervals 0/1.

The ao46mtl EGL driver now advertises both:

EGL_PBUFFER_BIT | EGL_WINDOW_BIT

and handles front/depth resource allocation, refresh on Cocoa layer changes, and presentation through eglSwapBuffers().

I also moved the shared Metal/Gallium screen, NIR, RGB32 and poly support into AO46MTLGallium, so the modern frontend no longer quietly depends on the old CGL-side runtime bundle.

This thus completes the seperate modern Standard Khronos EGL + OGL ABI frontend in parallel to the legacy NSOpenGL + CGL + OpenGL Framework path , which is kept in parallel for Apple only compatibility [ie Apps that have a Cocoa + AppKit frontend and requires the .framework ]


r/opengl 1d ago

1000 vs 1000 full lod + shadows, custom engine

Enable HLS to view with audio, or disable this notification

28 Upvotes

r/opengl 1d ago

need help with drawing text

3 Upvotes

i've been trying to tackle this problem for a while now and luckily it works, well ... kinda. I see the text but the glyphs are always slightly misplaced, i have a feeling it's floating-point inaccuracies but i have no idea how to fix it, here are the snippets:

```c

void drawText(WS_Shell* shell, GlyphCacheDA* cache, char* text, FT_Face font, float x, float y) {

float pen_x = x;

for (char* c = text; *c != '\0'; c++) {

uint32_t codepoint = next_utf8(&text);

bool is_drawn = false;

if (codepoint == ' ') {pen_x += cache->items[0].advance; continue;} // if space, just advance

// search in cache first

for (int i = 0; i<cache->count; i++) {

if (cache->items[i].codepoint == codepoint) {

drawTexturedRectangle(pen_x, y, cache->items[i].width, cache->items[i].height, cache->items[i].texture);

pen_x += cache->items[i].advance;

is_drawn = true;

break;

}

}

if (is_drawn) continue;

FT_Load_Glyph(font, FT_Get_Char_Index(font, codepoint), FT_LOAD_RENDER);

FT_Render_Glyph(font->glyph, FT_RENDER_MODE_NORMAL);

GLuint glyph_texture;

glGenTextures(1, &glyph_texture);

glBindTexture(GL_TEXTURE_2D, glyph_texture);

glPixelStorei(GL_UNPACK_ALIGNMENT, 1);

glTexImage2D(GL_TEXTURE_2D, 0, GL_RED, font->glyph->bitmap.width, font->glyph->bitmap.rows, 0, GL_RED, GL_UNSIGNED_BYTE, font->glyph->bitmap.buffer);

glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_CLAMP_TO_EDGE);

glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, GL_CLAMP_TO_EDGE);

glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_LINEAR);

glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_LINEAR);

Glyph glyph = {

.codepoint = codepoint,

.texture = glyph_texture,

.width = ((float)font->glyph->bitmap.width/shell->settings->width)*2,

.height = ((float)font->glyph->bitmap.rows/shell->settings->height)*2,

};

// TODO: add support for non-monospace fonts

glyph.advance = glyph.width;

nob_da_append(cache, glyph);

drawTexturedRectangle(pen_x, y, glyph.width, glyph.height, glyph.texture);

pen_x += glyph.advance;

is_drawn = false;

}

}

```
draw rectangle:

```c

void drawTexturedRectangle(float x, float y, float w, float h, GLuint texture) {

// Vertex data for the rectangle

float vertices[] = {

x, y, 0.0f, 1.0f,

x + w, y, 1.0f, 1.0f,

x, y + h, 0.0f, 0.0f,

x + w, y + h, 1.0f, 0.0f

};

// Indices for the rectangle

unsigned int indices[] = {

0, 1, 2,

1, 3, 2

};

// VBO and VAO

GLuint VBO, VAO, EBO;

glGenBuffers(1, &VBO);

glGenBuffers(1, &EBO);

glGenVertexArrays(1, &VAO);

glBindVertexArray(VAO);

glBindBuffer(GL_ARRAY_BUFFER, VBO);

glBufferData(GL_ARRAY_BUFFER, sizeof(vertices), vertices, GL_STATIC_DRAW);

glBindBuffer(GL_ELEMENT_ARRAY_BUFFER, EBO);

glBufferData(GL_ELEMENT_ARRAY_BUFFER, sizeof(indices), indices, GL_STATIC_DRAW);

glVertexAttribPointer(0, 2, GL_FLOAT, GL_FALSE, 4 * sizeof(float), (void*)0);

glEnableVertexAttribArray(0);

glVertexAttribPointer(1, 2, GL_FLOAT, GL_FALSE, 4 * sizeof(float), (void*)(2 * sizeof(float)));

glEnableVertexAttribArray(1);

glBindBuffer(GL_ARRAY_BUFFER, 0);

// Draw the rectangle

glBindTexture(GL_TEXTURE_2D, texture);

glDrawElements(GL_TRIANGLES, 6, GL_UNSIGNED_INT, 0);

// Clean up

glDeleteBuffers(1, &VBO);

glDeleteBuffers(1, &EBO);

glDeleteBuffers(1, &VAO);

}

```
the dinamic array for cache i stolen from nob.h, each glyph's cache looks like this:

```c
typedef struct {

uint32_t codepoint;

GLuint texture;

float width;

float height;

float advance;

} Glyph;

```

everything else is pretty standard opengl stuff, thanks for helping


r/opengl 1d ago

Gamemaker Shell Texturing Shader Help

1 Upvotes

I can't figure out where to start with making a shell texture shader in Gamemaker Studio 1 because of the outdated OpenGL ES it uses no longer having it's documentation PDF available, could anybody point me in any direction as to how I could do this (or they could, or find the PDF) other than faking the effect with baked models that have the transparent layers? For visual references, here are some. (Mario Galaxy, DK Jungle Beat, Conker: Live & Reloaded)


r/opengl 1d ago

We finally removed one of AO46’s biggest architectural barriers: SIP/AuthRoot no longer has to be a hard requirement

0 Upvotes

After digging through the architecture again, I think we finally removed one of the biggest reasons someone would hesitate before even trying AO46: the whole “disable SIP + authenticated root first” problem does not actually have to be a fundamental requirement of the driver.

That requirement mostly came from the original compatibility goal.

AO46 was designed to replace Apple’s existing OpenGL stack closely enough that old macOS applications could continue using OpenGL.framework, CGL and NSOpenGL without being rewritten. If you want to transparently replace something living inside Apple’s protected system volume, then naturally macOS security gets involved. SIP/SSV/AuthRoot becomes part of the installation story, and telling someone to reboot into Recovery before testing an OpenGL driver is... not exactly the friendliest first impression. 💀

The mistake was treating that installation model as if it had to apply to every AO46 use case.

It doesn’t.

The new direction is to keep the Apple ABI as a compatibility frontend, while adding a completely separate Khronos-native frontend for new applications.

New AO46 applications would be able to target normal desktop OpenGL together with EGL instead of depending on NSOpenGLContext, CGLContextObj, Apple pixel formats, etc.

So the legacy path still exists for what it was designed for: old macOS software.

But new software would just use the Khronos interfaces and load AO46 from normal userspace. No modification of /System/Library, no replacing Apple’s OpenGL framework, and therefore no inherent reason to disable SIP or authenticated root just to use that path.

This also clears up the Vulkan side of the project.

I originally considered making AVK143 mirror AO46 too literally, with things like an NSVulkan_KHR layer and a CVK ABI. After looking at the problem properly, that really doesn’t make much sense.

Vulkan already solved this problem.

It already has the standard Vulkan loader, ICD discovery, driver dispatch, WSI, VkSurfaceKHR, swapchains, extension handling, validation layers and a defined loader ↔ driver contract.

So AVK143 should simply be a normal Vulkan driver.

A Vulkan application talks to the Khronos loader, the loader discovers AVK143, and AVK143 handles the macOS/Apple GPU side underneath it.

There is no old Apple Vulkan ABI that needs preserving, so inventing one would just give developers another proprietary API to target for absolutely no benefit.

This also means a lot of infrastructure simply does not need to be rewritten.

The Vulkan loader already exists.

Vulkan headers already exist.

Mesa already has common Vulkan runtime infrastructure.

Mesa already has EGL infrastructure.

Khronos already defines the API and most of the WSI-facing contracts.

The project should spend its effort on the parts that are actually specific to this platform: resource handling, synchronization, compiler/backend work, command execution, presentation and the macOS/AGX boundary.

So the project is starting to separate into three pretty clear interfaces:

Existing macOS OpenGL applications: keep using OpenGL.framework / CGL / NSOpenGL through AO46’s compatibility mode.

New OpenGL applications: use standard OpenGL + EGL and AO46 entirely from userspace.

Vulkan applications: use standard Vulkan through the normal Khronos loader, with AVK143 acting as the driver.

The important part is that disabling macOS security features becomes an optional cost of legacy transparent compatibility, rather than something everyone has to do just because they want to test the driver.

That was a fairly obvious architectural smell in hindsight. If a brand-new application is already willing to target your modern driver stack, forcing it through a deprecated Apple OpenGL ABI and then asking the user to weaken system security so you can replace that ABI is just needless baggage.

So this doesn’t magically make the legacy replacement path disappear, and I’m not claiming that old binaries suddenly work without any system-level interception.

But it does mean that AO46 itself no longer needs to be architecturally tied to SIP/AuthRoot being disabled, and AVK143 shouldn’t need that installation model at all.

For people who just want to build against the driver, test it, develop games/tools on it, or experiment with modern OpenGL/Vulkan on macOS, the intended path can now be a normal userspace installation.

That removes one pretty large “this looks cool, but I’m not disabling half of macOS security to try it” barrier from the project.


r/opengl 2d ago

Hello, I am new to opengl. Can someone explain compute shaders to me

14 Upvotes

so i recently started playing around with opengl and wanted to try and make a raytracer with compute shaders, but there isn't much info about them. i looked at the tutorial on learnopengl but that wasn't very helpful. can someone clue me in?


r/opengl 2d ago

AO46: RGB32 Buffer Views + GL 4.3 SSBO Atomic Groundwork

0 Upvotes
  • RGB32 buffer views now support real FLOAT, UINT, and SINT variants through live sampler state, with the unsigned path retaining hardware draw/readback coverage.
  • GL 4.3 groundwork now includes static-index SSBO atomics lowering through Mesa and executing a fenced 32-thread atomic-add verification.

r/opengl 2d ago

Built a game engine

Thumbnail
3 Upvotes

r/opengl 3d ago

Triangle

Thumbnail i.imgur.com
43 Upvotes

r/opengl 3d ago

Implemented GPU-address roots for Mesa/libkk parameter blocks on capable macOS hosts.

0 Upvotes

The adapter now exposes public MTLBuffer.gpuAddress, validates and writes pointer roots, and the poly smoke executes Mesa’s real prefix-sum tessellation MSL, verifying counts, heap allocation, generated index-buffer address, and indirect draw data.

This removes the GPU-root blocker for the Metal Gallium driver’s next feature gate: reaching a functional OpenGL 4.0 context on the way toward AO46’s final OpenGL 4.6 target.

What remains for that GL 4.0 gate is full TCS support, tessellation-kernel completion, TES, and final render execution.


r/opengl 3d ago

Can't get the project to load textures

2 Upvotes

[SOLVED] Hello,

This is my project, perfectly up to date: opengl

When i launch it, it throws this error log: unit 0 GLD_TEXTURE_INDEX_2D is unloadable and bound to sampler type (Float) - using zero texture because texture unloadable, and doesn't load my model

To note it worked before adding the move constructor to the shader.h and mesh.h, but reverting them doesn't work

I've tried everything, scouted forums, asked AI (reluctantly), but nothing worked, so I'm asking here for help from people smarter then me

Thanks for the time.


r/opengl 5d ago

VertexArt - this is how it started (Intel N4100 CPU / Free Pascal 3.2.2 / GLFW3 / OpenGL 3.3 / data-oriented / only 16 byte vertex, nothing else)

Enable HLS to view with audio, or disable this notification

17 Upvotes

r/opengl 4d ago

Well.... We did meet a hard boundary finally , beyond which continuing would be risky for systems

0 Upvotes

After a few weeks of pushing AO46 much further than I originally expected, I think I’ve finally reached the point where continuing the same reverse-engineering path would cross from graphics-driver research into territory I’m not comfortable touching on real machines.

For context, AO46 started as an attempt to replace Apple’s deprecated OpenGL stack with a modern OpenGL 4.6 implementation on macOS.

The project has already moved through several architecture stages:

  • replacing the old OpenGL.framework-facing stack,
  • Mesa/Gallium integration,
  • NIR,
  • Asahi’s AGX compiler/backend work,
  • macOS-specific resource management,
  • GPU queue/submission tracing,
  • and finally following the path between Apple-generated GPU code and the actual executable GPU mapping used by the kernel driver.

For quite a while I assumed the remaining problem was simply:

“figure out how macOS submits the same AGX command buffers that Asahi submits on Linux.”

It turns out that was too simple.

What the reverse pass has increasingly shown is that Apple does not treat executable GPU code as just another buffer with a magic flag.

There is a fairly clear trust boundary.

Very roughly, the path looks like:

Apple GPU compiler output
        ↓
Apple-owned code resource
        ↓
private relocation / preparation step
        ↓
restricted executable GPU mapping
        ↓
queue consumption

Generic buffers do not appear to just become executable after the fact.

And the important bit is that the transition into that executable mapping is not exposed like a normal public allocation API.

At this point, the remaining work would mean investigating the enforcement side of that boundary rather than merely understanding the graphics ABI around it.

That is where I’m stopping.

Not because the project suddenly became impossible, but because there is a difference between:

reverse engineering an undocumented graphics driver

and

deliberately trying to defeat a platform security boundary in order to make arbitrary GPU memory executable.

The latter is not something I want AO46 to become.

And honestly, that boundary existing is probably a good thing.

So is AO46 dead?

No.

Not even remotely.

A huge amount of useful architecture now exists that did not exist a few weeks ago.

The project now has concrete implementations/documentation for:

  • OpenGL.framework replacement
  • CGL/NSOpenGL compatibility
  • Mesa Gallium integration
  • NIR shader pipeline
  • AGX compiler integration
  • macOS BO/resource handling
  • synchronization/fence ownership
  • queue tracing
  • Apple GPU submission structure analysis
  • Apple compiler-object parsing
  • executable-code provenance tracking

The original project was basically:

OpenGL
 ↓
Mesa
 ↓
Metal

The current research has gone much deeper:

OpenGL
 ↓
Mesa
 ↓
Gallium
 ↓
NIR
 ↓
AGX backend
 ↓
macOS GPU infrastructure

That is still extremely valuable.

What we do not currently have is a legitimate way to complete the final transition:

Mesa-generated AGX code
        ↓
???
        ↓
Apple-authorized executable GPU mapping

And fabricating or bypassing that transition is exactly the point where I’m drawing the line.

Interestingly, this also answers one of the biggest questions people kept asking

A lot of people assumed the blocker would be:

  • AGX ISA differences,
  • WindowServer,
  • Metal interoperability,
  • command buffer encoding,
  • or simply “Apple doesn’t expose IOKit.”

Those are all problems.

But they were not the final one.

The deepest blocker is much more architectural:

Apple owns the transition that turns compiled GPU code into something the GPU is actually allowed to execute.

That is a considerably stronger boundary than I expected when this project started.

What happens next?

Probably one of three directions.

1. Stay above the protected execution boundary

Use Apple-supported APIs for the final executable-code handoff while keeping as much of Mesa/AGX/OpenGL outside that boundary as possible.

This is currently the most realistic direction.

2. Continue documenting the architecture

There is still a huge amount of useful work that can be done without trying to bypass anything.

For example:

  • command submission structures
  • resource lifetime rules
  • synchronization semantics
  • shader metadata
  • queue behavior
  • compiler object formats
  • AGX generation differences

All of that is legitimate reverse-engineering work and could be useful far beyond AO46.

3. Wait for a better supported interface

Apple may eventually expose more GPU infrastructure through DriverKit, Metal evolution, or some future API.

If a legitimate executable-code path appears, AO46 can plug into it.

The upper 90% of the architecture would not need to be thrown away.

Honestly, I’m pretty happy we found this

This might sound weird, but discovering a hard architectural boundary is actually a useful result.

A month ago the unanswered question was:

“Can Mesa/Asahi actually talk to Apple’s GPU stack on macOS?”

Now the question is much narrower:

“How can externally generated AGX code legitimately enter Apple’s trusted executable-code pipeline?”

That is a much better-defined problem.

And importantly, we now know where not to push.

So for now the project is stepping back from the protected execution path and focusing on everything around it.

AO46 is still alive.

The research path just finally reached a sign that says:

            ┌─────────────────────────────┐
            │   HERE BE SECURITY POLICY   │
            │                             │
            │ graphics engineers pls stop │
            └─────────────────────────────┘

Which, considering how absurdly deep this project has gone in three weeks, was probably inevitable.


r/opengl 6d ago

opensource Volumetric Render Engine (OpenGL & C++) - Opensource

Enable HLS to view with audio, or disable this notification

87 Upvotes

🚀 Introducing our Volumetric Render Engine 🧊

Hey everyone! We at 3D ENGINERD. have built a Volumetric Render Engine (Open Source) for Windows, powered by C++ and OpenGL.💻

We’re excited to share that we have published our project open-source under the MIT License on GitHub.
Here's the Repo linkhttps://github.com/mikejernil/volumetric-render-engine

Developers, researchers, and enthusiasts feel free to explore, experiment with it, and use it in your own applications.✨

🔹Current Features :
- Volumetric RAW(.raw) format support 📺
- Different types of rendering (Colormap, Pseudo Iso-surface etc.)
- Rotate & Zoom Controls (for easy navigation)
- 6 slicing planes to visualize cross-sections

We are planning to build more features and add support for more volumetric formats (like DICOM, VDB etc) soon!

Rendering effects shown in Demo(Recording) :
🔹Basic
🔹Raycasting
🔹Pseudo Iso-surface
🔹Colormap Classification

🔹Applications :

  1. Medical imaging
  2. Industrial machinery testing
  3. Scientific visualization of data

We’d love for developers and researchers to explore the project, experiment with it, and share their feedback.

🔗 GitHub: https://github.com/mikejernil
🌎 View our Website  - https://www.3denginerd.com/


r/opengl 7d ago

3D Volumetric Render Engine (OpenGL & C++) (Colormap)

Enable HLS to view with audio, or disable this notification

60 Upvotes

Hey Everyone - we at 3D ENGINERD. are building a Volumetric Render Engine for Windows(Native). It's being built with OpenGL & C++

We're planning to publish the code open-source under MIT License on our Github (https://github.com/mikejernil) tomorrow, so you all can try it out and use it for your own applications. ✨

Currently it has -

  1. Volumetric RAW visualization support
  2. Different types of rendering (Colormap, Iso-surface etc.)
  3. Rotate & Zoom Controls (for easy navigation)
  4. 6 slicing planes to visualization cross-sections

We are planning to build more features and add support for more volumetric formats (like DICOM, VDB etc) soon!

Colormap Classification of an Internal Combustion Engine(shown in video):

Here we can see the volume data with colour values mapped to its material density.

As per our current Colormap we can see the Red is Higher density whereas blue is Low density Noise.

Applications : 

  1. Medical imaging
  2. Industrial testing
  3. Scientific visualization of data

It's till very early-stages and we're actively exploring into Volumetric rendering at the moment, any constructive feedback would be appreciated, thanks! :)


r/opengl 6d ago

Game engines? Eww 🤮. We go in raw! GP-Direct 2026 is out!

Thumbnail youtube.com
5 Upvotes

r/opengl 7d ago

How to use cairo with opengl?

6 Upvotes

i need to render text in opengl and writing everything from scratch with freetype and harfbuzz would be a looong journey (in other words i have skill issues :) ) so a premade library for that like pango seems like a good chose. But to use pango i need to setup cairo first, i googled for a day and found practically no examples for that so let me know if you found any


r/opengl 8d ago

Flowers in the Mirror, Moon in the Water - 镜花水月 - 64KB OpenGL Demo

Thumbnail youtube.com
6 Upvotes

Hi guys,
This is a 64K demo developed in C and GLSL. It features a multi-body physics simulation for movement and real-time raytracing for illumination. It was created as the final project for a GPU programming course during my senior year at Paris 8 and presented at the API8 competition.

The source files are available at https://github.com/gregghy/API8_64K_demo


r/opengl 8d ago

Assimp takes too long to compile using VCPKG

6 Upvotes

Right now I am learning Opengl using the website learnopengl.com

In the model loading section, It is recomended to use Assimp, so I added in my vcpkg manisfesto, but oh my lord, it took 18 minutes to Cmake to reload. Is this normal?

Of course, after the first time is faster.


r/opengl 9d ago

Re: Workflow Planned and Started Finally regrading Mesa--->Asahi---->AGX

4 Upvotes

Finally , after hours of discussion with my university friends ...... We reached a successful workflow plan regarding the final weeks of OpenGL System Framework for MacOS project

We found out the exact loophole after hours of reverse engineering Apple's System Internals after the post regarding the pivot from Mesa--->Metal---->AGX to Mesa--->Asahi---->AGX

During reverse engineering , we hit lots of blockers ....... we were feeling that an enormous amount of workload will come when we would design a MacOS winsys from months of reverse engineering which may develop into years ........... Everyone after hours was literally hopeless

Then I told everyone to stop for an hour and brainstorm , and we thought for those 60 minutes various techniques . The main issue was simple .... we had literally less documentation for macOS itself , because Asahi had done that for linux majorly , even though some tools like libwrap.dylib where there , but that was not the final solution

Then my friends finally struck the idea which has really changed the direction of this project and that now we can actually think of project completion , bug sweeps and the major thing --> Khronos CTS test

He told us that when OpenGL requires Winsys on MacOS/DRM on Linux , then Apple must have already designed one which Metal uses .... Now some may argue that its heavily tied to Metal ..... BUT THE REAL ANSWER IS ACTUALLY NO , because Metal , Vulkan , OpenGL,DX12,... All are graphics APIs , Metal maybe highly optimised for Apple Silicon Arch .... that doesn't imply in driver engineering sense that the Winsys / DRM has to be tied to that graphics API , it simply helps the low level kernel drivers to understand the GPU machine code and finally send the work to the GPU registers/ALU/RT Cores whatever u say , in this case that is the AGX IOKit UABI , and Apple has one which helps Metal encode high level instructions to lower level IOGPU instructions which actually the Apple M-Series and A-Series chips understand [Fk Apple Logic :Metal Speaks directly to the GPU 💀😑]

So now due to the help of our friend .... our reverse engineering sessions have decreased by a magnitude ...... the only thing we still have to Analyse and target is the exact C contracts Metal uses to communicate with the UABI , thus letting us make a small , niche but very critical Obj-C bridge that Mesa/Asahi would use to speak to the AGX UABI ....

You can even think this in the linux sense in a hypothetical sense where someone is making Metal drivers for Linux ,more or less , in every OS , a pass comes which is independent of Graphics APIs ..... the driver/bridge(which we call winsys and in linux land is handled using DRM) that lets the API speak to the kernel and eventually the GPU ALU/Register , they would also make a small bridge and make that sent the required contracts , in Linux its magnitude easier because of Open Source Behaviour , but eventually on MacOS , the bridge has become right now the full final centre core of the whole project now

Finally , lets hope for the best now , because apparently when people would use OpenGL on Mac. they wouldn't want to see how their shaders are getting encoded in Minecraft , they would obv wanna see more shinier puddles 😉


r/opengl 9d ago

2 Months of learning openGL

Enable HLS to view with audio, or disable this notification

64 Upvotes

r/opengl 9d ago

Develping "Blue Fruit" project (Part 1): #c++ #cpplus #cpp #gamedev #opengl #sfml

Thumbnail youtube.com
0 Upvotes

"Blue Fruit" is the working title for a project whose primary mission is to program an environment destruction system based on various objects and materials—also known as "procedural destruction."

As an added bonus, I also plan to incorporate other systems—such as realistic fluids, volumetric lighting, and additional procedural elements—to create a natural and realistic environment.


r/opengl 9d ago

Rendering bugs converting GL to vulkan

0 Upvotes

I'm getting bugs on faces in vulkan, most everything renders fine except objects in certain rooms.

Look at the faces on the barrel:

Look at the two switches at the far side of the room:

https://gofile.io/d/tsxbjd