Notes

XDC2009 Notes

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

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

• trace module for API calls
• rbug: remote debugging, object inspection, rendering single-stepping, etc.
• http://git.freedesktop.org/mesa/rbug-gui.git

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

• udev script runs on plug and fires up a seat by launching gdm on the device
• Walkthrough of scripts at http://libdlo.freedesktop.org/wiki/MultiSeatTerminal

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
  • Future: various GLX and DRI2 sync extensions, GL3 features; XXX MissingFunctionality on DRI wiki
• 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?