Matthias Hopf

XDC: How to bring in more contributors

emmes — Mon, 12 Sep 2011 22:18:11 GMT

In my talk (or rather: structured discussion) "Methods of Attraction: How to bring in new contributors" on this year's X.org Developer's Conference I brought up reasons why open source projects often fail to attract new contributors, and some changes to help this.

During the discussion it turns out that for X.org the changes are either very non-trivial, or (better) somewhat implemented already (like the list of low hanging fruits, which basically boils down to our ToDo list and the Janitor subproject).

I didn't really expect any direct outcome from this discussion (as it's more like a meta discussion because we need to understand the real issues first), but I think it was fruitful especially in keeping everybody aware of the situation.

One interesting aspect regarding our (very) low female contributor ratio was brought up by Brian Cameron: The Gnome project has an apparently successful program to promote contributions of women in their project. Something to be checked out in the future, maybe X.org can join forces or set up something similar.

Bye bye, SUSE...

emmes — Thu, 01 Sep 2011 16:52:15 GMT

Yesterday was my last working day at SuSE Linux Products. After exactly 7 years of working for this awesome Linux distribution there was an opportunity I couldn't refuse. I made innumerable friends in this company (and it's the people that define a company!), and there were many great moments that will stick in my memory forever .

Now I'm moving (back) to academia, and will start teaching and researching at the Georg-Simon-Ohm University of Applied Science, as "Professor for Applied Computer Science" (which is the official job title).

Currently, it's the free period of the summer semester, and the University is almost deserted. I'm currently only starting to get used to the new environment, prepare courses, meet with other professors, etc.

I'm pretty excited about the new opportunities in this position, and will keep you posted how everything turns out!

Now back to Fantasy Film Fest again ;-)

Network Image Installer

emmes — Sat, 27 Aug 2011 16:09:44 GMT

During our work in our preload department at SuSE we have to install our current image on several machines for each image version for smoke testing, which meant burning several DVDs per iteration (and there is typically one iteration per week!).
In order to ease this work flow I created a kiwi image for a CD or an USB stick for installing the latest image via network - the Network Image Installer. It's also capable of installing arbitrary openSUSE / Fedora / Ubuntu versions, so you never have to burn another DVD if you have a reasonably fast internet connection. Network detection is automatic, wireless requires the SSID etc. changed in a config file beforehand.

Find the sources on gitorious, I will eventually try to understand the functionality in the openSUSE build service to create images automatically, but for now you'll have to build the image yourself. I'll post when there is a downloadable image available.

Now I'm off to Fantasy Film Fest again .

SUSE graphical benchmark test

emmes — Thu, 11 Aug 2011 18:06:31 GMT

We at SUSE needed to know whether we had some severe regressions regarding graphics performance during enablement of intel SandyBridge graphics - and it turned out that it was not commonly understood what graphics performance is actually composed of. Some were only interested in core X commands (xterm users :-) , some only in render performance (office users :-) , some in low-core 3D graphics (compiz users :-) , some in hardcore 3D graphics (gamers :-) .

So finally I put together a standardized graphical benchmark with aspects for all users. And no, it won't output a single number, because that would be meaningless for everybody. But it makes it easy to compare different aspects between different graphics cards and drivers, and there are some surprising results. But more about the results later.

The sources for the benchmark are now on gitorious, and the Wiki entry describes its usage. It's currently somewhat tailored to SLE11SP1, so you might run into minor issues when running it on a different OS version. And of course, it's not very polished yet .

!@#$% Spam...

emmes — Mon, 01 Aug 2011 10:54:13 GMT

Due to the amount of spam I'm receiving as comments I had to disable most of the comment functions of the blog. If you want to add a reasonable comment and have difficulties doing so, please just mail it to me, I will publish it.

Sorry for the annoyance, but it's better this way. Given that I'm not blogging too often, this shouldn't be much of an issue anyways.

RAnsrID: Galois Field / Reed-Solomon code rewrite pending

emmes — Fri, 03 Jun 2011 10:31:11 GMT

While starting to implement error resilience (not erasure resilience, which is already working nicely) in my RAID-lookalike multi-disk block device RAnsrID, I finally had to notice that I didn't understand one aspect of Galois Field mathematics - the Reed-Solomon representation type has heavy influence on how to deal with errors (read: corrupted data).

So far, I only understood the canonical matrix style representation (basically a linear combination over the data disks for each redundancy disk). Turns out that with polynomial representation you can create way better (read: faster) algorithms for error correction - according to my analysis, erasure and error recovery is O(N²), compared to O(N³) for erasure correction in the linear combination case, and unknown (presumably O(N³⋅M²)) in the error case (N: total number of disks, M: number of redundancy disks).

Thus I will rewrite the redundancy routines based on Phil Karn's Reed-Solomon implementation - the best implementation with an open license I could find. Most implementations (like in par2) don't bother with error correction, and use block-level checksums to detect errors. That done, erasure recovery can be used. Needless to say, this is no option for my block device (where and why should I store the checksums).

No need to say that this delays delivery timeframe of RAnsrID further; especially as I'd like to incorporate the change in an at least data preserving backwards compatible way.

Also Hackweek 6 wasn't as productive as I hoped; I only managed to get the test suite up and running. Oh well.

RAnsrID continued

emmes — Wed, 09 Mar 2011 10:56:58 GMT

Our group is now in HackWeek 6, quite a few weeks delayed after all other groups at SuSE. I will use the time to (finally!) continue work on RAnsrID - see also my initial blog entry. The project source is hosted on gitorious.

The basic redundancy routines are all working already, next is a usable test suite, then run-time configuration management (live adding and removing disks, live reconstruction w/o repair in the read error case).

I doubt I will reach a final version 1.0 I can recommend to use, but it will hopefully be close.

Forging knives!

emmes — Sat, 26 Feb 2011 18:00:49 GMT

	I have a spleen for rather - say - exotic weekend activities (remember the R8 tour?). This time, two friends of mine and I went close to the middle of nowhere to the local blacksmith in Hallerstein (his web page is German only), for a two days forging course .
	The event was fantastic, apart from some major problems with the local power supply (the whole village went dark three times), so we had to setup a mobile power generator in order to power the fan for the smith's hearth. It went well, apart from the starter breaking on the first attempt to start up the generator (it was brand new ), but we were able to improvise.
	After a lot of hammering (also involving a pneumatic hammer we used for pattern welding for our Damascus steel knifes), and hours of grinding and polishing, every one of us was the proud owner of two self-forged knives, one of monosteel and one of Damascus steel.

It was an amazing experience, but you definitely need the help of an experienced blacksmith like our Axel, in order to get good results even on the first forging attempt. I guess I'll do it again, in the future. Maybe I will come home with a fully sized Katana next time .

It's X.org election time!

emmes — Mon, 21 Feb 2011 14:33:48 GMT

As all members of X.org should have noted in the meantime, it's election time again! After some efforts we actually do have more candidates than seats for the board of directors .

Some community members have asked a (rather large) number of questions, I have consolidated the answers I received in this wiki page. So far only three candidates replied, so for me at least the top three candidates are clear - it's better to vote for persons that do have an opinion and voice it, than for persons who prefer to stay quiet .

So go to members.x.org and vote!

Restricting Linux kernel configure options to currently used set

emmes — Mon, 17 Jan 2011 16:43:58 GMT

git is great for bisecting regressions (or finding a fix in a series of commits) - but compiling the kernel can take ages, especially if you have to do it on an Atom, and with the configuration of your favorite distribution...

Now finally I created a perl script for reducing the default config to the set of modules that are currently actually loaded. Reduces kernel compilation times on a quad core machine from 56 minutes to 6 for a standard SLED kernel Guess it's even more difference on this !@#$% Atom...

Usage:

`# cd /var/tmp/linux-2.6`	or wherever your git tree is located
`# gunzip </proc/config.gz >.config`	to get the current configuration
`# make oldconfig`	to add new options for current kernel
`# ~/linux-adaptconfig.pl >.config.new`	to remove all not required options
`# mv .config.new .config`
`# make oldconfig`	to be on the save side...
`# make -j5`	build, motherbeep, build :-)

Yes, it's a hack. No, it's certainly not perfect. But it might be exactly what you had been waiting for. I waited long enough to actually write it myself...

emmes — Tue, 10 Aug 2010 17:43:48 GMT

There are a few frequency meter implementations available for Atmel's microcontroller series, but I haven't come across a reasonable reciprocal frequency counter implementation, let alone one without extra hardware.

Thus I created a software only reciprocal frequency counter running on an ATtiny2313 (ATmega not tested yet) with a usable frequency range of 0Hz..10MHz (when running at 20MHz), sub-Hz resolution, and 10ppm accuracy or better.

This requires 64bit arithmetics, for which the libgcc routines are prohibitively expensive on ATtiny. The 64bit routines in C and assembler I thus implemented for this project require much less space.

AVR usbtiny based ir-lcd-switch

emmes — Tue, 13 Jul 2010 21:49:32 GMT

Dick Streefland has created a software based USB protocol implementation called usbtiny for the AVR attiny microcontroller family. I have stripped down the code so that I was able to add detection of a single programmable IR signal. When the signal is detected, an output pin triggers a power button press for 250ms. That way e.g. media center PCs can be switched on remotely. All this is documented on the project page.

During this project I decided to revive my passing knowledge about board layouting and etching. For layouting I have used kicad, IMHO the first open source layouting software that is actually usable. The result looks pretty good, the 8/10 mil raster shows excellent sharpness and only very little undercut. Especially considering that the material and chemicals have been laying around here unused for - what? - 20 years...

LinuxTag slides

emmes — Sat, 12 Jun 2010 10:14:51 GMT

I've just uploaded the slides of my talk about RAnsrID on LinuxTag on my publications page.

As the documentation of RAnsrID is basically non-existent ATM, this is rather important for potential users...

RAnsrID - git repository published, demo on LinuxTag 2010

emmes — Tue, 08 Jun 2010 16:46:15 GMT

I have just published my RAnsrID git repository on gitorious.org. Beginning now I will stay backward compatible with old versions of journal and disk meta structure blocks. Get the git repo from
git clone git://gitorious.org/ransrid/ransrid.git

Unfortunately, there is little (read: no) documentation available yet; that will change after LinuxTag. Upto then the only doc is the heavily commented source code. Grab it, study it, enhance it, send a patch - that's the open source way.

For LinuxTag I have another goodie - I will be traveling with four USB disks and give a short live demo of what the system is already capable of. Live add and removal of disks isn't working yet, but reading, writing, validation, and rebuilding is.

Note that nbd used to freeze machines during writes if client and server were running on the same machine. Since kernel 2.6.26 there is a patch included that ought to fix this issue, but there were some (inconclusive?) discussions about this patch beforehand. Using xen for the client seems to work around this issue as well, though.

RAnsrID - Redundant Array of Non-Striped Really Independent Disks

emmes — Wed, 26 May 2010 23:53:10 GMT

In my spare time I've been working on a RAID-lookalike system for storing large amounts of data with multiple redundancies - and with significantly lower power consumption and disk spinning time than standard RAID if you only access single large files in a typical session.

The whole thing is implemented as a network block device (nbd), and will be presented (in an early, but at least already partially working state) on LinuxTag 2010 in Berlin.

Note that this is not a direct competitor to a standard RAID solution - in fact, I propose using a RAID 1 for the journal it needs (e.g. use the system disk - you're already using a RAID there, right?). For a comparison table check the project page.

Source will be available soon, I've not decided which git hoster to use yet. I don't think it's reasonable to put this on freedesktop, because is relation to freedesktop to close to nothing. I might change my mind, though .

Filming in 3D: The right choice

emmes — Wed, 17 Mar 2010 23:50:27 GMT

Now as I've seen a number of 3D movies and especially two partial real action films recently - Avatar and Alice in Wonderland - I perfectly understand Cameron's point of view:

If you can film in 3D with a stereo camera, do it! It's so much better than post-processed 3D. The 3D effect in Alice in Wonderland always felt a bit out of place. And I'm not talking about composition, but rather about the tiny depth differences in details you probably don't get exactly right when doing post processing. And Burton probably was more careful than others will be in what looks like studio-driven films.

Ok, acknowledged, the comparison is everything but fair. Avatar had a much higher budget, which shows. It created probably the single least intrusive 3D experience for me so far. For purely animated films 3D is an easier task, and there Bolt felt almost as good as Avatar, Up a bit worse, but still so much better than AiW.

Many films still fall in the old pit falls like trying to shock / "interest" the audience with cheap sticking-out-of-the-frame tricks (My Bloody Valentine as a very negative example). Which bores at best, but certainly draws you away from the film. If it's done just for fun at the beginning of the film like in Monsters vs. Aliens, all right, but please behave. In Avatar the 3D effect was never annoying, it just drew you into the film and let you forget that you're watching a 3D film. It just fit.

Ah, and before I forget it:
The single most important feature of movies filmed in 3D is not the 3D effect. It's the fact that due to 3D directors and camera men finally have to think of good camera paths and slow cutting pace again. No chance to create "dramatic" effects with wacky camera and half second cuts, you have to have actually good choreography in action scenes. Otherwise the audience will... I'll spare you the gory details

Note that I still believe that the film content is way more important than the style. Still, we're talking about moving pictures, they ought to be pretty...

X.org Board of Directors transparency

emmes — Thu, 25 Feb 2010 16:54:04 GMT

I had been nominated to candidate for X.org's Board of Directors this year (actually two years, because members are elected for a two years term each) - and was actually voted for and elected.

During this year's elections a number of questions came up about several issues, partly regarding the financial situation of the foundation, partly about how the board members communicate with each other and the regular members. It basically all boiled down to the number one perceived issue with the X.org board:

It's transparency. Or rather the lack thereof.

It's generally accepted, that even some of the actions required by the By-Laws (like meeting minutes) have been somewhat neglected. As a result of the discussions, Eric Anholt has now published the irclogs on members.x.org, thanks for that! Also the irc channel for the regular board meetings (#xf-bod on irc.oftc.net) has probably not been advertised enough since its opening to the public. It is also safe to assume that this hasn't been done by intention, but just by lack of time - the daily schedule of most open source people is extremely cluttered (geez, when did I last blog?!?).

I want to promise that I will try my very best to push for transparency as much as possible, maybe starting by taking/polishing minutes after the next (my first) irc meeting.

I'm quite exited about the days to come .
And that is a good thing, because I'm pretty sure it will be - say - a little bit less thrilling after a while... as with all good things .

radeonhd 1.3.0 released

emmes — Sat, 10 Oct 2009 14:47:09 GMT

It has been about half a year since the last release, but finally, over a hundred git commits later, we have version 1.3.0 of the radeonhd driver.

You may think that a release "cycle" of 6 months is... not that much. However, as most open source projects radeonhd is pretty much understaffed. Together with lots of additional work on Novell's side (which of course reduces the amount of time Egbert and I can spend on radeonhd) it took us a while to finally find some time for polishing. Because 2D acceleration is active by default now on (almost) all chipsets, we were seeing more regressions than usual.

Never mind, you're probably more interested about the new release. These are the main changes:

Added support for RV740, M92, M93, M97.

Added more support for HDMI audio, XVideo color spaces, backlight control.

Added support for power management.

2D acceleration (EXA) is enabled by default now, except on RV740.

Tons of bug fixes (AtomBIOS, Cursor, DDC, EXA, LUT, MC, Quirks, RandR).

For more read the Phoronix article, the announcement mail or the README of the driver.

More Powermanagement for radeonhd

emmes — Thu, 23 Jul 2009 17:53:56 GMT

I've added support for PowerPlayInfo_V4 (the one I reverse engineered lately) in radeonhd today - and a whole bunch of heuristic validation routines. Which means that the driver finally has some idea about the possible chip frequencies and voltages .
Determination of some of the values is still scary, and I don't know yet whether we will stumble over them - especially the minimum frequencies are sort-of guessed from the (known) minimum PLL output frequencies. But we need them, because some cards (e.g. one RV770 I have here) only have one known good memory clock configuration, while it can save tons of power if it is lowered (tested + measured, GDDR5 memory really uses a lot of power). Therefor, the values are checked for reasonable bounds, and rejected if they exceed. So if a future chip needs less than 500mV for operation, we will have to update these tests...

The current code has all these bits in place, but doesn't configure anything different than previous versions. First, a set of reasonable settings has to be determined, which will need additional heuristics (this is done in rhdPmSelectSettings(), which needs some love still). This selection also depends on how difficult it will be to change the engine and memory clock, and the VDDC voltage. So far we only set the engine clock, but code is already in place for the other two.
Before setting a clock, it must be made sure that the engines using this clock are idle - that's why we (ahem!) only set the engine clock once at the beginning so far:

For setting the engine clock, the engine must be idle (surprise).
For setting the memory clock, memory accesses must be prohibited. Which means that the screen will be blank during this phase. It remains to be seen whether the vertical blank is long enough to do this on the fly. Otherwise this means that we typically shouldn't change the memory clock during runtime. Things get messy when multiple screens are attached...
For setting the VDDC voltage, all engines must be idle. Also, certain combinations of engine and memory clock require certain VDDC voltages.

The amount of known good configurations is limited, and sometimes they are contradicting . Remains to be seen whether we can sort-of interpolate between good settings, because typically there are more voltage values available than used...

Later we will need an oracle for selecting the right power state according to the current usage pattern. It might be easier to do that in kernel space, but this remains to be seen.

That's it for today, I actually hoped to get more accomplished during our HackWeek. But reading out dynamic AtomBIOS tables can be... intriguingly complex.

PowerPlayInfo V4.1

emmes — Fri, 26 Jun 2009 13:05:17 GMT

I finally spent a few spare minutes (underestimation of the week) to sort-of reverse engineer the PowerPlayInfo tables of newer ATI cards - and somewhat succeeded. But the information I found so far is not as encouraging as I'd like it to be.
Basically, you get a list of potential combinations of engine clock, memory clock, and core voltage, plus a number of unknown flags. So far so good, but on some (especially high class) cards the entries do not vary as much as I'd like them to do, and many combinations do not exactly make sense. Others are repeated over and over.

Examples (engine clock in Mhz / memory clock in MHz / core voltage in Volt):

RV770: 750/900/1.263 - 500/950/1.263 - 750/950/1.263
RV670: 669/829/1.214 - 300/829/1.014 - 300/829/1.014 - 300/829/1.214
RV635: 725/800/1.250 - 110/405/0.900 - 300/405/1.000 - 300/800/1.250 - 600/500/1.150

IMHO the RV635 values are the most reasonable ones - while the RV770 values are completely bogus.

Also, the PowerPlayInfo V4.1 still has quite a number of fields we don't understand - marked as unknown in my AtomDis disassembler and table dumper.

How to NOT replace your HTPC

emmes — Sun, 21 Jun 2009 16:05:53 GMT

I wanted to reduce heat, noise, and power consumption, and improve user experience when watching video - in my opinion a home theater PC is probably the least enjoyable multimedia device. Especially as it typically never does exactly what you want it to do, so you spend half your time configuring and expanding it.
Finally, there is a neat BluRay player LG BD 370 that plays Matroska container as well, which is the de-facto standard for fansubbed Animes nowadays. And it is reasonably cheap (<200€).

So I bought one and stress-tested it this weekend. Long story short, I'm unsure yet whether I will return it to the store or not. Because it doesn't exactly play everything - and yet I still somewhat like it .

Positive things first:

Fast bootup - the system is ready in something like 10 seconds.
Good BluRay performance - I don't have too many BluRays yet, but the ones I tested worked decently. It is the fastest BluRay player I have seen so far - but I still hate the BluRay engineers for choosing java as the menu language.
Does play and upconvert DVDs.
Does do 1080p@24 (untested), no issues at all with HDCP handshake, even on output device change and resolution switching with a cheap 15m HDMI cable.
Very good user interface - I miss buttons for 10s instant forward/backward skipping, otherwise it's clean, neat, and easy to use.
Never crashed on the approx. 50 disks I tested.
Trivial and fast firmware update over ethernet.
YouTube client - about the most useless feature IMHO.
No decoding artifacts, unless it had warned you that this might be possible.
Very good and accurate format description.
Able to switch between >2 audio streams and subtitles on the fly.
Does play matroska, avi, mp4, mov, mpg containers without problems. I have a single avi that doesn't play, but it's probably broken.
Does play most(!) subtitles, including embedded ass and external srt files.
Does play ac3, dts, mp3, aac audio streams.
Does play most(!) h264, some(!)divx, all xvid video streams.

The last points already indicates the major issues:

Has a hard limit of 720x576 for DX50 fourcc - this is unbelievable ridiculous, as XVID works without limits, and both are actually the same format.
h264 is only supported upto level 4.1 - many fansubs use level 5.0 or higher, in order to use more reference frames. The player warns if the level is higher than 4.1, but if less then 9 reference frames are used at 720p (limit at level 4.1), it will play fine. Unfortunately, this isn't the case for half the fansubs I have.
Newlines in subtitles are rendered as '\n'. Luckily, they almost break lines early enough when they are too long (few characters missing).
Some subtitles aren't rendering, not sure why.
Doesn't play m2p, ogm containers.
Doesn't decode ogg vorbis.
As with all commercial players I know so far: Doesn't allow to fix A/V synchronization. I have a DVD with audio lagging 500ms behind video (Ghost in the Shell, early pressing), and one with one audio stream being too early, and one too late (Fucking Åmål). Fansubs sometimes lag audio by up to +/-300ms, dunno why.
There is a region-free patch for DVD, but only few tests of it can be found on the net. Don't know whether this works for all firmware versions, but somehow I doubt so.

Less important nitpicking:

Switches 50fps - 60fps all the time (system menus are running at 50fps only - probably European model issue only). With the long HDMI switching times this is getting on your nerves.
Doesn't use embedded fonts in ass subtitles.
Doesn't decode flac.
dts recoding would be a nice feature for aac audio, but doesn't work at all (tested on sp/dif only). Either I get pcm(!) two channel, or dts mono(!) without(!) sound.
Doesn't detect VCD and SVCD.
Does do 1080p@24 only on DVD and BluRay. Don't care too much, my projector doesn't accept 24fps, but is very good at inverse telecine. So I don't notice that.

I also noticed too late that the BD 370 doesn't only support no UPNP - but also no playback of files via SMB, NFS, or any other network means, just YouTube. Sigh. But well, the BD 390 will be available in Europe shortly as well, and that should include UPNP. Because of this I haven't even started to test audio file playback.

So I have a lot of issues with quite a number of disks I tested. And cannot use it neither for local network playback nor for Apple movie trailers. Still I'm unsure whether to return it or not, because the disks it plays it plays almost perfectly, with a nice user experience. At least I will have to keep my HTPC in addition to it for now.

Sigh.

Completely Off Topic

emmes — Tue, 09 Jun 2009 10:36:58 GMT

Sometimes you have to got a little nuts and free your mind (TM) by doing something extraordinary - for instance driving a super sportscar like the Audi R8 over the alps for 4 days, accelerating uphill, cutting corners. Fits perfectly with six-course gourmet menus and lots of wine in the evenings.

Guess what I just did.

I know that this is just asking for sarcastic comments, so what are you waiting for?

Now back to doing something useful like fixing bugs in OpenSUSE...

Barriers, barriers, barriers!

emmes — Wed, 25 Feb 2009 13:54:17 GMT

Yet another thing one should remember when programming r[67]xx: barriers.

The shaders allow for optimization to run multiple so-called clauses in parallel. There are ALU clauses, fetch clauses, and special single instructions e.g. for exporting data that are considered clauses as well. Thing is, if you do not explicitly tell the engine to stall for the results of a clause (by BARRIER(1)), it will happily run this clause concurrently to the last one. On all but the most basic ASICs (read: RV610 and M72 didn't show any issues).

Now this can create really weird side effect. Just imagine the following trivial vertex shader (some strange symbolic notation here):

CF_INST_VTX fetch clause: buffer id0 FLOAT_32_32 -> GPR0
EXPORT_POS export insn: GPR0 -> vertex position

It basically should just fetch the vertices and pass them unchanged.

However, if you forget the barrier at the EXPORT_POS statement, the chip will concurrently fetch a vertex position into GPR0 and export the current contents of GPR0 to the rasterizer. Which means that the rasterizer can get arbitrary input. In my very case I couldn't believe my eyes - each time I ran the test program I got a rendering with the vertices of the test 4 to 12 calls ago, depending on the actual chip! Turns out that the chip assigns the 128 (or whatever is configured) vertex shaders in a round-robin scheme to the individual vertices and keeps the contents of the registers per shader unit. After 5 or so turns I got - by accident! - a correct set of coordinates through to the rasterizer, only it was pretty old by then.,,

Set the barrier, and all this is of no issue.

Alex has seen similar things in the ALU clauses, in his case it was forgetting to set the LAST() bit as an end-of-vector-unit flag. On r6xx it worked fine, on r7xx it barfed.

More r6xx mysteries

emmes — Mon, 16 Feb 2009 16:20:07 GMT

I have used up half of my weekend to understand an issue with r6xx chips - when sending two draw commands on my laptop, I got system freezes, DRM oopses, and kernel panics - though the code was actually pretty simple.

It really took a long night (and approx. a hundred reboots) to find this:

When you want to

change VGT_INDX_OFFSET / VGT_MIN_VTX_INDX / VGT_MAX_VTX_INDX or
switch to a different shader

you have to re-set the Render target (CB_COLORx_BASE / CB_COLORx_SIZE / CB_COLORx_VIEW / CB_COLORx_INFO / CB_COLORx_TILE / CB_COLORx_FRAG / CB_COLORx_MASK, to be verified which actually influence anything), either before or after setting the registers for VGT or shaders.

Today in the office I found out that this is only necessary on my laptop's M72, on RV610, on RV630, and on RV635 - but not on RV670 or RV770. So this is chipset specific, but not VC releated...

What - as I assume - happens is that only a write to the render target registers stalls writing to the VGT and shader registers, so this seems to be some kind of flaw in the pipelining logic on some of the chips. As setting the render target again doesn't have a too big performance impact, I assume it's best to do it regardless of the chipset.

Fosdem talks

emmes — Mon, 09 Feb 2009 16:51:07 GMT

This year's Xorg DevRoom on Fosdem was a great success. We had a room with a capacity of approx. 150 people, and it was at least 60-80% full all the time.

I held two talks that were pretty crammed (actually, on the RandR 1.3 talk the room was completely full, and people weren't allowed to get in any more). The r600_demo talk was pretty technical, so of course it drew in a little less people.

If you hadn't had a chance to visit the talks, you can download the slides from my web page. And Phoronix will have videos of all talks.

RandR1.3: New Features in a Nutshell
Transformation, Panning, Properties
Slides Video
r600_demo: Programming the New GPU Generations from ADM
HowTo Render a Freaking Triangle
Slides Video