This is a great project

[hdclark]

Just wanted to let you know I think this is a really neat project.

I was stuck trying to compile a cross-architecture static mesa for DICOMautomaton and ... I just don't think it will work. PortableGL, in comparison, took a tiny number of changes to integrate and build. What a lifesaver!

I still haven't been able to test the binaries work (ripped out glew init code and have not yet replaced it), but the program seems so much more tractable at this point that I had to reach out and thank you!

[rswinkle]

Thank you so much. I'm sure you know how nice it is to hear that about a project you've put a lot of time and energy into. Plus it sounds like I've succeeded on priorities 1 and 3 (Portability and Ease of Use), which is an added bonus.

DICOMautomaton looks like a great project too; it would be awesome to know that PortableGL was used in a practical project like that, and one that directly helps people.

Let me know if you have any questions, run into any problems/bugs, or have some missing critical feature (can't guarantee that I'll add it but anything's possible).

I'll leave this issue open for a while as an easy way to communicate. I mention it briefly in the README, but comparing the programs in my opengl_reference with their counterparts in PortableGL is a great way to learn the porting process.

[rswinkle]

Hey, so I just saw the recent commit that was trying out PortableGL in your project. It's good that you're grabbing it with wget rather than using a local copy from a month ago because I've made a decent number of changes in the last month and expect to make more as I work through porting learnopengl.com to PortableGL

I only skimmed over the code from that you were testing but one thing I noticed is your TexImage2D. PortableGL currently only supports RGBA (and only UNSIGNED_BYTE but that's less an issue). Stupidly, at some point I added the 1,2, and 3 formats as non-errors even though I never added full support for them (most notably in the texture access functions). It's never been a problem for me because with stb_image you can request 4 channel and it'll just fill them in no matter what the input image had.

I'm still debating if it's worth adding support for fewer channels and how. My gut says it's not worth the complexity of full internal support, but it'd be easy enough to let the user pass in anything and just convert them to 4 channel in TexImage1/2/3D, basically doing exactly what stb_image does so I don't have to change anything else.

[hdclark]

Thanks for checking in. I spent a bit of time porting to get a minimal openGL window with imgui vertex buffers, and got my code to compile, but none of the machines I tested would successfully initialize SDL.

I was planning to isolate a minimal test case, but had to put it on hold for a bit. Maybe you have some insight?

My goal is to use Alpine Linux (with musl toolchain) to compile a static binary with SDL, imgui, and PortableGL. I currently make CI builds using Alpine without SDL, so the non-GL basics are sorted out.

Alpine has a 'sdl2-static' library which seemingly supports X11, Wayland, and DirectFB. Running the compiled program on X11 and Wayland resulted in SDL initialization failures. I thought maybe DirectFB would be the safest bet, since it seems to best fit the static link use-case. There is a DirectFB-in-X11 helper in the 'libdirectfb-extras', but it also seems to fail. Testing on Arch Linux with nouveau drivers fails (regular user or root, note that /dev/dri is present). Testing on Ubuntu latest release with NVIDIA drivers likewise fails.

I don't know enough about the graphics stack to know if I'm doing something obviously wrong...

My next approach was to compile sdl2-static on Alpine without X11 support. But reflecting on this now, I'll rather try build one of the PortableGL examples using the same Alpine toolchain.

On 10/27/21, Robert Winkler @.***> wrote:

Hey, so I just saw the recent commit that was trying out PortableGL in your project. It's good that you're grabbing it with wget rather than using a local copy from a month ago because I've made a decent number of changes in the last month and expect to make more as I work through porting learnopengl.com to PortableGL

I only skimmed over the code from that you were testing but one thing I noticed is your TexImage2D. PortableGL currently only supports RGBA (and only UNSIGNED_BYTE but that's less an issue). Stupidly, at some point I added the 1,2, and 3 formats as non-errors even though I never added full support for them (most notably in the texture access functions). It's never been a problem for me because with stb_image you can request 4 channel and it'll just fill them in no matter what the input image had.

I'm still debating if it's worth adding support for fewer channels and how. My gut says it's not worth the complexity of full internal support, but it'd be easy enough to let the user pass in anything and just convert them to 4 channel in TexImage1/2/3D, basically doing exactly what stb_image does so I don't have to change anything else.

-- You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub: https://github.com/rswinkle/PortableGL/issues/2#issuecomment-953531547

[hdclark]

Just to add a bit more detail, the error messages I get when SDL_init fails are "No available video device".

Not sure if this will help, but here are the core bits I changed in my working patch. I think they follow the PortableGL examples closely, but I can't confirm with a test case at the moment.

+#define PORTABLEGL_IMPLEMENTATION
+#include <portablegl.h>

+    SDL_SetMainReady();
+    SDL_Init(SDL_INIT_VIDEO);

+    SDL_Renderer* ren = SDL_CreateRenderer(window, -1, SDL_RENDERER_SOFTWARE);
+    SDL_Texture* tex = SDL_CreateTexture(ren, SDL_PIXELFORMAT_ARGB8888, SDL_TEXTUREACCESS_STREAMING, 1280, 768);
+    
+    uint32_t *bbufpix = nullptr;
+    
+    glContext pgl_context;
+    void* gl_context = &pgl_context;
+    if(!init_glContext(&pgl_context, &bbufpix, 1280, 768, 32, 0x00FF0000, 0x0000FF00, 0x000000FF, 0xFF000000)){
+        puts("Failed to initialize glContext");
+        exit(-1);
+    }
+    set_glContext(&pgl_context);

I also purged all glew code, disabled SDL_GL_CreateContext(), and removed all old-style fixed pipeline OpenGL calls.

[rswinkle]

That looks correct. The SetMainReady() is really only if you want to build and run on Windows. And make sure to define the macro before SDL.h which I didn't see in SDL_Viewer.cc. I haven't tried building on windows in a couple years iirc, but it should still work.

I agree that you should try compiling and running the PGL examples/demos on your Alpinelmusl system. If they don't work then you know it's something to do with the system.

You can confirm that it's an SDL2 issue and not a PGL issue by running the regression tests (run_tests in the testing subdirectory) which write images to disk and don't use SDL2.

I've never used a musl based system but I do know that SDL2 recommends dynamic linking and goes to great lengths to enable it even when a program has been statically linked.

I don't think any of that would cause problems but I have no idea. I'm swamped this weekend but maybe next week if I have time I'll set up an Alpine VM and clone PortableGL into it and see what I get. If you haven't already you could try the SDL2 mailing list?

[hdclark]

Lots of great ideas here, thanks. I'll keep working at it.

On Thu, Oct 28, 2021, 23:15 Robert Winkler, @.***> wrote:

That looks correct. The SetMainReady() is really only if you want to build and run on Windows. And make sure to define the macro https://wiki.libsdl.org/SDL_SetMainReady before SDL.h which I didn't see in SDL_Viewer.cc. I haven't tried building on windows in a couple years iirc, but it should still work.

I agree that you should try compiling and running the PGL examples/demos on your Alpinelmusl system. If they don't work then you know it's something to do with the system.

You can confirm that it's an SDL2 issue and not a PGL issue by running the regression tests (run_tests in the testing subdirectory) which write images to disk and don't use SDL2.

I've never used a musl based system but I do know that SDL2 recommends https://wiki.libsdl.org/Installation dynamic linking and goes to great lengths https://github.com/libsdl-org/SDL/blob/main/docs/README-dynapi.md to enable it even when a program has been statically linked.

I don't think any of that would cause problems but I have no idea. I'm swamped this weekend but maybe next week if I have time I'll set up an Alpine VM and clone PortableGL into it and see what I get. If you haven't already you could try the SDL2 mailing list?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/rswinkle/PortableGL/issues/2#issuecomment-954459472, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAHEHSQG4U4EOAAKTNOUQ33UJI3ZRANCNFSM5E4WOLZA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

[RobLoach]

Saw your note about imgui. Just a heads up that Nuklear has raw framebuffer support so it would work directly with portablegl. Though, you would need to blit the buffer.