On Mon, Feb 24, 2014 at 9:43 PM, Roland Scheidegger <srol...@vmware.com> wrote: > Am 24.02.2014 21:23, schrieb Marek Olšák: >> Roland, >> >> The version CAPs that Emil wants to add have very little to do with >> which features a driver supports. The versions cannot be derived >> from other CAPs, instead, it should match what you get after you >> create an OpenGL context. For example, if your driver can do GL 4.0, >> the driver cannot report that it can do 4.0. Instead, it should say >> it can do 3.3, because that's what core Mesa can do. The only purpose >> of these new version CAPs is to match what core Mesa does without >> asking core Mesa. It's ugly, but it's the least invasive solution. >> >> Of course, it can actually be done cleanly, e.g. making both >> main/version.c and st_extensions.c independent of gl_context and >> only using a DRI screen or something like that, but that needs a lot >> more work. > Yes, that's what I'm saying. All the cap asking stuff in st_extensions.c > could be done without a context, as well as what mesa's compute_version > then does with it. > And yes you'd still need to clamp it to whatever the state tracker > actually supports (which is ugly since you can build mesa with non-gl > state trackers so querying the drivers that way ultimately makes not > much sense).
I don't think the clamping would be needed. st_extensions.c contains all that is needed for compute_version and compute_version can return the supported version based on an "enum gl_api" parameter and that's it. We could also remove the gl_extensions and gl_constants structures from gl_context and put them in the DRI screen. Later when the first context is created, we don't need to determine the version, extensions and constants again. Marek _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
