Currently I’m running macOS 12.6 on an Intel based Mac and have been trying to learn openGL. I’ve been following along with the tutorial at learnopengl.com and have found a weird bug. When running the application on the built in display everything works just fine. However, if I drag the window to one of my external displays or start the application on an external display I get openGL error 1286 (invalid frame buffer).
If it helps the monitors kinda suck. They are DELL P2214H’s and are pretty low resolution (1080X1920) when compared to the MacBooks 2880x1800 Retina display. There are also two graphics devices, an Intel UHD Graphics 630 and a Radeon Pro Vega 20. I have another monitor at home(much higher resolution) that I’ll try and see if the same frame buffer error happens(forgot about trying that).
Code running that produces error: hello triangle
After troubleshooting this problem for a few days I think the error has something to do with GLFW and not openGL and the way the frame buffer is being created. However, I have not a clue where to start looking for an issue like that.
Has anyone had this issue before and know of a fix or why this is happening?
Welcome to the GLFW forum.
Could you try one of the examples in the GLFW code such as triange-opengl.c? You should be able to build these from the source with cmake. If the example apps fail then it might be worth creating a GLFW issue on Github.
If you know how to use XCode to debug then it would be great to step through the code and see at which point the framebuffer error occurs.
With a discrete/integrated GPU Mac OS X applies some automatic rules to set the GPU the application uses, normally creating an OpenGL context sets the app to using the discrete/dedicated (High Perf) GPU. In case this is an issue you could check if the app is requiring the High Perf GPU when run on the built in display and the external displays to see if there is a difference.
A bit more detailed information about your system could be useful - which MacBook, how you are attaching your displays, and it might be helpful to run monitors.c which will list the monitor modes for all attached monitors.
@dougbinks Thanks for all the advice, I’ll try to list everything you asked for plus some more information.
I was just able to test on a different monitor with a much bigger resolution(AOC AGON AG493UCX, which supports 5120x1440 @ 120Hz). I have this display connected with a thunderbolt 4 cable and the application works just fine on both monitors.
My MacBook Pro is a 2019 15-inch with the 8-Core Intel i9, 32 GB RAM, and Radeon Pro Vega 20 with 4 GB RAM. The way that I had the old monitors hooked up was via a docking station (Startech product USB3DOCKH2DP - link). One monitor is connected directly to the docking station while the other one goes through a KVM and then to the docking station(error happened on both monitors so I don’t think the KVM is doing anything). It’s also probably worth mentioning that the cables have to have adapters on them to go from DP to DVI-I.
Now that I’ve actually typed it out I’m starting to wonder if the docking station is doing something weird? Reason I say that is because you need the software DisplayLink Manager in order for the external displays to work. Also, I’ve noticed that when dragging an app from the internal display to the external Dell display I get a call back via glfwSetFramebufferSizeCallback(). However, when testing with the AOC monitor I do not get a callback about a framebuffer resize when dragging the window between displays.
I went ahead and ran monitors.c with the AOC monitor just to have a comparison and will attach the results. Unfortunately, I don not have access to the original setup today but will have access to it tomorrow. Then I can go in and run those tests and step through the debugging. I’ll also try direct connecting the displays as well to see if that changes anything.
Internal Dispaly
Name: Built-in Retina Display (secondary)
Current mode: 1920 x 1200 x 24 (8:5) (8 8 8) 60 Hz
Virtual position: 942, 1080
Content scale: 2.000000 x 2.000000
Physical size: 330 x 207 mm (147.78 dpi at 1920 x 1200)
Monitor work area: 1920 x 1105 starting at 942, 1105
Modes:
0: 640 x 480 x 24 (4:3) (8 8 8) 60 Hz
1: 840 x 524 x 24 (210:131) (8 8 8) 60 Hz
2: 800 x 600 x 24 (4:3) (8 8 8) 60 Hz
3: 1024 x 768 x 24 (4:3) (8 8 8) 60 Hz
4: 1152 x 720 x 24 (8:5) (8 8 8) 60 Hz
5: 1280 x 800 x 24 (8:5) (8 8 8) 60 Hz
6: 1440 x 900 x 24 (8:5) (8 8 8) 60 Hz
7: 1650 x 1050 x 24 (11:7) (8 8 8) 60 Hz
8: 2048 x 1280 x 24 (8:5) (8 8 8) 60 Hz
9: 2560 x 1600 x 24 (8:5) (8 8 8) 60 Hz
10: 2880 x 1800 x 24 (8:5) (8 8 8) 60 Hz
11: 3360 x 2100 x 24 (8:5) (8 8 8) 60 Hz
AOC Display
Name: AG493UG7R4 (primary)
Current mode: 3840 x 1080 x 24 (32:9) (8 8 8) 60 Hz
Virtual position: 0, 0
Content scale: 2.000000 x 2.000000
Physical size: 1189 x 336 mm (82.03 dpi at 3840 x 1080)
Monitor work area: 3840 x 1055 starting at 0, 25
Modes:
0: 640 x 480 x 24 (4:3) (8 8 8) 60 Hz
1: 720 x 480 x 24 (3:2) (8 8 8) 60 Hz
2: 720 x 576 x 24 (5:4) (8 8 8) 50 Hz
3: 1280 x 720 x 24 (16:9) (8 8 8) 50 Hz
4: 1280 x 720 x 24 (16:9) (8 8 8) 60 Hz
5: 2048 x 576 x 24 (32:9) (8 8 8) 60 Hz
6: 2304 x 648 x 24 (32:9) (8 8 8) 60 Hz
7: 2560 x 720 x 24 (32:9) (8 8 8) 60 Hz
8: 1920 x 1080 x 24 (16:9) (8 8 8) 25 Hz
9: 1920 x 1080 x 24 (16:9) (8 8 8) 30 Hz
10: 1920 x 1080 x 24 (16:9) (8 8 8) 50 Hz
11: 1920 x 1080 x 24 (16:9) (8 8 8) 60 Hz
12: 1920 x 1080 x 24 (16:9) (8 8 8) 120 Hz
13: 3008 x 846 x 24 (32:9) (8 8 8) 60 Hz
14: 3200 x 900 x 24 (32:9) (8 8 8) 60 Hz
15: 3360 x 944 x 24 (210:59) (8 8 8) 60 Hz
16: 3840 x 1080 x 24 (32:9) (8 8 8) 60 Hz (current mode)
Looking online DisplayLink drivers can be a problem for OpenGL apps - it would be a good idea to check that your DisplayLink Manager is up to date. I note that the MacOS Display Link Manager website lists the latest as an Alpha from Sep 6, and the latest non alpha as being Jul 5th. So as MacOS 12.6 was only recently released there could still be compatibility issues they are working out.
To be honest it never crossed my mind that the driver could be causing the issues. When I have access to the setup tomorrow I’m definitely going to try direct connecting the displays first to see if that fixes the problem. I’m assuming that if that does fix the problem the driver is going to most likely be the source of the problem then?
I was going to upgrade to macOS 13 Beta 5 today but seeing how this might be macOS/driver issue I’ll hold off and stay on 12.6. Also, as you’ve mentioned I just now noticed that my driver software is outdated and needs to be upgraded. So, I’ll go in and update that to the latest and if that doesn’t work I’ll try the alpha.
There’s no reason why the monitors shouldn’t work when directly connected that I can think of, so the DisplayLink USB driver is potentially what’s causing this issue.
I’m currently at the setup with the two Dell monitors that’s been giving me issues. Just downloaded the triangle.c program you first mentioned and am getting the same error. Also, as a side note, I had to add the below line of code since macOS only supports forward-compatible contexts.
glfwWindowHint(GLFW_OPENGL_FORWARD_COMPAT, GL_TRUE);
Currently, I have tried the 1.7.1 and the 1.8 alpha of DisplayLink Manager. Neither of those worked. Just for fun I upgraded to the latest beta of macOS 13.0 and am still having the same issue.
I direct connected the display and everything worked like it should. So I’m pretty sure you are right that the driver is breaking things. Makes me feel a bit better that it wasn’t some super obscure bug that was messing things up.
@dougbinks really appreciate your help with this!
Thanks for reporting and testing this.
It does look like the DisplayLink is the problem here. Out of interest were you able to get any other OpenGL application (which doesn’t use GLFW) running via DisplayLink on your system?
It might be worth filing an issue with DisplayLink. I note that their old driver release states This release does not support OpenGL acceleration but newer ones don’t, so perhaps they think OpenGL should apps should work.
Well, this might not be as simple as a display driver issues now. I just tried the same hello triangle tutorial code with SDL2 and that works just fine.
So, I’m assuming the next step would be to try and debug the program to see where exactly this error is being set off? I’m not too sure on how to do that since it’s an OpenGL error about the framebuffer being invalid, and being brand new to the whole graphics programming realm my attempts might not be very productive.
Do you have any ideas on what the next steps should be? Should I go ahead and open a ticket on Github?
If an OpenGL SDL2 application works but GLFW doesn’t it’s worth opening an issue on Github. I’ve checked and there are no DisplayLink related issues open.
To debug this the first step would be to find out when the error occurs, either by sprinkling printfs along with glGetError() to console / file or stepping through with the debugger.
If you’re getting GL_INVALID_FRAMEBUFFER_OPERATION it would be useful to check the enum status of the call glCheckFramebufferStatus( GL_FRAMEBUFFER ); which should return more information. Normally the default framebuffer is complete, i.e. GL_INVALID_FRAMEBUFFER_OPERATION should not occur. DisplayLink likely needs to create it’s own framebuffer to copy the render to USB, so it’s potentially this which is causing issues alongside GLFW - i.e. the bug may be one in DisplayLink which GLFW hits, but SDL doesn’t.
If you are able to run monitors.c on the DisplayLink connected monitor that would be potentially useful too.