xorg/ Events/ XDC2009/ Notes

XDC2009 Notes

Live from sunny Portland, it's the X Developer's Conference 2009!

  1. Monday, September 28
    1. SoC review
    2. Board talk
    3. krh: rootless X with Composite
    4. gregkh: Death of HAL
    5. bernie: multiseat with USB video demo
    6. jakob: Debugging gallium drivers
    7. daniels: Release stuff
    8. mjg59: Power management
  2. Tuesday, September 29
    1. idr: OpenGL 3 and Mesa
    2. krh: Stitching together FBOs + KMS + EGL
    3. idr: GL shaders for shader model 3/4
    4. aaronp: Synchronisation and presentation
    5. bernie: multiseat technical stuff
    6. jbarnes: intel driver update
    7. agd5f: AMD driver update
    8. krh: wayland
  3. Wednesday, September 30
    1. tiago: PCI and VGA arbitration updates
    2. eamon: XACE updates
    3. corbin: Why Xorg Sucks
    4. tiago and oliver: Embedded Xorg
    5. ajax: Future of the DDX

Monday, September 28

Bart Massey: Welcome, Introductions

SoC review

  • Been doing this for about three years
  • Bart looking to get out of the organizer role next year; volunteers?
  • Hard to find good mentors; volunteers?
  • Corbin (only SoC student in attendance) on his project: shatter
    • don't take summer classes if you're doing a project!
    • also, be fearless about applying if you're a student, you'll do better than you think
  • ajax on mentoring: good, rewarding, helps if you have a routine and regular updates
  • Have we asked the students what the pain points were? Uh, no. Hmm, should do that.

Board talk

  • new hardware this year? yeah, probably.
  • Still finalizing 501(c)3 reorg. Paperwork! So much paperwork.
  • Elections coming up again, nominate yourself or your friends/enemies

krh: rootless X with Composite

  • Expose CompositeRedirectSubWindows, hook CreateWindow, redirect root window in CW hook
  • Hook RealizeWindow and make GEM handles for the window pixmap, tear it down in UnrealizeWindow
  • Update it in SetWindowPixmap (resize, reparent, etc)
  • Hook MoveWindow to reflect X position as Wayland moves

gregkh: Death of HAL

  • HAL is dead upstream!
  • Linux will probably port to libudev
  • Others will need to port to... other.

bernie: multiseat with USB video demo

jakob: Debugging gallium drivers

daniels: Release stuff

  • 1.7 mostly done
  • 7.5 basically just needs badging and releasing. Huzzah!
  • Development proposal: http://lists.x.org/archives/xorg-devel/2009-September/002231.html
  • Do we merge the drivers back in? Hm.
  • The protocol header re-org made bisecting irritating. Are we done?
  • "Our release process is, we name a month, and then two months after that..."
  • General consensus on having someone to own master and manage merges
  • Given regular server releases, driver merge is generally acceptable
  • 1.8 targets: XKB2, XI2.1 grab fixes, some DRI2 proto enhancements, RANDR proto enhancements, GLX 1.4, VDPAU token in DRI2
  • Corbin: "shatter by 1.10"
  • Testing. We should really do some of that.
  • Testing: should get hardware for it (scan grabber, etc)

mjg59: Power management

  • What draws power? GPU, VRAM, outputs, and displays
  • GPU: clock gating, reclocking
  • VRAM: framebuffer compression, reclocking
  • Outputs: Load detection, PLLs
  • Displays: LVDS reclocking, DPMS
  • Until recently, all we had support for was DPMS, enabling clock gating, static power policy
  • Moving to more on-demand response
  • Savings: LVDS reclock ~0.5W, gpu/memory reclock 10-15W
  • Could reclock the HT link on AMD IGP
  • Could use sideport RAM on IGP too
  • Could change PCIE lane count, but that requires ~3 frames to do... probably machine-dependent
  • Should do adaptive screensaver timeouts
  • Could D3 the entire card? Really touchy.
  • How far can we go with input policy? Screensaver for example, you could suspend the keyboard.
    • daniels: when we update grabs, we'll add flags

Tuesday, September 29

idr: OpenGL 3 and Mesa

  • Several patented technologies in OpenGL that we want in Mesa
    • Floating point textures and render targets (in core GL3), certain compressed texture formats
  • external libraries solve some of it (for S3TC), could kinda do that with fp textures... but not targets
  • could act like freetype (configure switch for patented technologies)
  • could try to get OIN to help on the patent license front
  • plan: yes, do both of those

krh: Stitching together FBOs + KMS + EGL

  • Goal is to be able to do EGL straight on top of KMS
  • KMS: drmAddModeFB, drmModeSetCrtc, drmModePageFlip
  • EGL: eglCreateWindowSurface, eglCreatePixmapSurface, eglSwapBuffers
  • FBO: glGenRenderbuffers, glRenderbufferStorage
  • Possibility: use EGL images to do glue together KMS objects to GL

idr: GL shaders for shader model 3/4

  • Advanced assembly shader extensions for Mesa
  • middleware wants to generate assembly shaders: wine/cedega, Cg
  • ARB_vertex_program is really basic, no branches/predication/texture fetching
    • Enough for most GLSL shaders; supported in hw on 965/r200/nv20
  • NV_vertex_program2 adds predication, branches, procedure calls
    • supported in hw on nv30 and (kinda) 965
  • NV_vertex_program3 adds texture lookups, address push/pop, relative indexing into attr/result arrays, second condition code register; basically shader model 3
    • supported in hw on nv40 and ~965
  • NV_vertext_program4 adds integer insns, structured branching, unified insn set with fragment processor; shader model 4
    • G80, ~965
  • ARB_fragment_program: base support, no branches, no predication
    • r300, i915, nv30, r500
  • NV_fragment_program: predication, partial derivatives, packing/unpacking insns
    • nv30, ~965, r500
  • NV_fragment_program2: structured branching (no unstructured), fragment facing attribute, misc insns
    • nv40, ~965, r500
  • NV_fragment_program4: integer insns, unified instruction set with vertex processor
    • G80, ~965, r600
  • lots of nvidia extensions that match their hardware but not really anybody else's
    • instructions only on nv hardware, no structured branched on vertex model, different predication model...
  • what we want is supportable across a range of hardware: 965, R500; 915 and R300 stuck at existing ARB level
  • want structured branching, predication, vertex textures, partial derivatives
  • Is this worth doing? Less work than making GLSL rock, but we kinda need to do that anyway
  • Nice for middleware, but does it help app developers?
  • Modest support; we'll bang something out in the working session later.

aaronp: Synchronisation and presentation

  • No defined ordering between X and direct rendering

  • GLX APIs are only good for your own X and GL stream, not useful between apps

  • X sync objects, like GL sync objects. Contains nothing but binary state: triggered or not.
  • Rendering streams could be stalled until sync object reaches triggered.
  • Export these to other APIs so you can sync between them
  • Also need control over where and when presentation happens, and feedback on when buffers are in use by presentation
  • Explicit multibuffering: allocate multiple backing pixmaps, explicitly set backs to be the new front; kind of like existing multibuffer extension?
  • Sync counters not that close of a match, since hardware really only has boolean triggers
  • Presentation requests forwarded to the current CM, or else automatically composited

bernie: multiseat technical stuff

jbarnes: intel driver update

  • DDX
    • EDID fixes, hang fixes, XvMC for new chipsets, KMS output transforms, KMS-only build available, cursor flicker fix, regen fixes
    • Future: Removal of UMS, glamour, maybe cairo-drm?
  • 3D: Big pile of GL features, texture tiling, hang fixes
  • Kernel 2.6.31: dynamic clock control, self-refresh support, error detection, FIFO watermark support, misc output fixes, vbios parsing fixes, DisplayPort support, MCHBAR allocation, new chipsets
  • Kernel 2.6.32: GPU hang recovery, FBC support, tracepoints, hang fixes, misc output improvements, madvise support, memory shrinker, display cleanups
  • Kernel future: per-process GTT, context support, page flipping, DRM events, GPU scheduling, zone rendering

agd5f: AMD driver update

  • 3D driver for R600 and R700! Pretty much works, which is awesome.
  • Working on IRQ support for R600 and R700
  • More power management work in KMS
  • R800 support coming up
  • HDMI audio
  • XvMC in gallium for R300-R500 now, 600 and 700 soon
  • Lot of suspend and resume fixes
  • sideport scanout support
  • debugfs support in 2.6.31
  • usual future stuff like pageflipping

krh: wayland

  • New, minimal, composited display server
  • Server and compositor is one process
  • Not a remote display protocol
  • All clients are direct rendering; efficient buffer sharing is assumed (GEM, TTM, etc)
  • Either allocate a buffer, render, and pass to wayland; or incrementally update an existing buffer
  • Needs input, which is basically copied MPX and XI2
  • Multipointer, all events have a device ID; hotplug, axis and button labels
  • Passes on evdev codes
  • XKB as a client side library
  • Transforms screen input coordinates to surface coordinates
  • Not like earlier attempts - Fresco, Y, SDL - by reusing X components
  • X runs on wayland, either rooted or rootless, so your apps still work.

Wednesday, September 30

tiago: PCI and VGA arbitration updates

  • X used to do all PCI management and direct hardware access
  • RAC was built to handle multiple PCI devices
  • libpciaccess pulled most of this out from the server, but broke multiple device support
  • RAC recently removed, needed to be in kernel for multiple X server support anyway
  • VGA arbiter landed in linux kernel, allows multiple X servers to work again
  • Most recent hardware actually doesn't need the arbiter, but needs driver support
  • X is very cautious about wrapping everything for arbitration, could probably be optimized
  • int10 outside X, something like udev to trigger it for non-KMS devices
  • Todo: remove old probe scheme, last bits of RAC
  • Future: hotplug graphics, hybrid graphics

eamon: XACE updates

  • compiz plugin with security context in menu, permanent overlay for context display
  • firefox running in a different security context; different frame colors for different contexts
  • Defeats xspy! Defeats GetImage! It's like the future.
  • Has MPX support, so you can give different contexts to different devices, bind keyboards to password dialogs, etc.
  • DRI2 needs better lockdown so you can't just attach to arbitrary buffers

corbin: Why Xorg Sucks

  • Classes of users: Naïve, Informed, Experienced
  • Naïve complaints: old, bloated, my youtube doesn't work, flash, java, fglrx/nvidia
  • Rebuttal: Mature, full features, backward-compatible, out-of-tree is not our problem
  • Informed complaints: m12n was a bad idea, X protocol is old, 3D doesn't work, HD video doesn't work, hotplug displays don't...
  • Mostly just a matter of wanting the moon on a stick
  • Linux haters: no FBOs or pbuffers, no GLSL, no DRI2, no GL2 or GL3, no GLX 1.4
  • Actual state of 3D: decent, getting better
  • Not that far from actually satisfying the complaints!

tiago and oliver: Embedded Xorg

  • Mostly moved from kdrive to Xorg
  • Supports newer extensions, and is actively developed, but has much larger RSS
  • Xorg is already shrinking, which is good
  • Basic configuration will disable dga, dri, glx, ipv6, xinerama, xaa...
  • Could add more configuration options to disable more things; worth the complexity? Probably.
  • x86emu, vgahw, ddc, etc... could reasonably be optional
  • lots of the core is still kind of large, but is mostly .text, so meh
  • RANDR happens a lot, should be fast; external screensaver control would be nice

ajax: Future of the DDX

  • Is our goal X, or the stuff to enable things like X; Arguably should be the latter
  • Moving enablers out of X (already: kms, pixman; future targets: xkb, x86emu/libx86)
  • What about X config?
  • Move EDID and DisplayID parsers to a lib; Make drivers/apps use it.
  • Move i2c into a separate lib
  • fbdevhw could be removed
  • Remove non-randr 1.2 stuff?
  • randr extension for full display state setup (full set of outputs and crtcs in one shot)
  • DPMS and screensaver extensions; should be only one
  • Remove DPMS, add new functionality to randr, tell internal screensaver something else is managing the screensaver
  • Extra cruft: old ramdacs, gatos tuners/decoders, bank switching, PC98, ScrnInfoRec
  • MAXSCREENS/MAXFORMATS/MAXDEVICES
  • One DDX with loadable backends
  • Xinerama - unify proto with randr; Make most of the screen stuff global; need shatter
  • Adding YUV/JPEG/opaque data source pictures to render
  • Moving Xv to render so we can do Xv in the DIX?