Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add initial support for compute shaders. #152

Open
wants to merge 1 commit into
base: develop
Choose a base branch
from

Conversation

Roldak
Copy link
Contributor

@Roldak Roldak commented Mar 6, 2022

Hi!

This PR is to add the base support for compute shaders, which already allows performing arbitrary computation in SSBO objects on the GPU (see test). Binding some of the "memory barrier" API is necessary to make compute shaders usable, so I also did that.

A possible future evolution is to bind the Image units API, to allow compute shaders to perform arbitrary read/writes to textures (well, images), but I didn't need them personally yet.

Note: I added the GL.Compute and GL.Memory_Barriers packages because I couldn't think of an existing package that would be a good fit the new APIs. If you have better ideas on how to expose those I'll happily make the changes!

@flyx
Copy link
Owner

flyx commented Mar 6, 2022

Thanks for this! I will hopefully find time to give this a proper review in the coming week. A quick thought would be that GL.Memory_Barriers.Memory_Barrier could be shortened to GL.Memory.Barrier without any loss on intent. Besides, could you add a wrapper for glMemoryBarrierByRegion since that would basically be the same as the one you did already? My rule of thumb is „always add the full extend of one API reference page, never just a part of it“ because otherwise, exotic alternatives that frequently exist will never get added.

@Roldak
Copy link
Contributor Author

Roldak commented Mar 7, 2022

A quick thought would be that GL.Memory_Barriers.Memory_Barrier could be shortened to GL.Memory.Barrier without any loss on intent. Besides, could you add a wrapper for glMemoryBarrierByRegion since that would basically be the same as the one you did already?

Done!

I will hopefully find time to give this a proper review in the coming week

Sounds good!

@flyx
Copy link
Owner

flyx commented Mar 20, 2022

Sorry for the long silence. I am still figuring out how to be able to continue maintaining this library since

  • GNAT isn't natively available on aarch64-darwin
  • OpenGL 4.2+ features aren't available on macOS

The situation is that I currently cannot test anything. There are solutions like Apple's Rosetta 2 to run GNAT (creating amd64 binaries which it can then run) but that's certainly not ideal (and doesn't get me newer OpenGL features). qemu seems to be able to run an amd64 Linux but that also is a layer that can introduce additional bugs. I'll have a solution eventually but this doesn't have much priority for me since it is for one library that doesn't have much activity. It may take some more time, sorry for that.

@flyx
Copy link
Owner

flyx commented Sep 8, 2022

I'm afraid I have decided to stop maintaining OpenGLAda. This is my only active Ada project and I am not using it for anything, hence keeping up with the language and ecosystem is taking up too much of my time and I lost motivation.

I am very sorry for this. You can keep using your own fork, there won't be any upstream development happening anymore.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants