GNOME Bugzilla – Bug 744407
Can't support core 3.2 gl context on llvmpipe
Last modified: 2018-04-15 00:01:03 UTC
For lame patent reasons the llvmdriver in mesa can't currently promise core 3.2 contexts, as they require the support of floating point buffers, which are patented. This means that right now we would fail in opengl use in such a case. This is not cathastrophic atm, as nothing requires GL as such, but it may be a problem in the future as things start using GtkGLArea. Ajax proposed to add a mesa context flag to mean "core 3.2 but without floating point", then we could use this as the default context type and then add a separate enum value for "real core 3.2".
Basically this would be another attribute you pass to CreateContextAttribs, a la: https://www.opengl.org/registry/specs/KHR/context_flush_control.txt The attribute's value would be something like a bitmask of feature sets, corresponding to various parts of OpenGL that are difficult to implement for whatever reason. For example, a driver might implement GL 4.0 except for tessellation shaders. The GL would use this bitmask when computing the maximum GL version it can provide in CreateContextAttribs.
So, i think the plan is: Make gdk require 3.2 core as now, but also document that it may not support fp buffers even if 3.2 core does not. Also introduce gdk_gl_context_set_require_fp() or suchlike, which you can set before realize if you need fp support. We'd default this to FALSE which means we can pass this in the bitmask to the context creation function.
oh, and i forgot, just drop the current "profile" thing and just go with specifying major/minor numbers.
Created attachment 296703 [details] [review] Remove GdkGLProfile The existence of OpenGL implementations that do not provide the full core profile compatibility because of reasons beyond the technical, like llvmpipe not implementing floating point buffers, makes the existence of GdkGLProfile and documenting the fact that we use core profiles a bit harder. Since we do not have any existing profile except the default, we can remove the GdkGLProfile and its related API from GDK and GTK+, and sweep the whole thing under the carpet, while we wait for an extension that lets us ask for the most compatible profile possible.
Review of attachment 296703 [details] [review]: looks good to me
Comment on attachment 296703 [details] [review] Remove GdkGLProfile Attachment 296703 [details] pushed as d066e75 - Remove GdkGLProfile will keep the bug open for the rest of the issues.
We're moving to gitlab! As part of this move, we are moving bugs to NEEDINFO if they haven't seen activity in more than a year. If this issue is still important to you and still relevant with GTK+ 3.22 or master, please reopen it and we will migrate it to gitlab.
As announced a while ago, we are migrating to gitlab, and bugs that haven't seen activity in the last year or so will be not be migrated, but closed out in bugzilla. If this bug is still relevant to you, you can open a new issue describing the symptoms and how to reproduce it with gtk 3.22.x or master in gitlab: https://gitlab.gnome.org/GNOME/gtk/issues/new