We do have a list of (70) bugs blocking the release (10101):
https://bugs.freedesktop.org/show_bug.cgi?id=10101
But nobody other than Adam has ever looked at that.
It seems we're all heads down now. There were lots of good talks at XDS in the fall about new stuff that was coming, (Gallium, etc.). But it's
Bug 13795: With Mozilla and cairo now using Render, we're using lots of parts of the server/drivers that have never really been used before. As expected, they are broken.
Some of the breakage is avoidable with XAANoOffscreenPixmaps.
Can we drop XAA altogether? Not for this release. EXA isn't quite ready yet. And Glucose isn't happening at all.
Ajax: I'm feeling kind of alone here. Nobody else is looking at this stuff? Daniels: I just closed a blocker. One fixed.
Ajax: I don't feel like I'm scaling that well. There are huge swaths of the code that nobody cares about. Things change and break, but nobody takes responsibility for things.
Even the drivers that are "well maintained" have problems. We see lots of churn in the drivers, but not releases. Releases are cheap guys! I don't have a solution for that except shaming people---maybe this is how I get a start.
Every 6 months or so we have a session where we say "what do we want in our next release?" and we write them on the whiteboard. Then, several months later someone, (lately, Ajax), looks at the list and sees which ones are actually coming together, (about 50%), and decides those are the ones that actually go in.
Example of the picaccess change that was on the "desired" list for several releases, but never went in. Finaly, we sat down and forced it in, but found that only the "top 3" drivers had been ported to it, and everything else broke. Fortunately, someone stepped in to save things after the fact. The problem is that we don't have anyone signing up for that janitorial work---or a commitment to "don't break the drivers". But we could have done the whole pciaccess change in-pace with a compatibility layer so that nothing would have ever broken.
Jesse Barnes: We had a big flamewar about putting the drivers back "in tree" in one git module or whatever. That never came to consensus, but wouldn't it help? Right now, nobody cares about the "server" and the distribution maintainers end up taking on all the pain. Wouldn't it be better if driver hackers had a vested interest in getting the "big blob of server and drivers" into a releasable state together.
John: Is the big problem lack of resources for driver development?
Someone: Or just lack of policy?
Ajax: I don't think it's lack of resources. If we had done pciaccess correctly, then it wouldn't have been any work---just a sed script.
Daniel: Bisectability is really nice. People can bisect an independent driver and find Jesse's driver bug. But if we had the big blob, and someone tried to bisect, then it would all just be "Oh my God, my keyboard doesn't work". So if we did put everything together, we'd need lots of separate trees, (input, etc.).
Ajax: Do git submodules help us address the issue?
Eric: Zack's done more work with the submodule thing, but I don't think it gives us what we want. We don't get a master supermodule that points to all the "master" branches of the submodules. Instead, it has to have exact sha1 sums for each point. It would be great for tagging releases, but not so nice for "build master".
[Discussion: What was the whole point of modularization?]
Ajax: It's great to be able to build the server without having to build xedit.
Daniel: It was great for distributions.
Jesse: The only thing that makes sense to merge back together is the server and drivers. It's a social problem, but this technical change would help.
Kevin: That puts structure onto the technical side of things, but not any structure onto the social problem.
Ajax: The problem with merging things together is that it doesn't address the modularization problem. What happens when I want to package up the server, but the Intel driver happens to be broken at the time? If all I can grab is one point in the development of everything, then there's a problem there. How can I back out just the Intel driver changes?
John: It sounds like we want monolithic build and test, but we want modular packaging and distribution.
Ajax: One of the problems is that we're just not testing in the first place. And that's a big part of the problem.
Ajax: We actually do have a test suite (XTS) that we got released under a free license a while ago, but nobody is actually running that. And nobody is adding new tests.
Keith: But we can't add tests to that test suite. We are writing new ad-hoc tests. Do we create a new test suite infrastructure? Do we use something like piglet?
Bart: We don't have to solve all our problems with automated tests. We do need to put together the social organization, (maybe even pay people), to make things happen.
[Someone]: We have a lot of server bugs already without automated tests and they already aren't getting worked on.
Jesse: We're getting a little off-topic here. The original problem was that Ajax isn't getting any help with release management.
Daniel: Release manager is a misnomer anyway. There's no herding of others doing work or anything. It's just signing up to be the person that fixes all the bugs.
Eric: The advantage of automated testing is that you find out the regressions quickly and you only have a couple of commits to look at to find and fix the bug.
[A few minutes more discussion on technical vs. social problems, lots of missing testing from anybody. Lack of a decent infrastructure for writing new tests.]
Our goals include:
What have we been doing?
Memory management is critical. And it's still not done. How do we finish this?
DRM, kernel modesetting, VGA arbitration.
Monitor hotplug. Have the desktop-side configuration support, really just need the event from the hardware.
Driver work:
Video. MC and iDCT and such need to get properly implemented everywhere.
Gallium is a rework of the DRI driver model. The driver ends up being rather large and opaque, and writing new ones is rough because it's so large.
In Gallium, the driver is split up to isolate the core logic from the hardware from the window system from the OS. The core logic assumes that the driver is shaderful.
This allows better reuse (state tracker stays the same, only the hardware driver changes).
This allows better portability to other OSes or windowing systems.
Still under development, but mostly interface-stable.
Have several drivers already (i915, i965, softpipe, cell). External projects for nouveau and R300.
The big pieces are the state tracker, the winsys layer, and the core driver itself.
the core driver encapsulates all the hardware knowledge Other pieces:
"draw", software vertex walk
CSO, constant state objects, responsible for optimisation of state emission
buffer management code
TGSI code, internal representation of shaders
LLVM integration It works! Software rendering path works. i915 works on both X and Windows. Works on PS3.
Fallbacks are hard. Fallbacks are really hard. Ideally you wouldn't have them, but that requires a complex state tracker, since OpenGL is really big and weird. Being worked on.
APM used to exist. It more or less worked! But when it didn't, there was no recovering.
Open Firmware exists, but isn't typically relevant for desktops.
Embedded things have their own stuff.
ACPI basically makes no guarantees about what happens when you come back from resume.
The steps are: call device suspend callbacks, platform Prepare-to-sleep method, platform Go-to-sleep method, (suspend), random BIOS stuff, platform Back-from-sleep method, platform wakeup method, device resume callbacks.
ACPI doesn't require that the platform do anything, but it also doesn't require that the platform do nothing.
Some machines will reenable text mode in BIOS. Sometimes that happens during ACPI methods. Sometimes that only happens if the platform thinks Linux is running. But you'd really rather not go back to text mode at all. Ideally, you'd restore state and go back to graphics directly.
Swapping out all the state is kinda difficult, but doable. The really hard part is getting the device into a consistent state before doing the state restore. Then you need to block X until everything is back to a reasonable state.
(Lots of implementation details)
How do you survive video hotplug? Actually, you're not expected to be able to.
Need to be cleaner about input hotplug, not doing it right right now. Just a bug.
DDX module in hw/xquartz/, old hacked-up version of Mesa
Everything else is plain-jane Xorg, packaged up as X11.app
History
Apple branched XFree86 4.3 and included it in the OS Goals
Pleasant experience for Unix apps on a Unix OS
Support all traditional X11 technologies on a Mac (GLX, drag and drop, copy/paste, rootless)
Cater to wide range of users: sysadmins, developers, research, design
Take advantage of OSX features Keeping up
X11.app and XDarwin evolved in parallel
XDarwin pulled most improvements from X11.app, X11.app pulled XFree86 updates Decay
X11.app brought to release quality and parked in maintenance mode
Resync with XDarwin depended on volunteers
XFree86 licensing change forced a move Leopard X.org resync
BSD team in Apple Core OS group took on task of porting X11.app to "new code"
XFree86 code base severely bit-rotted
Xplugin shim didn't keep up with the rest of the OS
Non-existent developer community
Limited Apple resources
Functional, but some regressions, limited testing
Installed by default on Leopard Further open source push
xquartz.macosforge.org - trac instance, etc
Code maintained in freedesktop.org git branch, binaries on macosforge
x11-users mailing list, xquartz-devel
Picked up an intern! Hi Jeremy! X11.app today
Discarded old Darwin code, renamed DDX to Xquartz
apple branches in git
Built like a normal X server, configure && make && make install
Limping along on old Mesa code though Current challenges
Quirky input code
Crashy rootless code
Stale DRI code Coming projects
New DRI driver using OpenGL.framework
Fix rootless and/or replace with Composite
Better input and RANDR support
Smarter clipboard proxying
Move to open source window manager
Sync with git master
Debriefing: A one-time, semi-structured conversation with an individual who has just experienced a stressful or traumatic event.
No kernel side
possible new ioctl for mapping a set of buffer objects (rather than just one) Simpler DDX driver requirements
fbconfig come from the DRI driver instead of from the DDX
back buffers allocated on demand by the DRI driver
sarea is a buffer object rather than a magic map
new self-describing block format for sarea records
sarea still necessary for describing cliprect changes (log showing dynamic buffer allocation)
Event ring buffer
protocol for catching up if the client falls too far behind the server Initialization and operation examples
Server setup: DDX driver opens DRM device, calls dri2 to initialize the sarea, with optional size for driver-specific blocks
Client setup: If DRI2 extension is available, call DRI2Connect for busid, driver name, sarea buffer object handle; call DRI driver's createNewScreen, which doesn't set up any pre-sized render buffers.
Tell DRI2 module that we're interested in a given X drawable. Server responds by logging it to the new sarea.
When the drawable is bound to a context, the DRI driver parses the sarea event log and sets up the necesary render buffers.
GLX_EXT_texture_from_pixmap in direct contexts for free Lockless options
As the server moves windows around, the cliprects change and you have to blit. You have to make this appear atomic to clients, otherwise the pixels and cliprects will be inconsistent
Introduce two new submit methods:
Technical discussion on how to implement sync to vblank.
(Super hot demo)
What do app authors want?
YUV picture formats as a new source picture type
JPEG/PNG picture formats for compressed image transport
YUV needs new filter types for hue/contrast/etc
Gradients need to be properly specified, should just copy the cairo spec
Gradients need dithering, and for filters to work in general
Technical discussion of how to do automatic mipmapping
Rendercheck needs a ton of work
Transforms need to be floating point? Or at least need to be specifiable in floating point
(Søren rants for a while about the imprecision of the spec)
Kernel modesetting is in progress, for all the usual reasons: suspend, flicker-free boot, reducing root code in userspace, graphical boot, graphical panic
Really hard to preserve compatibility, so a new driver sounded like a good idea. Problem is the existing code is well-tested and also tedious to rewrite. Rewriting it was a mistake; should have used the existing DDX code to begin with.
Why ATOM? Should work since Windows uses it. Reuses AMD engineering work. Keeps the driver from needing to know hw details. But, sometimes buggy and not always exactly what we want.
What do users want? Working 3D. Accelerated video. Modesetting is uninteresting as long as it comes up.
So, use ATOM to leverage the existing AMD engineering work. Reduce time to support new hardware, get on to the fun features.
AMD GPU design is "like Lego blocks". Different GPUs share same modules (DAC/TMDSC, 3D engine, CP), but can move around between GPUs. Can and does. But ATOM takes care of most of this for us.
Kernel code should reflect this modular design; each piece should talk only to the piece of the chip that it's responsible for.
Lockups are easy to trigger. And, surprisingly hard to recover from. (Technical details.) Need to sanitize the command stream to be sure you don't do weird things, and avoid the WAIT_UNTIL feature. But this makes vsyncing hard.
Lots of cases where the GPU can stall. Fencing is really hard; need to be careful about batching them. Some buffer offset registers stall until they can be done safely, so you want to avoid doing them. Context switches need some optimization for this case.
Fragment programs are essential now, and optimisation is critical so you correctly run everything you claim to be able to run. LLVM will save us all.
Texture indirections are a finite resource. You can reduce them by rescheduling the shader.
r300 and r400 don't support all swizzling combinations. Want to redo shaders to use native swizzling when possible.
Future work: DRI2, radeon gallium driver, get gears to work, fragprog compiler.
Background: working on Dirac, which is a codec from BBC that's designed to be competitive with MPEG4.
Currently: 8 bit per channel, normal color gamut, 480i/30 or 720p/30.
Future: 10-12 bit per channel, wide gamut, 1080p/60, possibly stereoscopic.
Pipeline:
rescale/compose Colorspaces we care about:
BT-709 (sRGB) - the web, HD everything
BT-601 - DVDs, SD TV, other old stuff
Whatever your monitor uses
CIE XYZ (Digital cinema, wide-gamut video) (Explanation of a chromaticity diagram)
Scaling/Resampling
Scaling is hard to do well, near-axis-aligned lines will alias badly What do apps want to know?
Exact frame rate of the output pipe
Exact time of image presentation
Sync to vblank XVideo API
Good sides: Zero copy with the SHM extension, simple, maps well to the original problem domain
Bad sides: attributes underspecified, lots of useless attributes, missing modern details, slightly desynced with X rendering, doesn't work in cairo XVideo implementations
Good: works everywhere, tends not to use software fallbacks
Bad: vertical softening, bad scaling, bad conversions, no rgb support, only one overlay OpenGL
Good: lots of control
Bad: needs GLSL for that control, very complicated, no native YUV, three ways to do vsync, not meant for video, can't connect XVideo port to OpenGL OpenGL implementations
Good: intel works, mostly; nvidia works, windows works.
Bad: works inconsistently Future
Pluggable pipeline
Extend XVideo
GPGPU codecs
R500 was 3d build on R300. Very similar designs.
(Diagram of GPU hardware evolution)
R600 Overview
Compose rect engine Host data path
32 surfaces for tiling and swapping
Can do virtual or physical addresses
Privileged and non-privileged access per surface Command processor
Same basic setup and semantics as previous generations
New prefetch parser
Dedicated DMA engine
Lots of new Type 3 packets
All drawing and state can go through the CP, no need to touch registers
2D packets emulated by the CP
Insert interrupts for event completion Paging and DMA engine
Has own ring buffer, async from the GPU
Host BLT, copy BLT, fences, interrupts
Different packet formats from CP Interrupt handler
Dedicated ring buffer for incoming interrupts
Source ID to map interrupt to originating block and subfunction Virtual memory
Translation of logical addresses seen by clients into physical addresses seen by the memory controller
Page fault detection (maybe not validated)
Page access bits (also maybe not validated) Unified shaders
One big program of control flow, ALU, or fetch clauses
128 bit pixels, 5 way superscalar, access to vector and scalar results from previous insn
Five main types of shader: vertex, pixel, geometry, DMA copy, fetch Compose rect (crazy 1-bit text accel thing)
Driver plan
Proposed features:
Standard output properties DPMS
Goal is power management without polling
Basic plan: Enable/Disable requests, OutputDPMS request, OutputDPMSChanged and EnableChanged event, IDLETIME sync counter
Allows DPMS transition to be decoupled from "idle"
Provides DPMS notification to applications
Leaves legacy auto-DPMS stuff around
New enable and disable are refcounted. Event includes the refcount. Panning rectangle
Bounding box for the CRTC, just moves the CRTC origin around
CRTC follows mouse on edge transitions
CRTC events will be generated, probably needs to be a PanningNotify for lack of room Projective transform
Handles input
Uses existing rotation backend
No driver impact
Would be more efficient done in the compositing manager, but wouldn't handle input
This actually works. Whoa. GPU objects
Completes the object hierarchy
Object, list of properties, mapping to CRTC Standard output properties
Provide more information about outputs
Connector type, signalling level, etc.
Need a list and a definition of each
Started working on tinderbox as part of the OLPC bringup effort
Got interested in adding that test harness to X
It works! tinderbox.x.org
Gives you a long list of build results, properly hierarchical, triggered by commits.
Also has some basic test infrastructure for sanity-checking the builds:
What else do we need?
XCB is a replacement for Xlib: a thin C binding with latency hiding and transparent multithreading
Just does a protocol binding and some language bindings
... and then also has a util library
In attempting to port x11perf to XCB, noticed that the image implementation is broken
X image protocol is subtle and quick to anger. Not many apps use the Xlib facilities in interesting ways.
The gory details
Maybe convert or expand xcb/util/image provides:
Create new image with given or native format
Convert images between formats
fast get/put pixel inlines
User-controllable memory management
Protocol insulation xcb_bitops.h provides some fast bit-banging inlines
Forced some reevaluation of some XCB design
util packaging Requests for help and further work
Finish the x11perf port
Image test suite
Specify or build other userland libs
Port apps to XCB
Wine is a set of libraries to allow running unmodified Windows apps.
Uses X for input and output, translates GDI and DirectX to X APIs
Raw mouse input
3D rendering issues
Members! Be members. Go to members.x.org
We exist to provide education, support, and infrastructure to enable X development. If you think you could use some of that, let us know! We will do what we can.
Meetings and conferences are not necessarily limited to XDC and XDS. If you want to do something smaller and local, let us know! We will do what we can.
The software has been coming out. See elsewhere for details.
Vendor relationships keep getting better. Docs and source keep coming out. Life is good.
We are doing GSoC again. We may be doing additional direct student funding again.
We are VESA members, we're about to be CEA members. We should do something about Khronos; if this is you, let us know! Getting this information out to the development community is important, so let us know if this will help you.
The old LLC structure is being closed out, finally. We're within epsilon of being a 501(c)3.
Apologies for the election being so chaotic last time around. There is a team working on improving this process.
Current board meeting structure is bi-weekly for the whole board plus committee meetings as needed.
Membership agreement is being finalised to make membership easier to agree to and sign up for.
We're spending money well now. We will begin looking for sponsorships again. Healthy cash flow is healthy.
Infrastructure between x.org and freedesktop.org is being merged behind the scenes, for the betterment of both.
There is another major conference coming. September 10-12 (ish) is XDS 2008 at Edinburgh Zoo. Conference facilities, probably a sunset tour, general good times. Should have final details in a few weeks.
Some minor optimizations to be had with CSE. Things I hate
State polling requests suck. "Give me the state of the keyboard! Including button up/down!" Doom.
bg=None.
Every protocol request is an entrypoint.
But each one has to be characterised, and it's the ioctl problem.
(Hateful spreadsheet)
EVI, XTrap/Record, DoubleBuffer, MultiBuffer. Die. (XT/R needs a closer look.)
MIT-SUNDRY-NONSTANDARD. Die.
APPGROUP. Unused. Die.
XFree86-DGA. Dead once we get relative mouse motion.
XFree86-Misc. Die.
TOG-CUP. Die.
Xinerama. Enh. Kinda hard.
DPMS. Can pretty much just go.
XFree86-VidModeExtension. Can die once we fix RANDR. To-do
Finish some XCB stuff.
GLX and DRI.
MPX/Input security improvements.
Move on to higher desktop layers. (Technical discussion of how to fix bg=None)
Owen Taylor is working on fixing Radeon Render performance. And making progress! Should be done as generic Render services, so everyone wins.
John Bridgman raises some concern about lockstepping DRM and X as far as getting support pushed out. There's some slip, it works. But it is something the driver maintainers need to be conscious of. Also, what are the last steps to getting X to run as non-root?
Paulo Zanonni and Tiago Vignatti on VGA arbitration. This needs to be done in the kernel to get it right, since each server may want to have VGA space routed to it at various times. Existing proof-of-concept as kernel+library+server code. Should just be a /dev node.
Jesse Barnes on getting off of /dev/mem. Mostly there. How do we expose caching policies to maps? How do we deal with non-PCI video devices like USB?
Adam Jackson on Xinerama and shatter and stuff. If you're interested, go talk to him. http://cgit.freedesktop.org/~ajax/xserver-shatter
Daniel Stone on input. Core, XI, and XKB. Massive amounts of duplication. This is really terrible. Lots of it is being fixed, yay! Being worked on in xkb-atkins branch. This is sort of a prerequisite for merging MPX.
Bart says cut and paste is still broken.