Using apitrace with Xvfb

Sat May 16 03:20:21 PDT 2015

I'm inclined to agree here that Freeglut isn't correct to ignore the
extension string. If I recall, either WGL or GLX have undefined behavior
for unsupported function lookup.

- Nigel
On May 16, 2015 5:42 PM, "José Fonseca" <jose.r.fonseca at gmail.com> wrote:

> Yep, I also reproed the issue here and reached similar conclusion.
>
> I too I'm not sure where the bug is. Per
> http://lists.freedesktop.org/archives/waffle/2013-June/000164.html it's
> not safe to look exclusively at the client string neither.
> GLX_ARB_create_context seem to require server support for certain cases
> (though maybe that's not the case for SW renderering.'
>
> FreeGLUT seems the oddball here.  For example, GLFW
> uses glXQueryExtensionsString.
>
> In short, even if we manage to hack glretrace to cope with this Xvfb
> weirdness, there are loads of OpenGL apps/toolkits which will choke on it.
> So I wonder if there's much point to do it.  It seems the ideal would be to
> fix xvfb itself...
>
> Jose
>
>
> On Sat, May 16, 2015 at 4:07 PM, Nick McVeity <nmcveity at gmail.com> wrote:
>
>> Good idea. Here is the trace:
>>
>>     0 glXQueryVersion(dpy = 0x1feb4f0, maj = &1, min = &4) = True
>>     1 glXQueryExtension(dpy = 0x1feb4f0, errorb = &153, event = &93) =
>> True
>>     2 glXQueryExtensionsString(dpy = 0x1feb4f0, screen = 0) =
>> "GLX_ARB_get_proc_address GLX_ARB_multisample GLX_EXT_import_context
>> GLX_EXT_visual_info GLX_EXT_visual_rating GLX_MESA_copy_sub_buffer
>> GLX_MESA_multithread_makecurrent GLX_MESA_query_renderer
>> GLX_OML_swap_method GLX_SGI_make_current_read GLX_SGIS_multisample
>> GLX_SGIX_fbconfig GLX_SGIX_pbuffer GLX_EXT_texture_from_pixmap "
>>     3 glXChooseFBConfig(dpy = 0x1feb4f0, screen = 0, attribList =
>> {GLX_DRAWABLE_TYPE, GLX_WINDOW_BIT, GLX_RENDER_TYPE, GLX_RGBA_BIT,
>> GLX_RED_SIZE, 1, GLX_GREEN_SIZE, 1, GLX_BLUE_SIZE, 1, GLX_ALPHA_SIZE, 1,
>> GLX_DOUBLEBUFFER, True, GLX_DEPTH_SIZE, 1, GLX_STENCIL_SIZE, 1, 0}, nitems
>> = &8) = {0x2028bc0, 0x2028da0, 0x202e070, 0x202e250, 0x2028cb0, 0x2028e90,
>> 0x202e160, 0x202e340}
>>     4 glXGetVisualFromFBConfig(dpy = 0x1feb4f0, config = 0x2028bc0) =
>> &{visual = 0x1ff6700, visualid = 33, screen = 0, depth = 24, c_class = 4,
>> red_mask = 16711680, green_mask = 65280, blue_mask = 255, colormap_size =
>> 256, bits_per_rgb = 8}
>>
>> No call actually fails but the context fails to create because it can't
>> find the GLX_ARB_create_context extension (which is missing from the
>> extension string list). If glretrace gets a GLX version >= 1.4 and can't
>> find this extension and you request a core profile, the createContext
>> function returns NULL. This code is all in glws_glx.cpp in the
>> createContext function.
>>
>> Further inspection using "DISPLAY=:99 glxinfo" does indicate that the GLX
>> server does not support GLX_ARB_create_context extension:
>>
>> name of display: :99
>> display: :99  screen: 0
>> direct rendering: Yes
>> server glx vendor string: SGI
>> server glx version string: 1.4
>> server glx extensions:
>>     GLX_ARB_multisample, GLX_EXT_import_context,
>> GLX_EXT_texture_from_pixmap,
>>     GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_copy_sub_buffer,
>>     GLX_OML_swap_method, GLX_SGIS_multisample, GLX_SGIX_fbconfig,
>>     GLX_SGIX_pbuffer, GLX_SGI_make_current_read
>> client glx vendor string: Mesa Project and SGI
>> client glx version string: 1.4
>> client glx extensions:
>>     GLX_ARB_create_context, GLX_ARB_create_context_profile,
>>     GLX_ARB_create_context_robustness, GLX_ARB_fbconfig_float,
>>     GLX_ARB_framebuffer_sRGB, GLX_ARB_get_proc_address,
>> GLX_ARB_multisample,
>>     GLX_EXT_buffer_age, GLX_EXT_create_context_es2_profile,
>>     GLX_EXT_fbconfig_packed_float, GLX_EXT_framebuffer_sRGB,
>>     GLX_EXT_import_context, GLX_EXT_texture_from_pixmap,
>> GLX_EXT_visual_info,
>>     GLX_EXT_visual_rating, GLX_INTEL_swap_event,
>> GLX_MESA_copy_sub_buffer,
>>     GLX_MESA_multithread_makecurrent, GLX_MESA_query_renderer,
>>     GLX_MESA_swap_control, GLX_OML_swap_method, GLX_OML_sync_control,
>>     GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer,
>>     GLX_SGIX_visual_select_group, GLX_SGI_make_current_read,
>>     GLX_SGI_swap_control, GLX_SGI_video_sync
>> GLX version: 1.4
>> GLX extensions:
>>     GLX_ARB_get_proc_address, GLX_ARB_multisample,
>> GLX_EXT_import_context,
>>     GLX_EXT_texture_from_pixmap, GLX_EXT_visual_info,
>> GLX_EXT_visual_rating,
>>     GLX_MESA_copy_sub_buffer, GLX_MESA_multithread_makecurrent,
>>     GLX_MESA_query_renderer, GLX_OML_swap_method, GLX_SGIS_multisample,
>>     GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, GLX_SGI_make_current_read
>>
>> The client supports the extension but not he server, thus it is not in
>> the GLX extensions list. So how does freeglut work in the first place?
>> Looking at the trace:
>>
>> 0 glXQueryExtension(dpy = 0xa444f0, errorb = NULL, event = NULL) = True
>> 1 glXChooseFBConfig(dpy = 0xa444f0, screen = 0, attribList =
>> {GLX_RED_SIZE, 1, GLX_GREEN_SIZE, 1, GLX_BLUE_SIZE, 1, GLX_DOUBLEBUFFER,
>> True, GLX_DEPTH_SIZE, 1, 0}, nitems = &64) = {0xa7e020, 0xa7e200, 0xa83480,
>> 0xa83660, 0xa7d4e0, 0xa7d6c0, 0xa82940, 0xa82b20, 0xa7da80, 0xa7dc60,
>> 0xa82ee0, 0xa830c0, 0xa7ce10, 0xa7d120, 0xa823a0, 0xa82580, 0xa7c2d0,
>> 0xa7c4b0, 0xa81860, 0xa81a40, 0xa7b790, 0xa7b970, 0xa80d20, 0xa80f00,
>> 0xa7bd30, 0xa7bf10, 0xa812c0, 0xa814a0, 0xa7b1f0, 0xa7b3d0, 0xa80780,
>> 0xa80960, 0xa7e110, 0xa7e2f0, 0xa83570, 0xa83750, 0xa7d5d0, 0xa7d7b0,
>> 0xa82a30, 0xa82c10, 0xa7db70, 0xa7dd50, 0xa82fd0, 0xa831b0, 0xa7cf00,
>> 0xa7d210, 0xa82490, 0xa82670, 0xa7c3c0, 0xa7c5a0, 0xa81950, 0xa81b30,
>> 0xa7b880, 0xa7ba60, 0xa80e10, 0xa80ff0, 0xa7be20, 0xa7c000, 0xa813b0,
>> 0xa81590, 0xa7b2e0, 0xa7b4c0, 0xa80870, 0xa80a50}
>> 2 glXGetVisualFromFBConfig(dpy = 0xa444f0, config = 0xa7e020) = &{visual
>> = 0xa4f630, visualid = 297, screen = 0, depth = 24, c_class = 4, red_mask =
>> 16711680, green_mask = 65280, blue_mask = 255, colormap_size = 256,
>> bits_per_rgb = 8}
>> 3 glXGetProcAddressARB(procName = "glXCreateContextAttribsARB") =
>> 0x7f49a8ac15f2
>> 4 glXCreateContextAttribsARB(dpy = 0xa444f0, config = 0xa7e020,
>> share_context = NULL, direct = True, attrib_list =
>> {GLX_CONTEXT_MAJOR_VERSION_ARB, 3, GLX_CONTEXT_MINOR_VERSION_ARB, 3,
>> GLX_CONTEXT_FLAGS_ARB, GLX_CONTEXT_DEBUG_BIT_ARB |
>> GLX_CONTEXT_FORWARD_COMPATIBLE_BIT_ARB, 0}) = 0xa55da0
>> 5 glXIsDirect(dpy = 0xa444f0, ctx = 0xa55da0) = True
>>
>> It seems it doesn't bother checking the extension string, preferring to
>> just call glXGetProcAddressARB("glXCreateContextAttribsARB") and using the
>> pointer returned. I don't know how valid this is. When I made a similar
>> change to apitrace, glreplay was able to replay the trace that was failing
>> before. If the context is direct, perhaps it doesn't matter than the glx
>> server doesn't support the GLX_ARB_create_context[_profile] extensions?
>>
>>  -- Nick
>>
>>
>> On Fri, May 15, 2015 at 5:38 PM, Alexander Monakov <amonakov at ispras.ru>
>> wrote:
>>
>>> To investigate this further, trace the replayer, i.e.:
>>>
>>>   DISPLAY=:99 apitrace trace -o rtrace apitrace replay trace
>>>
>>> This should show what GLX call is failing in the replayer.
>>>
>>> Alexander
>>>
>>
>>
>> _______________________________________________
>> apitrace mailing list
>> apitrace at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/apitrace
>>
>>
>
> _______________________________________________
> apitrace mailing list
> apitrace at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/apitrace
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/apitrace/attachments/20150516/ecabdf07/attachment.html>