| Summary: | Max core profile version: 0.0 in the "Drivers/DRI/r300" component of the "Mesa" | ||
|---|---|---|---|
| Product: | Mesa | Reporter: | Alina <pythonalina> |
| Component: | Drivers/Gallium/r300 | Assignee: | Default DRI bug account <dri-devel> |
| Status: | RESOLVED NOTABUG | QA Contact: | Default DRI bug account <dri-devel> |
| Severity: | critical | ||
| Priority: | medium | ||
| Version: | unspecified | ||
| Hardware: | Other | ||
| OS: | Linux (All) | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
Is there a question somewhere in there? (There is currently no r300 "dri" driver, only a gallium one, btw.) @Ilia Mirkin I think she refers to the fact that "core profile" reports 0.0 (In reply to Hi-Angel from comment #2) > @Ilia Mirkin I think she refers to the fact that "core profile" reports 0.0 It is printing the results of GLX_MESA_query_renderer return values. This is how the lack of core profile support is indicated. > This is how the lack of core profile support is indicated
I don't understand, is it possible to have compatibility profile, but not the core one? And if it is, what would apps requesting a core profile get?
(In reply to Hi-Angel from comment #4) > > This is how the lack of core profile support is indicated > > I don't understand, is it possible to have compatibility profile, but not > the core one? And if it is, what would apps requesting a core profile get? Technically it's not the "compatibility" profile until GL 3.2 rolls around, but in essence yes. An implementation would probably not expose GLX_ARB_create_context_profile, but if it did, such requests would fail. > Technically it's not the "compatibility" profile until GL 3.2 rolls around, but in essence yes. An implementation would probably not expose GLX_ARB_create_context_profile, but if it did, such requests would fail.
I shall say, my OpenGL-fu not very good, but this looks like a mess. Using GLX_ARB_create_context_profile is generally the expected way of using OpenGL, right? Then, the only way to use r300g is to ask compatibility or to query every possible extension separately. The first one we don't want apps to do, and the second one hardly would be used by anyone because, at least, core profile is expected to be present.
So, after all, it's bug, right?
(In reply to Hi-Angel from comment #6) > So, after all, it's bug, right? Nope. It's all working correctly and both as intended by the driver authors, as well as in the way that applications expect it. For the history sake, I've got the answer about design on IRC, and this is indeed correct. The separation to Core profile and to (optional) compatibility profile only appeared at OpenGL 3.2, and prior that there was a different way to get max. supported version. Hence, if the app supports prev. OpenGL, it should fallback on that codepath. |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.
server glx version string: 1.4 client glx version string: 1.4 GLX version: 1.4 Max core profile version: 0.0 Max compat profile version: 2.1 Max GLES1 profile version: 1.1 Max GLES[23] profile version: 2.0 OpenGL version string: 2.1 Mesa 17.1.8 OpenGL shading language version string: 1.20 OpenGL ES profile version string: OpenGL ES 2.0 Mesa 17.1.8 OpenGL ES profile shading language version string: OpenGL ES GLSL ES 1.0.16