airlied

ripping the X server a new driver API

Mon, 14 May 2012 17:05:58 GMT

So I've been slowly writing the hotplug support v3 in between all the real jobs I have to do.

[side note: When I started out on hotplug. one of my goals was to avoid changing the server API/ABI too much so I could continue side by side testing.]

how did I get to v3?
v0.1: was called dynerama it failed miserably and proved that using Xinerama as the plugging layer was a bad plan.
v1: was the first time I decided to use an impedance layer between some server objects and driver objects.
v2: was the a major rebase of v1.

v2 was trucking along nicely and I managed to get the design to the stage where PRIME offloading intel/nouveau worked, USB device hotplug with udl worked, and GPU switch worked between two drivers. However v2 duplicated a lot of code and invented a whole new set of API objects called DrvXRec, so DrvScreenRec, DrvPixmapRec, DrvGCRec etc, this lead me to looking at the pain of merging this into the drivers and the server, and my goals of avoiding changing the API/ABI was getting in my way.

So before starting v3 I decided to rework some of the server "APIs".

The X server has two main bodies of code, one called DIX, and one called DDX. The DIX (device independent X) code and the DDX (Device dependent X code). In the X.org tree the dix lives up in the top level dirs, and for X.org server the DDX lives in hw/xfree86. The main object with info about protocol screens and GPUs is called ScreenRec in the DDX and ScrnInfoRec in the DIX. These are stored in two arrays, screenInfo.screens in the DIX and xf86Screens in the DDX, when code wants to convert between these it can do one of a few things.

a) lookup by index, both structs have an index value, so to go from ScrnInfo to Screen you look at screenInfo.screens[scrninfo->scrnIndex] and other way is xf86Screens[screen->myNum]. This is like the I didn't try and make an API, I just exposed everything.

b) ScrnInfo has a ScreenPtr in it, so some code can do ScrnInfo->pScreen to get the pointer to the dix struct. But this pointer is initialised after a bunch of code is called, so you really can't guarantee this pointer is going to be useful for you.

c) XF86SCRNINFO uses the DIX private subsystem to lookup the Scrn in the Screen's privates. This is the least used and probably slowest method.

So also screenInfo.screens contains the protocol screens we exposed to the clients, so this array cannot really change or move around. So I'd like to add screeninfo.gpuscreens and xf86GPUScreens and not have drivers know which set of info they are working on, however (a) totally screws this idea, since the indices are always looked up directly in the global arrays.

Now lots of the Screen/ScrnInfo APIs exposed to the drivers pass an int index as the first parameter, the function in the driver then goes and looks up the global arrays.

So my first API changes introduce some standard conversion functions xf86ScreenToScrn and xf86ScrnToScreen, and converts a lot of the server to use those. Yay an API. The second set of changes then changes all of the index passing APIs to pass ScrnInfoPtr or ScreenPtr, so the drivers don't go poking into global arrays. Now this is a major API change, it will involve slightly messy code in drivers that want to work with both servers, but I can't see a nicer way to do it. I've done a compat header file that will hopefully allows to cover a lot of this stuff where we don't see it.

I've ono other API introduction on the list, Glyph Pictures are another global array indexed by screen index, I've gone and added an accessor function so that drivers don't use the index anymore to get at the array contents directly.

Once this stuff lands in the server, a team of people will go forward and port the drivers to the new APIs (who am I kidding).

update on hotplug server

Thu, 22 Dec 2011 17:28:41 GMT

No new videos yet, need to fix some more rendering bugs so it looks nicer :)

So I've been working towards 3 setups:

a) intel rendering + nouveau offload
b) nouveau rendering + DVI output + intel LVDS output
c) hotplug USB with either intel or nvidia rendering.

Categorisation of devices roles:
I've identified 4 devices roles so far:
preferred master: the device is happy to be master
reluctant master: the device can be a master but would rather not be
offload slave: device can be used as an additional DRI2 renderer for a master
output slave: device can be used an additional output for a master

For the 3 setups above:
a) intel would be preferred master, nvidia would be offload slave
b) nvidia would be preferred master, intel would be output slave
c) usb devices would be output slaves, however if no master exists, usb device would be reluctant master.

I've rebased the prime work[1] on top of the dma-buf upstream work, and worked through most of the lifetime problems. Some locking issues still exist, and I'll have to get back to them. But the code works and doesn't oops randomly which is good.

prime is the kernel magic needed for this work, as it allows sharing of a buffer between two drm drivers, so for (a) it shares the dri2 front pixmap between devices, for (b/c) it shares a pixmap that the rendering gpu copies dirty updates to and the output slaves use as their scanout pixmap.

So I've done nearly all the work to share between intel and nouveau and I've done the kernel driver work for udl, but I haven't done the last piece in userspace for (c), which is to use the shared pixmap as usb scanout via the modesetting driver.

Today I hacked in a switch on the first randr command, so I can start the X server with intel as master and nouveau in offload mode. I can run gears on intel or nouveau, then after the randr command and another randr command to set a mode, the X server migrates everything to the nouveau driver, puts it in master mode, and places the intel driver into output slave mode. It seems to render my xterm + metacity content fine.

So the current short-term TODO is:
fix some issues with my nouveau/exa port rendering
fix some issues with xcompmgr
add usb output slave support.

Medium-term TODO:
worked out how to control this stuff, via randr protocol. How much information do we need to expose to clients about GPUs, and how do we control them. Open issues with atomicity of updates to avoid major uglys. Switching from intel master to nvidia master + intel outputs, means we have to reconfigure the Intel output to point at the new pixmap, but the more steps we put in there for clients to do, the more ugly and flashing we'll see on screen, however we probably want a lot of this to be client driven (i.e. gnome-settings-daemon).

Longer term TODO:
Get GLX_ARB_robustness done, now that Ian has done the context creation stuff, this should be a lot more trivial. (so trivial someone else could do it :)

[1] http://cgit.freedesktop.org/~airlied/linux/log/?h=drm-prime-dmabuf

hotplug demo video (teaching X.org new tricks).

Fri, 21 Oct 2011 11:15:25 GMT

So today I managed to see something on screen doing X.org hotplug work. So I present to you live X.org plugging.

http://www.youtube.com/watch?v=g54y80blzRU

Pretty much is a laptop running xf86-video-modesetting driver, with my server, an xterm + metacity. Plug in a USB displaylink device, with a kernel drm driver I wrote for it. (Sneaky xrefresh in the background). and the USB device displays the xterm and metacity.

So what actually happens?

The X server at the start had loaded drivers using udev, and the a new driver ABI. It exports one X protocol screen and plugs an internal DrvScreen into it.

When the hotplug happens, the server inits another DrvScreen for the new device, and plugs it into the single protocol screen. It also copies all the driver level pixmaps/pictures/GCs into the new driver. The single protocol screen at the bottom layer multiplexes across the plugged in drvscreens.

This is like Xinerama pushed down a lot further in the stack, so instead of doing iterations at the protocol level, we do it down at the acceleration level. Also I have randr code hooked up so all the outputs appear no matter what GPU they are from.

This isn't exactly what I want for USB hotplug, ideally we'd use the main GPU to render stuff and only scanout using the USB device, but this is step one. I also need the ability to add/remove drvscreens and all the associated data in order to support dynamic GPU switching.

The real solution is a still a long ways off, but this is just a small light in a long tunnel, I've been hacking on this on/off for over a year now, so its nice to see something visible for the first time.

first impression of google plus

Tue, 19 Jul 2011 10:00:08 GMT

If you've seen the social network, you know when he launches "The Facebook" the first time he needs his friend with the non-nerd contacts email list, I get the feeling that google plus never got this step.

When I joined facebook it was because my mother sent me an invite.

The thing is finding out what my nerd friends are doing is easy, they are always on irc or mailing lists or twittering. I'm not sure what google+ adds to this.

glibc - inconsistent interfaces due to arrogance

Wed, 11 May 2011 07:56:32 GMT

To start off, I don't actually mind arrogant people as long as they back their attitude up with some semblance of sanity, however arrogance without ability pisses me off, and it seems that its the number 1 trait to be a maintainer of glibc.

Today someone pointed out F_SETOWN_EX to me which I can use to fix a problem in the X server, however trying to use gettid made me realise why these guys are considered such fuckwits.

http://sourceware.org/bugzilla/show_bug.cgi?id=6399

WTF? glibc exposes 3 interfaces that need the result of gettid passed to them and internally relies on gettid to implement raise properly and it won't expose the interface. Notice in the bug he never addresses the problems, just closes it with "CLOSED ARROGANCE".

Other recent glibc fuckwittery includes the whole overlapping memcpy issues in F14 breaking flash for everyone, and trying to remove the rpc implementation a week before the F15 final release freeze, so that if the package had gotten in and packages that needed a rebuild for say a security fix would mean linking the fixed package against a different RPC library than the original which could cause untold pains.

So really if glibc could DIACF already thanks.

upgraded planet.kernel.org + planet.freedesktop.org planet software to venus

Tue, 29 Mar 2011 00:11:55 GMT

This is a test post hidden in an informational post.

I've upgraded the planet generator software for planet.kernel.org and planet.freedesktop.org to the latest venus codebase.

This was mainly due to the older planet software running p.fd.o taking down the webserver once or twice this week.

Hopefully it doesn't do any damage.

LCA 2011

Sun, 23 Jan 2011 23:25:19 GMT

First day of LCA 2011 at Kelvin Grove QUT Brisbane.

I'll be organising the Southern Plumbers mini conference today, and will be speaking on Thursday at 11:30 AM about graphics drivers (who'd have guessed).

working t410s intel/nvidia basic switching

Tue, 07 Dec 2010 04:42:55 GMT

git repo:
http://git.kernel.org/?p=linux/kernel/git/airlied/drm-testing.git
branch: drm-nvidia-switch

So I have a T410s with an LVDS panel and switchable graphics between intel and nvidia. I've gotten the basic switching support just like we have on the intel/amd combination.

The code is a start towards generic nvidia/nvidia and intel/nvidia switching but its missing some bits. The MUX switch on some GPUs relies on passing a parameter to the WMI function that we aren't passing, luckily the lenovo doesn't need this parameter at the moment so it works fine. Other laptops in this range may require the parameter.

I'll try and get some more info on the magic value we need to pass on other systems to make it work better, other systems like the Sony Vaios have a number of muxable outputs listed in a table, that the intel acpi code prints out at drm.debug=0x4. Again the lenovo doesn't have this table.

Other issues:
once switched and powered off the Intel, we get log spam from the IPS driver about the MCP limits.
nouveau gets a 1024x768 console since we can't detect the LVDS panel at startup.

also, this only works with open source drivers, i915 and nouveau.

some info on intel/nvidia switchable

Tue, 09 Nov 2010 01:09:27 GMT

Okay I sat down for a few hours last week with a switchable Intel/NVidia GPU laptop, and at least worked out some more info. I'm going to braindump it here.

Firstly in intel_acpi.c jbarnes has worked out some of the values for outputs in the ACPI tables esp around what is and isn't MUXed.

Now we had suspected that one of the nvidia GPU DSM methods (method 5) might actually do something, but a deeper investigation along with mjg59 made us realise it isn't the mux control, so we started looking elsewhere.

So we tracked down the MXDS method which is attached to the ACPI outputs per GPU, there is one on the LVDS for the internal GPU and one on the LVDS for the external GPU. So it appears that this is the mux switching object. Looking further up it appears that this is called via a WMI interface, so to do this all properly it looks like we need to write a WMI driver to call the mux switching, instead of just banging on ACPI methods.

So going forward a WMI driver needs to be written to which you pass the ACPI output IDs to the WMI MXDS method, and it should switch the mux.

Now despite this we didn't actually get the switching to happen, nouveau never got an auxch connection to the panel on the laptop, so I'd really like to see if anyone is useful enough to take this knowledge and make it do something on an LVDS laptop, all I have locally are a big pile of hacks.

Thanks to Jesse Barnes for the laptop, and Matthew Garrett for the ACPI decoding.

[update: one commentor asked about Macs, they have a non-WMI, non-ACPI method of handling things, sidolin on #nouveau at one stage mostly reverse engineering the mux, which was just reading/writing some memory mapped I/O ports to do the switch, not sure how far he is from pushing some patches out].

Southern Plumbers Miniconf CFP (LCA 2011 - Brisbane)

Sat, 25 Sep 2010 03:29:40 GMT

As part of LCA 2011, we are organising a mini-conference to provide a place for low-level system developers to gather and discuss interesting aspects of the kernel and lowlevel userspace. This miniconf is aimed at a similar audience to the Linux Plumbers Conference.

We'd really like to have talks that are entry points to open floor discussions and interactive sessions, though if a talk is interesting enough it will be considered depending on the quality of other submissions.

Areas of interest:
- Linux kernel
- X.org / Mesa
- toolchain/gdb (not deep compiler stuff, more system interactions)
- udev/u*/*Kit/hal replacements
- systemd/upstart/sysvinit
- virtualisation

The Southern Plumbers mini-conference is planned for Monday 24th Jan 2011.

Please send all submissions to airlied@gmail.com. Submissions will close on Friday, October 29th (when I leave for the real Linux Plumbers Conference), though I may accept submission over the week of LPC as well if I can drum up interest.

CFP available at http://planet.kernel.org/splca/cfp.txt

--
Dave Airlie and Matthew Wilcox.

embedded GPU : what are they hiding?

Sat, 03 Jul 2010 01:28:52 GMT

So to follow on from my posting stating my position wrt kernel drivers for closed source userspace drivers, lets take a look at the embedded GPU industry and Linux kernel relationship.

What does the embedded industry get from Linux?

They get a kernel which is royalty free, with 1000s of man-years of development experience and resources. Before Linux these vendors either sourced an OS on a royalty basis from some closed-shop, or rolled their own in-house one.

Now people might say "but the embedded GPU industry has to support Windows as well", but take one look at NVIDIA Tegra One and you can see the embedded windows marketplace is less than important, NVIDIA Tegra Two is all about the Linux, whereas they were pretty much only talking to MS on Tegra one.

So Linux is a great boon for this industry, and means they can produce higher quality products for a lower cost (or lower quality products at a lower cost in some cases). So really there are probably two games in town for these embedded vendors, selling into Apple or selling into Linux centric developments, like Android, Meego, Linaro.

So what are they actually hiding in userspace?

The main thing they seem to be hiding is shader compilers and their GPU assembler code, things that convert from GLES into the assembler code for their GPUs. This stuff isn't rocket science but it probably is where most of their speed up and tricks are hidden.

So why do they think it valuable?

I think all 3D IP vendors dream of becoming Imagination Technologies, they need to learn there is already one Imagination Technologies and the only way to easily disrupt their revenue stream and sell into other SOCs is to be disruptive, not just follow the herd. They also probably had to spend a lot of money writing a decent GPU compiler from scratch, whereas most embedded firmware is a lot more trivial, so they probably think they need to directly recoup the costs from this development instead of giving it away. The thing is they are hw vendors, the sw is a sunk cost, opening it would actually make future maintenance easier. HW companies never do well at SW and they would be best to just open it and try and involve some community development around it.

Is the value of this IP more valuable than what the receive from Linux?

This is the crux of my issue with these vendors, they are receiving the Linux kernel for free, but don't want to contribute anything back. They know they can't sell into any where else except Linux driven products, but they insist on keeping their development methodologies from the days of Windows and their own in-house OSes. Those days are gone, but they cling to the idea that for some reason they can produce a better GPU stack on their own than they could in collaboration with other, despite the fact that the kernel that forms the basis for their sales was developed in this fashion. They also all use gcc as the compiler for their CPUs again proving the insanity.

Isn't it up to them what they do?

Totally, but its also up to the Linux community to push back against them. The thing is they'd never have opened any code if it wasn't for the GPL making them at least open the kernel portions, they don't care about freedom or GPL, they care about their bottom line, and doing the least amount of work to remain legal and make money. Now they are getting all this wonderful software for free, Linux phone sales are driving their bottom line, but they still don't want to play the game by the rules of the kernel. They want to have their cake and eat it too. (the cake is a lie). Hence they spend their time creating their own solutions in private, releasing what they have to comply with legalese but never actually allowing people the freedom to use their devices.

So shouldn't we give a little?

The thing is two major vendors have been pushing Imagination Technologies for years to open something, these guys are aiming to sell thousands->millions of devices, we have gotten the ugliest kernel shim in the world in 4 years of trying. All the other vendors are only willing to give that little. I don't personally think any of them want to open this stuff and will hide behind IP excuses for ever.

What will make them change their minds?

a) money and lots of it. If google or olpc can demand open driver commitments (in contracts, not handwaving agreements) then I suspect these vendors will quickly realise the value of their IP is dwarved by the value of sales. This probably means a major chance for one of the vendors to control a lot of the space in the Linux world.

b) disruptive vendor, one vendor realises before the others that opening their IP will lead to more sales than keeping it closed and also lead to the chance of more people optimising their technology and leveraging other work in the industry.

So are you saying they should drop all their in-house developed solutions?

No I'm saying that the driver for their hardware is a single entity, and if the whole entity isn't open, then none of it is truly open. So if they don't want to release an open userspace, then they don't get to merge their open kernel bits to support the closed userspace. We have to keep the maintenance burden on them, so it keeps costing them money to track newer kernels, and they don't get community support from other vendors who have committed to doing things right.

So why should they re-write drivers?

This happens in Linux the whole time, with nearly every new technology. Wireless, RAID, SATA for example, all have had vendors trying to push complete stacks of their own writing, you'll notice over time the drivers that are actually written to the current stacks work best, an the crazy vendors drivers are often horror shows.

What would be nice to happen?

It would be great if there was a hero with time/funding and involvement in the ARM GPU community to take over being maintainer of these solutions, from kernel all the way to userspace. Vendor driver writers could ask this person for advice, and they could have some sort of working group where they develop a stack based around current Linux technologies, like GEM/TTM/DRI2/Mesa/Gallium3D. If you take a look at the mesa stack lately, there has been a lot of work on making it work as an EGL/GLES stack as well as a classic GL stack. Then vendors would supply open drivers compliant with this stack, and just sell lots of chips.

What would be most likely negative solution?

We get what we have now, they maintain the 5-6 GPU stacks in their own world, and never talk to each other, and it costs them more and more money going forward to maintain. Some hero reverse engineers one or two of the GPU architecture, maybe some hero writes a open driver stack from docs under NDA or with open docs.

I may update this post as I have more thoughts ;-)

open source kernel bits with closed source userspaces

Thu, 01 Jul 2010 23:42:14 GMT

[I posted this to lkml earlier - discussion should happen there not in comments here, but its nice to have somewhere easy to point people at].

Now this is just my opinion as maintainer of the drm, and doesn't
reflect anyone or any official policy, I've also no idea if Linus
agrees or not.

We are going to start to see a number of companies in the embedded
space submitting 3D drivers for mobile devices to the kernel. I'd like
to clarify my position once so they don't all come asking the same
questions.

If you aren't going to create an open userspace driver (either MIT or
LGPL) then don't waste time submitting a kernel driver to me.

My reasons are as follows, the thing is you can probably excuse some
of these on a point by point basis, but you need to justify why closed
userspace on all points.

a) licensing, Alan Cox pointed this out before, if you wrote a GPL
kernel driver, then wrote a closed userspace on top, you open up a
while world of derived work issues. Can the userspace operate on a
non-GPL kernel without major modifications etc. This is a can of worms
I'd rather not enter into, and there are a few workarounds.

b) verifying the sanity of the userspace API.
1. Security: GPUs can do a lot of damage if left at home alone, since
mostly you are submitting command streams unverified into the GPU and
won't tell us what they mean, there is little way we can work out if
the GPU is going to over-write my passwd file to get 5 fps more in
quake. Now newer GPUs have at least started having MMUs, but again
we've no idea if that is the only way they work without docs or a lot
of trust.

2. General API suitability and versioning. How do we check that API is
sane wrt to userspace, if we can't verify the userspace. What happens
if the API has lots of 32/64 compat issues or things like that, and
when we fix them the binary userspace breaks? How do we know, how do
we test etc. What happens if a security issue forces us to break the
userspace API? how do we fix the userspace driver and test to confirm?

c) supplying docs in lieu of an open userspace
If you were to fully document the GPU so we could verify the
security/api aspects it leaves us in the position of writing our own
driver. Now writing that driver on top of the current kernel driver
would probably limit any innovation, and most people would want to
write a new kernel driver from scratch. Now we end up with two drivers
fighting, how do we pick which one to load at boot? can we ever do a
generic distro kernel for that device (assuming ARM ever solves that
issue).

I've also noticed a trend to just reinvent the whole wheel instead of
writing a drm/kms driver and having that as the API, again maintainer
nightmares are made of this.

d) you are placing the maintenance burden in the wrong place

So you've upstreamed the kernel bits, kept the good userspace bits to
yourselfs, are stroking them on your lap like some sort of Dr Evil,
now why should the upstream kernel maintainers take the burden when
you won't actually give them the stuff to really make their hardware
work? This goes for nvidia type situations as well, the whole point is
to place the maintainer burden at the feet of the people causing the
problems in an effort to make them change. Allowing even an hour of
that burden to be transferred upstream, means more profit for them,
but nothing in return for us.

lolbuntu

Tue, 04 May 2010 23:30:46 GMT

Ted with the smackdown:

https://bugs.launchpad.net/ubuntu/+source/linux/+bug/543617/comments/20

Update:
when you can't fix bugs in your "enterprise distro" file them against someone elses community distro:
https://bugzilla.redhat.com/show_bug.cgi?id=588930

engineering FAIL

Fri, 16 Apr 2010 05:19:46 GMT

So we bought an Electrolux front-loader washing machine just over a year ago, all ready for the amount of washing a baby produces!!

a few days ago, the drum stopped spinning. I did all the filter cleaning etc the manual recommended but still no moving drum. So as I was ringing the warranty repair people I decided to use a lot more force than I'd consider using on something under warranty. This was followed by the sound of a coin dropping somewhere inside and the drum moving again. However it still wouldn't move under power. So I called Electrolux who gave me the is Tuesday 2 weeks good for you?.

So I decided to have a look myself, took the lid off and low and behold the drive belt had snapped in half. So today I bought a new drive belt from a spares place and tonight I shall endeavour to resurrect the washer.

Now some net searching over the course of last night discovered this is a really common problem on these washing machines. The washing machine when faced with the prospect of coins will just let a coin enter between the two drums and once there it can then jam the inner and outer drums together and cause the drive belt to snap or the motor to give up. Now I'm not the best person at taking money out of my jeans and stuff goes into the wash sometimes before I notice, but really who thinks selling a washing machine that can die when faced with one or two accidental coins is a) something you can sell, b) something you can apparently say isn't a warranty fault as there is a sticker on the thing saying not to put coins in it. I think if Electrolux came to fix it would cost nearly 1/4 the price of the washing machine if the warranty didn't cover it.

So I'm hoping to abuse my google juice to say to everyone "DON'T BUY ELECTROLUX FRONT LOAD WASHING MACHINES" because they obviously don't think about using them in the real world.

radeontool 1.6.1 released

Wed, 24 Mar 2010 03:30:14 GMT

I've just done a 1.6.1 release of radeontool from my personal repo, it contains both
radeontool and avivotool, and is probably full of ugly but whats in distros now is older
and worse.

radeontool (and avivotool) are lowlevel tools to tweak register and dump state on radeon
GPUs, they also can parse parts of the BIOS data tables.

Tarballs are at
http://people.freedesktop.org/~airlied/radeontool/

git://people.freedesktop.org/~airlied/radeontool.git

Main changes:
r128 support from Jonathan Nieder
Some new legacy table decoding added
cleanups

two X servers one graphics card.

Thu, 18 Mar 2010 01:59:57 GMT

So sane multi-seat handling was something I wanted to make KMS do at some point and designed for but never quite implemented.

So in an attempt to maybe get help out people who are interesting in this I've gotten two seats on a single card working here to a demoable level.

http://people.freedesktop.org/~airlied/multiseat/

contains a kernel patch + libdrm patch.

The kernel patch pretty much contains 3 pieces:

(a) ability to create "render" device nodes with an attached list of output resources it controls (crtcs/encoders/connectors).
(b) hardcoded render node setup for my X1900 - two parts - core drm creates 3 devices nodes, radeon driver assigns hardcoded
resources to the nodes - in this case render node 0 gets a crtc + DVI + encoders, and node 1 gets the other crtc/DVI/encoders, and
render node 2 gets no outputs.
(c) drm mapping fixups for multiple device nodes - this is something we should probably cleanup independently of this patch.

the libdrm patch just contains support to use an env var to pick the device path.

With this xorg.conf and the two startx wrappers I can run two X servers separately.

TODO:
(a) define a kernel/user interface to set seats and nodes up. The DRM control node is there specifically for this purpose but I never got around to specifying this interface. It basically needs a few methods:
1. Create new render node with output configuration.
2. Remove render node.
These would have to rely on their being no users of the render or legacy device nodes in advance. The kernel would
also have to get the driver to validate the output configuration. The output configuration would be a list of IDs for crtcs/encoders/connectors.

(b) maybe add a drm device path to xorg.conf so each card section can specify one, would help get away from BusID also.

(c) make a sane userspace interface to use it all - I suspect you'd need something in gdm/ConsoleKit to configure this sort of
thing, you'd have to construct per-card multi-seat profiles with a list of the outputs and stuff you want on each seat etc.

At this point I'm just trying to flesh out my backlog of projects and figure out how long they will take to do properly, feel free if someone is interested in picking this up and running with it.

GPU offloading - PRIME - proof of concept

Fri, 12 Mar 2010 06:16:59 GMT

THIS IS A PROOF OF CONCEPT - its not going to be upstream unless someone else dedicates their life to it, (btw anyone know anyone in ASUS?)

So NVIDIA unveiled their optimus GPU selection solution for Windows 7, so I decided to see what it would take to implement something similar under DRI. I've named it PRIME for obvious reasons.

Goals:
1. Allow a second GPU to render 3D apps onto the screen of the first, pickable from the client side.
2. Just target the rendering side, I'm assuming the GPU power up/down is similiar to what was done for the older switching method.

Restrictions + limitations:
1. Must have compositing manager running
2. Must have second screen configured for slave card (doesn't need to be used)

Test system:
Intel 945 IGP + radeon r200 PCI card - yes this won't be a speed demon.

Terms:
Master: the IGP displaying the output - intel
Slave: the GPU rendering the app - radeon r200 in this case.

Step 1: kernel support

http://git.kernel.org/?p=linux/kernel/git/airlied/drm-testing.git;a=shortlog;h=refs/heads/drm-prime-test
http://cgit.freedesktop.org/~airlied/drm/log/?h=prime-test

The kernel requirements were simple, we needed a way to share a memory managed object between two kernel device drivers.
The kernel has a GEM namespace per device, however this isn't good enough to share with other devices, so I introduced a new PRIME namespace with two ioctls. One ioctl allows the master device to associate a device buffer handle with a name in the prime namespace, and the other allows the slave device to associate a prime namespace handle with a buffer. When the master creates a prime buffer the kernel associates the list of pages with the handle, and when the slave looks up the same handle it retrieves the list of pages and fakes up a TTM buffer populated with those pages as backing store. I've added the concept of slave object to TTM to allow for this.

The drm repo contains the API wrappers + intel + radeon pieces to call the association functions for buffer objects.

Step two: DRI2 Protocol
http://people.freedesktop.org/~airlied/prime/0001-dri2proto-add-prime-token.patch
http://people.freedesktop.org/~airlied/prime/0001-prime-support-for-mesa.patch

From the X server point of view a recent change to the DRI2 layer allowed for multiple device driver names to be associated with a DRI2 end point. The client can request either a DRI or VDPAU device name currently. I firstly extended the DRI2 protocol, to add a new buffer type, called PRIME, and added a hack to mesa's glx loader to request the prime driver if an environment variable was specified.

Step 3: X server DRI2 module + drivers

http://people.freedesktop.org/~airlied/prime/0001-intel-add-prime-master-support.patch
http://cgit.freedesktop.org/~airlied/xf86-video-ati/log/?h=prime-test
http://people.freedesktop.org/~airlied/prime/0001-dri2-prime-hackfest.patch

This was the messiest bit and still requires a lot of change. First up I added an interface for the drivers to register as PRIME master and slaves. Intel driver registers as master, radeon as slave for my demo. We store these in an array. When a client connects and requests prime driver, we mark the drawable and redirect the dri2 buffer creation requests to the slave screen driver. Also the drm authentication is sent to both kernel drms. It then hooks the swapbuffers command where it does a region copy, and redirects this to the slave driver, and damages the pixmap in the master driver. Now the "interesting" part, my original implementation simply grabbed the window pixmap at the dri2 create buffers time, however there is an ordering issue with compositing, this pixmap is pre-composite redirection so isn't actually the pixmap you want to tell the kernel to bind to both gpus. This turned out to function badly, I could see gears all stretched over the front buffer.

So a quick coke + chocolate break later, I had enough sugar to bash out the hack that now exists. DRI2 calls the slave driver copy region callback, which checks if the drawable pixmap is on the same screen, if its not, it checks if we've marked the pixmap as a prime pixmap (i.e. one that belongs to the master). It is, it swaps in the slaves copy, otherwise it callsback into DRI2. This callback calls the Intel driver to make the buffer object backing the pixmap, shareable, and returns the handle,then calls into radeon with the handle to create a new pixmap pointing at the shared buffer object. Once all that is done, radeon copies the back buffer to the shared front pixmap, we return and damage is posted and the compositor grabs the window pixmap and displays it.

So does it work?
On my blistering fast test system with X + xcompmgr running glxgears was going at 150fps from the r200 PCI card. Hopefully I can get some time on a faster system or one of the dual laptops.

Caveats:
- When a window manager is running the gears get all corrupted, this looks like the clipping and/or stride matching between
the drivers isn't correct. I suspect something with reparenting and decorations, I'm not enough of an X guru to understand this yet, hopefully one of the other hackers can fill me in. Also before it gets reparented and redirected a frame can land on the real front buffer, again clipping should take care of this, but isn't working yet. I need to workout how clipping and that stuff works in X/DRI2. - talk to ppl about clipping then JDI.
- Once a client has connected as a prime, we don't tear it down properly, so later clients can end marked as prime. - work out some sort of resources to turn stuff off
- Reference counting on the pages in the kernel is iffy, currently i915 ups the page list refcount but never drops it. solution JDI
- hardcoded /dev/dri paths in dri2 for slave device - solution JDI
- radeon driver could in theory be a prime master - solution JDI
- nouveau could support prime master/slave also. - solution nouveau guys JDI
- requires an ugly second screen in xorg.conf to load the slave driver. Can we have a 0 sized screen or maybe a rootless second screen. - solution : rearchitect X server to allow drivers without screens (6m-1yr work)
- pageflipping needs to be hacked off in intel driver. - work out and then JDI

Where is the video?
Once I get it working with a window manager on a useful machine I might do a video of two gears going.

Where now?
Well this is a purely academic exercise so far, after a week of kernel fighting I decided to do something new and cool. To make this as good as Windows we need to seriously re-architect the X server + drivers. At the moment you can't load an X driver without having a screen to attach it to, I don't really want a screen for the slave driver, however I still have to have one all setup and doing nothing and hopefully not getting in the way. We'd need to separate screen + drivers a lot better. Having some sort of dynamic screens would probably fall out of this work if someone decides to actually do it.

The kernel bits aren't as ugly as I thought but I'm not sure if upstreaming them is a good idea without the others bits. The refcounting definitely needs work also the cleanup when clients exit.

DRI2 needs some more changes, I might try and flesh it out a bit more and then talk to krh about a sane interface.

I'm probably going to get forced task switch quite soon, so I might just get to having this running on a W500 or T500, before dropping it for 6 months, so if anyone wants a neat project to play with and has the hw feel free to try and take this on.

ASUS feel free to send me one of the real optimus laptops and I'll get nouveau guys hooked up and try and RE the nvidia DMA engine.

GPU switching update

Fri, 26 Feb 2010 05:04:56 GMT

Okay I've been busy elsewhere but dragged myself back to try and finish this for upstream

v10 of the patch is up
http://people.freedesktop.org/~airlied/vgaswitcheroo/0001-vga_switcheroo-initial-implementation-v10.patch

changes are mainly that mjg59 was right about keeping ugly things in the drivers.

adding ATRM support to get the ROMs on ATI hybrid for the discrete card was actually a pain with the previous code design,
so I moved lots of it around again, and now the discrete ROM can be retrieved via the ATRM method.

I've tested it on the W500 and it works as well as before, which means still the 3rd or 4th switch fails and locks the machine up,
I need to debug this further.

The refactored code should hopefully make it easier to fill in the nvidia/nvidia and intel/nvidia blanks for mjg59.

Update 1: v11 is now up
http://people.freedesktop.org/~airlied/vgaswitcheroo/0001-vga_switcheroo-initial-implementation-v11.patch
It should fix the failure to switch to IGD the 2nd time hopefully.

Update 2: v13 is now up, it blindly implements nvidia DSM changing, but I've no idea if it works. Hopefully someone can test it and give me some feedback. Its nearly all guesswork from work mjg59 did.

whats in drm-radeon-testing?

Mon, 08 Feb 2010 23:58:05 GMT

I'll try and post these regularly when I make major additions/removals.

drm-radeon-testing is the cutting edge KMS radeon branch, it is going to be rebased and things will be added/removed as they are worked on by developers. So you can base patches on it but you should talk to the developer who owns the area first.

git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git drm-radeon-testing

I've just pushed a rebased tree now with the following:

latest i2c algo + hw i2c engine code + all fixes squashed: This adds support for hw i2c engines found on radeons and
exposes them + sw i2c buses to userspace so i2c tools can use them. (agd5f).

pll algorithm reworking + quirks: cleans up the code to allow for the selection of the old pll algorithm on some hardware. (agd5f)

pm support so far: Adds all the current PM patches - just does engine reclocking so far using the power tables from the BIOS. (Zajec/agd5f)

Evergreen (Radeon HD 5xxx) support: basic KMS support for the evergreen range of devices - no irqs or accel yet. (agd5f)

radeon unlocked ioctl support (airlied)

bad CS recording (glisse)

misc cleanups/fixes - Dell/Sun server support ported from userspace hopefully.

The tree did contain Jerome's r600 CS checker but I've dropped it for now at his request as he has newer patches
in testing.

video of GPU switching

Thu, 04 Feb 2010 02:16:12 GMT

Here's a really badly shot video of GPU switching in action ;-0 - whiteouts are mostly be logging out and in ;-)

hybrid graphics : the story continues (part 3)

Wed, 03 Feb 2010 07:07:43 GMT

v6 of the patch + another patch which needs some work before I can merge it are available now.

This mainly cleans up the patch architecture a lot and allow for Matthew to put his nvidia code in easier hopefully. Its moves the ATPX specific code to the radeon driver.

The second patch is from an experiment that I videod on a webcam but am now failing to upload, I'll probably get a better video tomorrow, the lighting was fairly bad for it today.

It basically allows for a delayed gpu switch ( it changes the debugfs API ), and allows gpu drivers to block the switch.

The switch file now takes ON/OFF like always, but the PCI IDs input is gone. There are 4 commands

IGD - try and switch now to the integrated device - can fail if drm drivers block it (mainly if X has the device open)
DIS - try and switch now to the discrete device - can fail if drm drivers block it (X again).
DIGD - try a delayed switch to integrated device
DDIS - try a delayed switch to discrete device.

So with X running you can echo DDIS to the file and log off X, it'll then switch as soon as X closes the drm device, and when
gdm restarts X it'll be running on the discrete GPU. If we had a shiny GUI on top of this it'd be as close as MacOSX can do it.
When you select to do a delayed switch we power up the other GPU straight away so the switch is quicker.

It needs more debugging, some open issues include:

after a few switches it can die on its ass
powering up the Intel glitches the display even when running the AMD
there may be race conditions in the patch, probably need a mutex around device open + this stuff
suspend/resume - since we D3 the card, if you do an s/r cycle it'll resume it, we need a flag in the
driver to say its powered off by the mux and to ignore s/r cycles - I've started adding this to radeon.

mjg59 has access to an nvidia laptop and is looking closely at how to make that all work.

hybrid graphics on Linux (Part 2)

Tue, 02 Feb 2010 05:49:55 GMT

Okay v4 of the patch is available at

http://people.freedesktop.org/~airlied/vgaswitcheroo/
http://people.freedesktop.org/~airlied/vgaswitcheroo/0001-vga_switcheroo-initial-implementation-v4.patch

First thing I added was power up/down methods. This calls the DRM suspend/resume methods + along with the cut power for discrete GPU. I'm not sure dynamic Windows ever does this as it seems to take a bit of work, I suspect they just run the second GPU in really low power modes. This is slow because we have to repost the ATI card after turning it back on.

I then talked to mjg59 and worked over the ATPX detection. I removed all the DMI code and it should detect *any* laptop that uses ATPX (i.e. ATI/ATI and Intel/ATI) from what I can see. I've tested on Lenovo W500 and T500 now and it appears to work on both. Would be nice if someone on a ATI/ATI and/or ASUS ATI/ATI or ATI/Intel machines could give it a whirl. I think the main problem with ATI/ATI is the poweroff methods have a hardcoded Intel PCI ID. I've no idea yet how to tell on an ATI/ATI which device is the IGD and which is discrete. Its probably more than likely the IGD is the one with the ATPX method on it.

It doesn't switch off at boot yet but I've added commands to let you do it.

echo "OFF" > switch - turns off the not in use card, so if Intel and ATI are on at boot, it will turn off ATI
echo "ON" > switch - turns back on not in use card
echo "PCIID" > switch - causes a switch with full off/on cycles.

nvidia combos appear to use a DSM method and in theory nouveau_acpi.c should be detecting that, so it might be possible for someone to hook that up.

I've also started looking at some desktop integration via gdm or logout - but its not my usual place to code so going is a bit slower ;-)

hybrid graphics on Linux

Mon, 01 Feb 2010 09:03:08 GMT

So someone thought it would be a good idea to make laptops with two graphics chips in them and switch betweem them to save power.

Now other OSes support this to varying degrees, I think XP + MacOSX require a logout cycle and Vista/Win7 can dynamically switch while running, while Linux basically falls over in a heap.

So I sat down today with a Lenovo W500 which has an Intel GM45 and AMD Radeon 3650 Mobility in it, and I wrote a patch to try and get closer to the XP/MacOSX level.

The result of one days straight hacking is at:
http://people.freedesktop.org/~airlied/vgaswitcheroo/

The patch is totally focused on the Lenovo W500, other switchers will need to add stuff to this codebase.

So what works?
Boot in switchable graphics - which boots with intel and radeon turned on
KMS drivers load for radeon and intel, radeon BIOS stored in start of VRAM (driver hacked to read it)
bind to both drivers + fbs for both.
mount debugfs - cat /sys/kernel/debug/vgaswitcheroo/switch
2
0 :0000:01:00.0
1+:0000:00:02.0
shows the 02.0 (intel) device is in charge of the MUX.
goto runlevel 5, play with X under the Intel driver, goto runlevel 3 kill X
at fbcon echo "0000:01:00.0" > /sys/kernel/debug/vgaswitcheroo/switch
barely glitches console and switches
goto runlevel 5, play with X under the ATI driver, goto runlevel 3 kill X
echo "0000:00:02.0" > /sys/kernel/debug/vgaswitcheroo/switch
goto runlevel 5, play with X under intel again.
wash and repeat.

What does it do?
So far its just switching the MUX using the ACPI method and remapping all the console to the other framebuffer device,
it also reset the bits that denotes which devices is the boot vga device which X uses to pick the primary GPU. This
means X doesn't need an xorg.conf to switch. (I think all those patches are in upstream X server).

What does it not do?
It doesn't powerdown the radeon when its not in use yet. I know the ACPI call to power it off/on, and since I have
the BIOS I should be able to repost it. So I'll try adding the callbacks into the KMS driver to do this soon.
It doesn't poewrdown the intel when its not in use yet. Not sure what I can do here, since there is no ACPI method to turn
it off. I think I can just D3 the GPU, and use the normal s/r paths to bring it back. Again requires more investigation.
The whole what ACPI + methods map to what device, how the mux ids match etc will probably all need to be stored in the DMI table.
Anything not a Lenovo W500 - probably not that hard to add other Intel/AMD variants to this, add DMI and mux switching method.
nouveau isn't hooked up - this could probably be done by some interested party - the driver hooks so far aren't very hard.
No idea about ATI/ATI or NV/NV ones either.

I'm really hoping interested community people can make this actually useful to them on other hw, I won't have permanent access to the W500 to keep this all tested in the future.

Can we do dynamic switch without restarting X?
No. X needs a lot of work, a lot more than the day it took to hack the kernel.

How do we go forward?
We probably need to add gdm support to move this forward. A logout button that is "Switch GPU", that gdm kills the X server,
then hits the switch port and starts a new X server. I'll try and talk to some gdm hackers over the next few days.
I'll try and push this into a git tree against Linus current, and we can add tested patches for other machines as they go in.
Also the DMI section is only imaginary of what I think others might need, we might have to rip it all out. Also I've no idea
if there are ACPI methods to query the switchable modes etc.

LCA 2010 talk

Fri, 22 Jan 2010 03:18:39 GMT

So I originally was going to attend LCA 2010 for the week, but real life interjected and I couldn't abandon family commitments for that long, so I ended up doing a crazy cross-Tasman dash. As well as the change in flights, Isabel came down with a virus and Gia also got it, I think I got a milder version of it, but they both seem alright by the time I left but I had little sleep the previous two nights.

So I flew on Wednesday morning, got in Wed afternoon, met up with ppl, had a couple of beers, wrote slides, slept, finished slides, went to Thur morning, drugged myself up on Nurofen Plus to combat viral effects, gave my talk, went to see ajax talk, went to professional network dinner, went for beers with ajax + benh (listening to an American and a Frenchman speaking about wine while listening to drum n bass in a Wellington pub was a bit wierd). Decided to push on through, so got back to room at 3am or so, checked out/left for airport at 4:20am, flew at 6:20am, into BNE at 7am, home, bed, sleep for a few hours and mind Isabel for afternoon.

So my talk was "So you've put kernel graphics drivers in the kernel... what next? can I haz ponies?". My slide deck is off the 0-content style + lots of pictures of various ponies, which I've found, they'll be on the LCA site soon and I'll upload them when I plug that laptop in again.

(a) stop people reading ahead of your bullet points so they don't doze off while you are catching up
(b) gives them something to look at apart from me while they actually have to listen to me :-P

It seemed well received, the room was pretty packed out (ppl standing/sitting - LCA schedulers you listening?) and I don't think the sickness or lack of decent preparation made a big difference. I'd like to apologise for not even mentioning SGX/poulsbo, I'm not sure how but it totally slipped my mind, but the situation hasn't really changed in terms of how screwed it is.

radeontool 1.6.0 released

Thu, 17 Dec 2009 05:22:43 GMT

I've just done a 1.6.0 release of radeontool from my personal repo, it contains both
radeontool and avivotool, and is probably full of ugly but whats in distros now is older
and worse.

radeontool (and avivotool) are lowlevel tools to tweak register and dump state on radeon
GPUs, they also can parse parts of the BIOS data tables.

Tarballs are at
http://people.freedesktop.org/~airlied/radeontool/

git://people.freedesktop.org/~airlied/radeontool.git