XDS2010 Program

This is the rough program for XDS2010.

Recordings of the presentations can be found at Videos or at youtube. Search for XDS2010

• This session will be just be a discussion for those involved with the driver. There won't be a presentation and it will likely be of limited use for others.

Ideas

• X server 1.10 planning session
  • merge drivers back? * old PCI support (non-libpciaccess) on driver side (or why keep a 1:n for driver:server) * and the close-source ones?
  • and what about the big proto module?
• Non-Linux support BoF
  • DRM/KMS on *BSD
• Review of latest DRI2 protocol additions (?JesseBarnes)
  • DRI2SwapBuffers
  • DRI2 events (swap, invalidate)
  • DRI2Wait*
  • discussion of triple/n-buffering
• Development process recap
  • what is working, what isn't?
  • master vs. stable vs. -next
• Multi-touch session
• Gestures session
• Xephyr BoF
  • last one out the room is the maintainer
• XCB BoF
  • What still needs doing to support widespread porting efforts?
• Handling Input events: assume threads or not? (TiagoVignatti)
• BoardOfDirectors chat
  • XDC 2011 (in Brazil?)
• Documentation or: how a newbie got involved
• EGL in mesa * what is EGL * what's in mesa * how does it work * what do dri/gallium drivers need to provide.
• libxkbcommon - who's the maintainer, where's it going?
• Wacom roadmap BoF
• Which functions can app developers rely on ? * used to be that apps using ~GL 1.2 or 1.3 worked, anything higher was iffy * most drivers now either support GLSL / GL 2.x or are getting close * implementation is sufficient to make many apps work but not "perfect" yet * app devs are starting to rely on GL 2.x but need per-platform testing to succeed * can we identify a "new recommended level" that should work across all major HW platforms ? * something like "GL 2.x minus plus ? * What extensions should we force to be enabled in all drivers? * GL_ARB_copy_buffer - GL_ARB_vertex_buffer_object is always enabled, and this is a trivial addition. Done in Mesa master. * GL_ARB_map_buffer_range - This extension requires additional driver hooks that not all drivers implement. This may still be doable in the future. * GL_APPLE_object_purgeable - Same as GL_ARB_copy_buffer, right? Some concern was expressed at XDS that apps might make (false) assumptions based on the availability of this extension. * GL_ARB_vertex_array_object * GL_ARB_draw_elements_base_vertex - We can (mostly?) fake this on hardware that doesn't have real support. Do we care that much? * GL_SGIS_generate_mipmaps Done in Mesa master. * Are there sufficient tests for these in piglit or glean?
• Kill it with fire * What can we remove from X, Mesa, etc? * GL_ARB_imaging - ?EricAnholt has a branch. Nobody uses convolution or histograms. Removed in Mesa master. * GL_EXT_cull_vertex - This is only enabled in swrast and the Intel drivers. Do any applications use this? Removed in Mesa master. * GL_EXT_paletted_texture and GL_EXT_shared_texture_palette - This is only enabled by swrast and tdfx drivers * GL_EXT_clip_volume_hint - No hardware driver supports this. The support in swrast appears to be fake. JakobBornecrantz expressed some concern that this can enable some extra fast paths in llvmpipe and softpipe. The question remains whether or not applications actually use this extension. * GL_APPLE_client_storage - This is only enabled in swrast and the Intel drivers. Do any applications use this? The support appears to be fake. * GL_MESA_packed_depth_stencil - No hardware driver supports this. It's not enabled in swrast either. This is a superset of GL_EXT_packed_depth_stencil that also has a 15.1 depth/stencil format. Removed in Mesa master. * Corbin's list