[Mesa-dev] [PATCH 00/12] Computing GL versions without gl_context

Marek Olšák maraeo at gmail.com
Sun Aug 3 11:07:58 PDT 2014


On Sun, Aug 3, 2014 at 7:57 PM, Emil Velikov <emil.l.velikov at gmail.com> wrote:
> On 03/08/14 18:26, Marek Olšák wrote:
>> On Sun, Aug 3, 2014 at 6:44 PM, Emil Velikov <emil.l.velikov at gmail.com> wrote:
>>> On 03/08/14 16:18, Marek Olšák wrote:
>>>> Hi everyone,
>>>>
>>>> GLX_MESA_query_renderer can return supported GL versions before any context is created, but Gallium drivers and st/dri have not way to know which versions are supported, because the version computations take place in st/mesa at context creation.
>>>>
>>>> This patch series adjusts mesa/main, st/mesa, and st/dri to make computing all GL versions without a context possible. With this series, all supported GL versions (core, compatibility, ES1, ES2) are computed at DRIscreen (and pipe_screen) creation, which brings us closer to adding support for GLX_MESA_query_renderer.
>>>>
>>>> Please review.
>>>>
>>> Great work Marek,
>>>
>>> A ages ago when I initially looked at this I was thinking of extending (some
>>> of) the extension/limits to be a API_OPENGL_LAST+1 sized array(s). This way we
>>> don't need to do the {mesa,st}_init_{constants,extensions} dance four times.
>>> The idea was to avoid making our glMakeCurrent even slower than it actually
>>> is. Perhaps you shuffled things around and this is no longer relevant ?
>>
>> I don't think so. I don't remember how MakeCurrent works, but I don't
>> think this series has anything to do with it.
>>
> Indeed. Seems like got the wrong function here.
>
>>>
>>> While there I was planning on deflating the size of gl_context (~150K) my
>>> moving gl_constants (~1K) and gl_extensions (~0.2K) to DRIScreen, and storing
>>> just a pointers in gl_context. This way we can avoid having yet another copy
>>> of the constants (another ~0.2K) into glsl :) Yet I feel that all that is
>>> slightly orthogonal to the original topic.
>>
>> Actually, this series does make moving gl_extensions and gl_constants
>> into DRIscreen a lot easier, assuming you would add separate copies of
>> those structures for Core, Compat, ES1, and ES2. Then, we wouldn't
>> have to do any feature checking at context creation.
>>
> Indeed it does, yet my idea was bit different - keep the data in DRIscreen and
> avoid copying it around. Just expand the specific limits/extensions (iirc only
> 10-20 of them need it) to store a value for each gl_api.
>
> Ex. from st_init_extensions()
>
> // Note the missing if (api == API_OPENGL_CORE)
> consts->MaxViewports[API_OPENGL_CORE] =
>       screen->get_param(screen, PIPE_CAP_MAX_VIEWPORTS);
> if (consts->MaxViewports[API_OPENGL_CORE] >= 16) {
>    consts->ViewportBounds[API_OPENGL_CORE].Min = -16384.0;
>    consts->ViewportBounds[API_OPENGL_CORE.Max = 16384.0;
>    extensions->ARB_viewport_array[API_OPENGL_CORE = GL_TRUE;
>    extensions->ARB_fragment_layer_viewport[API_OPENGL_CORE] = GL_TRUE;
>    if (extensions->AMD_vertex_shader_layer)
>       extensions->AMD_vertex_shader_viewport_index[API_OPENGL_CORE] = GL_TRUE;
>    }
>
> As such one will need to call st_init_extensions() only once :) Yet I fear it
> may look a bit messy.

Ah this. Well, you can ignored that. gl_constants and gl_extensions
should be API-agnostic, i.e. drivers should just expose the features
they support and mesa/main should figure out what should be exposed to
the user based on that. Therefore, checking the API in
st_init_extensions is unnecessary and conceptually wrong.

So you can ignore what I said before and indeed there only needs to be
one common copy of both structures that is shared by all GL APIs.

Marek


More information about the mesa-dev mailing list