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.
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?