Using apitrace with Xvfb

Sat May 16 00:42:02 PDT 2015

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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/apitrace/attachments/20150516/3a496b8d/attachment-0001.html>