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.

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.

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

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.

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.

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
  
  

Given that testing textured triangle rendering (one texture only) isn't even scratching today's GPUs capabilities, I added another performance test, this time validating the ALU performance of the chips.

I actually got extremely close to the theoretical peak (and not higher), therefore I consider the values to be correct . Given the complexity of creating pixel shaders on the fly this is quite a bold statement, though...

Some numbers:

M72:     34.69 GigaFLOPS (Peak:  35.2 GigaFLOPS = 2 *  40 units * 440 MHz)
RV610:   41.46 GigaFLOPS (Peak:  42   GigaFLOPS = 2 *  40 units * 525 MHz)
RV670:  426.45 GigaFLOPS (Peak: 427   GigaFLOPS = 2 * 320 units * 668 MHz)
RV770: 1196.43 GigaFLOPS (Peak:   1.2 TeraFLOPS = 2 * 800 units * 750 MHz)

Gosh, I never thought a benchmark could get that close to marketing numbers...


If you want to test yourself:
Grab the latest r600_demo from git, and call

./r600_demo ctP

The performance test is 'P', clearing and drawing a triangle is just to have some image to copy so you actually see it working .

Remember that the first performance test is actually measuring memory performance, like described in my last blog entry. BTW, the GPU resets 'r' between most of the tests are no longer necessary, caches are flushed correctly now.

AMD has finally released the 3D register specs for R6xx! Actual programming information is yet to come, so stay tuned. Note however, that even the programming docu won't answer all your questions - you're probably better off playing with actually already usable code in r600_demo.

I've taken the opportunity to update r600_demo and included the register descriptions in the comments of the register file. That helps development enormously, especially when working with tags.

I also added a simple performance test, that will typically be started with

  r600_demo crtrP

(so you actually see something rendered). It measures the number of textured pixels we can get from the card. Note that this is relatively memory hogging, so the shader performance increase of modern cards won't show up as much as one would hope. Also, the performance very much depends on the exact texture size and scaling parameters. Increase/decrease RENDER_QUAD_{WIDTH,HEIGHT} in r600_perf.c, and you will see what I mean. Also note that the resulting numbers are still relatively low, because we don't do tiling yet. That will certainly be a major boost.


An RV610 gives me 316 textured Megapixels per second, while an RV770 with GDDR5 memory gives me 1619. Note though, that the RV770 is principally more than 5x as fast as an RV610, this test almost exclusively checks memory performance.

I have pushed the AtomBIOS disassembler and table dumper we have used during the development of radeonhd to a git repository on freedesktop.org:

• git://people.freedesktop.org/~mhopf/AtomDis

It has been enormously helpful in radeonhd development, especially in the early days. Its code has basically been derived by analyzing the AtomBIOS parser from AMD - which is public and part of the radeonhd driver for a long time now.

It can be used by anybody interested in the BIOS code. Remember that this is some sort of interpreted assembler-like language, which is CPU independent. The disassembler is not endian safe yet, though.

You need to link/copy the atombios.h from radeonhd/src/AtomBios/includes into the source directory, before you can actually compile it. Then you can dump disassembled command tables and annotated data tables from BIOS images. The BIOS image itself can be dumped from a card e.g. by running the rhd_conntest utility that is included in the radeonhd driver package.

I pushed our r6xx/r7xx bringup tool r600_demo yesterday very late in the evening, while Alex pushed the according DRM support. Of course, Phoronix posted a lengthy article about it directly after the push happened. Originally, I had planned to blog about it after dinner, but fell asleep after this exhausting day

Now this is only a developer's tool, but if you are interested in experimenting with your newly acquired freedom, the README describes what you have to do. I'll explain some parts of the inner working here - beware that this gets quite technical:


The register names and values have mostly been autogenerated from the to-be-released documentation, the result is the rather lengthy (188kb) r600_reg_auto_r6xx.h. Some additional registers had to be added by hand to r600_reg_r6xx.h, the hope is that we can eventually improve the documentation and parsing process, so that the need for manually added data is reduced. r600_reg_r7xx.h adds registers that are r7xx only, or changed from r6xx to r7xx. It's only 8k, which shows how close r6xx and r7xx are architecture wise.

r600_demo sends commands directly to the DRM by the same means that is actually reserved for the Xserver, so don't expect it to behave nicely if the Xserver has to draw anything while r600_demo is running. Best don't start any X11 client on the same screen where r600_demo will run on.

The rendering commands themselves are put together in a local buffer that is later submitted to the DRM. For convenience there is a set of macros + functions in r600_emit.h, that use the interface defined in r600_hwapi.h: E32(), EFLOAT(), PACK0(), PACK3(), which emit the 32bit integers, floats, Packet0 and Packet3 headers, respectively (see r5xx Docs, page 24ff, what the PacketX commands actually mean - this part is largely similar to r6xx, just some Packet3 command numbers changed). EREG() and EREGFLOAT() emit packets that set one register exactly, and are the most often used macros.

r600_init.c is probably the most interesting file - it contains code for initializing and setup of the most important subsystems; thus the file is probably a misnomer.

flush_cache() isn't really used ATM, because it turns out that Intel CPUs' memory writeback ordering is sufficient enough for caches to be flushed before the CP's registers are written - at least if there is a sequence point (e.g. function call) in between, otherwise the compiler might reorder. As the CP is written in the kernel only, this is trivially true.

What turned out to be really necessary is flushing the GPU's caches before reusing them, especially the input caches (shader, vertices, attributes, textures), except for the ring buffer which apparently isn't cached. So far we only have a all-or-nothing solution, called cp_set_surface_sync() in r600_lib.c. That has to get more fine granular. flush_gpu_input_cache() is supposed to do similar, but is untested and most probably wrong in its current form. We don't do the flushing in any but the EXA tests so far, so you typically have to reset the engine before each test (see the README).

r600_lib.c contains helper routines of which most you shouldn't notice at all - except for the GPU state output you get at the end of each r600_demo run. Please note that the GPU state flags aren't understood very well at this time, just that if a lot of the state flags light up, something has gone haywire. And there are tons of state flags...


Now if you want to experiment with new rendering approaches, best read r600_triangles.c for how to render triangles and how to push coordinates with different resolution (be aware that only a few combinations work, more about that in a later blog, but floats always work). In r600_texture.c you can learn how to setup and use a texture. And if you want to experiment with blending, you have to read r600_exa.c - but be aware that this is the freshest code of all

I have pushed the description of RandR 1.3 default properties into proto/randrproto's randrproto.txt. They are mostly for describing the outputs so that screen configuration tools can determine their types (e.g. is it DVI, VGA, or a laptop panel). SignalFormat and ConnectorType are considered mandatory for a driver to claim RandR 1.3 support.

A "reference" implementation of those properties (and of ConnectorNumber) is now available in the radeonhd driver. The more elaborate properties as SignalProperties, CompatibilityList, and CloneList are not yet present there, though.


On a typical card I currently get the following output of xrandr --prop:

Screen 0: minimum 320 x 200, current 1400 x 1050, maximum 1920 x 1080
TV_7PIN_DIN disconnected
        _PanningArea:
        _OutputNumber: 1 (0x00000001)
        ConnectorNumber: 1 (0x00000001)
        ConnectorType:  TV
        SignalFormat:   unknown
                supported: unknown
VGA_1 disconnected
        _PanningArea:
        _OutputNumber: 2 (0x00000002)
        ConnectorNumber: 2 (0x00000002)
        ConnectorType:  VGA
        SignalFormat:   VGA
                supported: VGA
DVI-I_1/digital disconnected
        _Coherent: 0 (0x00000000)       range:  (0,1)
        _PanningArea:
        _OutputNumber: 3 (0x00000003)
        ConnectorNumber: 3 (0x00000003)
        ConnectorType:  DVI-I
        SignalFormat:   TMDS
                supported: TMDS
DVI-I_1/analog connected 1400x1050+0+0 360mm x 270mm
        _PanningArea:
        _OutputNumber: 1 (0x00000001)
        ConnectorNumber: 3 (0x00000003)
        ConnectorType:  DVI-I
        SignalFormat:   VGA
                supported: VGA
   1400x1050      74.8*    60.0
   1280x1024      85.0     75.0     60.0
   1280x960       85.0     60.0
   1152x864       75.0
   1024x768       85.0     75.1     75.0     70.1     60.0
   832x624        74.6
   800x600        85.1     72.2     75.0     60.3     56.2
   640x480        85.0     75.0     72.8     72.8     75.0     66.7     60.0     59.9
   720x400        85.0
   640x400        85.1
   640x350        85.1

As the radeonhd driver separates the analog and digital parts of DVI-I connectors into separate RandR outputs, only a single SignalFormat is supported per output. For drivers that do not separate these, a DVI-I output will have TMDS and VGA as supported SignalFormats, and you will be able to switch between them by setting the SignalFormat property accordingly.


Going to our openSUSE 11.1 release party now. ^__^

I once wrote that we had RV770 working, but RV710 and RV730 didn't behave as they should.

Well, it was us who didn't behave. Alex noted that RV710 and 730 weren't recognized correctly by accident, and thus missing from a switch statement. Now as they are added they just fly.

3D, here we come!

I just pushed the last bits of RandR 1.3 based panning support. Panning was disabled with the introduction of RandR 1.2, because the old semantics didn't fit in multi-viewport configurations at all.

The new panning support is extremely flexible. You can specify (per output) the panning region, the mouse tracking region, and the panning borders. As pictures tell more than a thousand words, I'll show you some ASCII art (well, actually unicode art ;-)

┌──┳━━━━━━━━━━━━━━┳─────┬ ─ ─ ─ ─ ─ ┐
│  ┃     CRTC     ┃     │
│  ┃              ┃     │           │
│  ┃             X┃→    │
│  ┃              ┃     │           │  framebuffer
│  ┗━━━━━━━━━━━━━━┛     │
│                       │           │
│panning area           │
└───────────────────────┴ ─ ─ ─ ─ ─ ┘

The panning region defines the total area that should be partially visible on the screen. The displayed region will follow the pointer (pan) if you're moving the mouse past the CRTC's edges. In a single-headed environment that should always be the framebuffer, in a multi-headed environment you probably want to pan only a part of the framebuffer per head, as in this figure. Of course you can disable panning per axis.

┌────────┳━━━━━━━━━━━━━━┳ ─ ─ ─ ─ ─ ┐
│        ┃     CRTC     ┃
│        ┃              ┃           │
│        ┃              ┃
│        ┃              ┃           │  tracking area
│        ┗━━━━━━━━━━━━━━┫     X
│               ↓       │     ↓     │
│panning area           │
└───────────────────────┴ ─ ─ ─ ─ ─ ┘

The mouse tracking region defines for which part of the framebuffer the pointer position will update the panning region. You typically use the panning region or the total framebuffer size for that, depending on your taste. If set to the total screen size, the CRTC will pan in the remaining axis even if the pointer is outside the panning area on a different CRTC, as shown in the figure above. If the pointer is outside the tracking area, the CRTC will not pan.

┌──┳━━━━━━━━━━━━━━┳────────────┐
│  ┃     CRTC     ┃            │
│  ┃              ┃            │
│  ┃              ┃→           │
│  ┃           X←→┃            │
│  ┃       border_right        │
│  ┗━━━━━━━━━━━━━━┛            │
│                              │
│panning area                  │
└──────────────────────────────┘

If you specify borders, panning will start before you actually hit the edges of the viewport, as indicated in the figure. Very useful because you have some context where you will be scrolling to. If the borders are 0, the screen will pan when the pointer hits the CRTC borders (behavior of pre-RandR Xserver panning).


Panning support requires a driver update to be really useful (RandR 1.2 had no way of telling the driver that only the viewport changed). At the time of writing, only radeonhd has support for it, and only in git.

There are probably some rough edges, we just have to find and polish them.

While we're still waiting for the ip review process to be finished, we continue making progress on understanding and utilizing the hardware.

I'm documenting everything we find out, which didn't make it into the regular chipset documentation, and will publish this (probably on a wiki) as soon as we are allowed to.

Alex stumbled over some document, and found out that the bitfield for the command number of ALU instructions for R7xx was shifted by one freaking bit! No wonder that the engine didn't behave as anticipated for integer coordinates. With that knowledge we were able to update the macros and verify that the RV770 indeed works like the previous chipsets.

No luck on RV710 and RV730 so far, though.

I have started on a Mesa DRI driver now, together with two ATI engeneers, Cooper and RichardZ. Given the size and complexity of a DRI driver it will probably take a while until we have something to show.

Will we be faster than the IP review process? Who knows...

Finally some good news regarding DRI on R6xx:

As I've already written Alex had captured memory + register accesses from the in-house developer tools from ATI. With quite some effort we have reduced these more than 1.5 MBytes of C code to a very manageable size, with structures and models we do (mostly) understand.
There are a few undocumented or sparsely documented register accesses, but nothing worrying. Cache handling will need a bit of care (we haven't really done anything in that area), but that is one part of the chip that's documented very well. OTOH it's pretty complex .

Bottom line is we now have a fully stable programming model for the R6xx chips, the RV770 works as well (not the RV710 or RV730 yet, but we don't even have firmware for them yet), for basic functionality only, but including textures and shaders.
The chips' programming is actually quite beautiful - with a few exceptions. E.g. we do not understand how to send vertices reliably to the chip in any format except for floats, though the hardware engineers claim (undoubtedly they are right) that the integer formats should work as well. So we're still doing something wrong here.

It took so long to get to this point, because the chips are extremely picky - even while being actually beautiful and reasonable to program. Flip one bit the wrong way, and the whole engine goes haywire. And it goes haywire in subtly different ways on RV630 compared to RV620.
And (of course) the documentation is far from perfect, I'm writing down everything learned, so we hopefully never fall into the same pits again.

For now progress will slow down a bit again, because at openSUSE we getting close to RC1 of 11.1 - and that always means we need to fix bugs in other areas as well.

So Ian had some travel issues getting to the city of Angels, but I think I can easily top that...

First, our flight to L.A. was canceled due to engine issues. I wanted to fly from Berlin and staying with a friend there, who wanted to go to the Volume Graphics (which started on Sunday), so he would miss his first conference day - and I my acclimatization day.
We phoned the hotel (Vagabond Inn) that our flight was canceled and told them to withhold the reservation, which they accknowledged. Twice.
When we came to L.A. with 3h delay on the next day (we were 2h on the plane alone, waiting to get a timeslot to take off), of course our room was gone. F*ck.
We were driven to the second Vagabond Inn, which is an easy 30 minutes by cab from downtown, just to have anything this night. I phoned my travel company to reserve something near downtown, which they did, at the Dunes Inn Wilshire.
When we arrived we were told that there is no room available, they have no reservation, and that they don't work with this travel agency at all. F*uck!

We ended up at the UCLA university campus, at a hefty price tag of $147 (for a university guest room) per night, and 14 miles from downtown. At least the shuttle service goes here.

I hate L.A. Did I already mention that?

Yes, this is contradicting. In fact we should have seen glxgears run on r6xx or r7xx for one or two weeks now, but (as always) things didn't turn out as they should. Me having my little finger broken didn't exactly help either.

So I think it's time for a current status report, even though nothing is to be seen right now:


I've been working on a bringup tool named r600_demo, initially derived from r300_demo, but there's not much left from the old code. We need this to get a good understanding how the chips actually behave before getting into DRI, because r6xx and r7xx chips are so fundamentally different than r5xx when it comes to 3D programming. And it's never good to learn something new in a complex environment.

This appears to be a good idea, because the chip turned out to be extremely picky in some regards. CP (command processor), type3 packets, DMA, all works beautifully. So we're sure that the memory layout is fine as well. But we haven't seen a single triangle yet, and currently fail to understand why. Alex, RichardZ, and Wolke from ATI are analyzing the problem as well, so far no luck. I've added tons of status register analysis code, and yes, the chip is busy, but interpreting what those busy flags and their combination actually mean is definitely nontrivial.

Lately, Alex has verified that the in-house tools (TCore) are able to render triangles, and captured memory + register accesses. With this log he added a routine to r600_demo to program the chip in exactly the same way as indicated in the log. Guess what: no triangles.

And just to reduce work hours during this hot phase on this subject, I'm going to SigGraph today, and on vacation and another conference afterwards. So I won't be working on this for the next 4-5 weeks. :-(

The 3D documentation isn't available yet to the public either, because IP review apparently turned out to be much more complex then anticipated. Much to the annoyance for everybody involved, including explicitely those poor guys at ATI that have to review them.


Bottom line is: we will eventually get there, but even with ATI's great help it's more difficult than anticipated. The programming itself isn't that bad (though definitely much more complex than with r5xx), it's the tiny little details that bite you.

If the doctor is content with the situation the metal in my finger is removed today. Then I'll be able to type normally again, yippee! Ok, after some painful weeks stretching and strengthening the muscles... ;-)

Wish me luck.

There had been good news, and there had been pretty bad news for me on Friday.

The good news was that I had a great time on Rock im Park, a big (60.000 visitors, 3 days) rock festival here in Nuremberg. And Oomph!, which was the most important group for me, was f*cking great, never thought they would be that good live on stage.

The bad news was that on the way home on Friday night I had a serious bike accident. I had an open splintered fracture of the small finger of my right hand, and was hospitalized.

Luckily, all blood vessels are fine, the tendon is perfectly ok, and the nerve is untouched. Luckily and strangely, it doesn't really hurt at all, despite the 10cm gap in the flesh. Typing with one hand isn't exactly fun, though, especially when you're used two writing with 10 fingers...
And this will continue for 6 weeks minimum.

I'm now at my parents place, and won't be working regularly for the next two weeks. Which means that I won't be working as much on DRM/DRI in the next weeks as I hoped I would, but others like Dave Airlie will surely continue. So this means slowdown, but no retreat.

I just pushed DRI support to master for radeonhd. Yippie!

That said, direct rendering is turned of by default (Use Option "DRI" to enable), because currently it still disables all 2D acceleration support (including ShadowFB). We need full CP (command processor) support in the driver to be able to do both 2D and 3D acceleration.

Also, on x86_64 the list of provided visuals acts... weird. Dave Airlie verified that this doesn't happen any more on git master of the Xserver, at least with the radeon driver - no wonder, the visuals are provided by the DRI driver now, and not by some "fragile setup" in the GLX layer (read Xserver commit 7d74690536b if you're interested).

So this is on the TODO list:

• CP support, working together with 2D accel. Luc's working on CP already.
  
• Mipmap textures are broken (DRI driver)
  
• Texture upload after suspend to disk is partially broken
  
• Watermarks are not set correctly (missing docs)
  
• Movewindow support is missing (partially superfluous)

This is not tested well enough and needs verification:

• x86_64 working on Xserver git master
  
• R5xx cards
  
• AGP