/Kretz/blog/

As I've seen some bug reports on this issue and no solution I thought I'd post mine:

Running Vista in qemu/kvm is mostly no problem. Except for user mode networking. Apparently Vista decides that it doesn't like the qemu DHCP server and ignores the IP it is assigned. Of course user net doesn't work then.

The simple solution is to give Vista a fixed IP, but which IP should you actually give it? There's only one that makes everything work right, and that is 10.0.2.15. Found this out by looking through the qemu code. If you don't use this IP then -redir won't work. And that was a major issue for me.

Hope it helps somebody.

Dear Lazyweb,

what is the best way to debug a problem with the session DBus apparently getting stuck? The KDE4 session on this computer becomes completely unresponsive. An ssh login still works but a simple

export DISPLAY=:0
qdbus

doesn't return. No output at all.

qdbus --system

still works. Running

strace qdbus

shows it waiting on a read on some pipe it created right after reading /var/lib/dbus/machine-id.

ps aux showed two session busses running. One from the user and another one from root. The root session bus was probably created by running Adept a few minutes before.

strace on the dbus process of the user showed it polling and calling gettimeofday, apparently at timeouts. Attaching gdb to the session bus didn't give me any information

Anyway, I don't know enough about dbus and I would like to get rid of this annoying hang. Whatever you try to do with the computer, in the end you have to fall back to SysRq + {S, U, B} since nothing else can get the system back. Any ideas how to get more information on what could be the cause?

When programming with SSE there are some cases where you need a double-quad vector filled with all 1s. E.g. for a simple bitwise not:

(This does a (~x & ~0) which of course is equal to ~x, the bitwise not we were looking for.) The bitwise not is necessary to implement some of the missing comparisons. SSE2 only has integer comparisons for ==, < and >. To implement !=, <= and >= you need a bitwise not.

So now that I motivated your need for a double quad with all 1s, where do you get it from? Well, easy, you say. Put a constant there. OK, it's 128 bits big, but what does that matter. And you're right, except if the constant is not in the L1 cache. Because then the load of the constant from L2 cache will introduce some unnecessary latency. So yes, it's a solution but not the nicest one.

Here's a better one. Remember that a comparison in SSE gives you a full double-quad. And if the comparison of the entries in the vector says they were all equal (for cmpeq, that is) you get a double-quad filled with 1s. Great... let's do it:

Works. Nice... except gcc warns about an uninitialized variable r being used. Looking at the generated code we see it added another xor instruction to initialize the register to 0. Ugh.

I can do better than two instructions. I want one! So inline assembly it is:

You'd expect that to work? I sure did. And sometimes it did. Sometimes it didn't. Huh? Guessing... put a __volatile__ there: Less failures. But not cured. So remove the __volatile__ again and objdump -d the binary while doing instruction steps in gdb in a split view in Konsole (nice feature there!). And what do I see. After cmpeqps was called on a register that register is all 0s! Why oh why? How can the same thing not be equal. So I look at the value of the register before the call: 4 NaNs (at least when interpreted as 4 floats). I slap my head, remember that NaNs are never equal to anything, and look for the integer comparison instruction.

The result:

Perfect. Now it works. I am able to do a bitwise not in two instructions (gcc is able to keep the xmm register around for another pandn, so this is also as good as it can get) and I don't have to worry about the cache at all.

Lesson learned: don't mess with floating point instructions when trying to do bit magic.

Short status update from me for all who still don't know:
I'm working on my diploma thesis this year. My day to day work is making the TPC Trackfinder software for the Alice detector of the LHC as fast as possible. (TPC Images) Target hardware is Multicore x86(_64) or GPUs. It's a challenging task, and I enjoy getting more experience in the HPC sector.

What I wanted to point everybody at, though, is that Intel has released the intrinsics it will be supporting with the Larrabee with the last gaming conference. What I didn't notice until today is that they also released a complete header that allows you to program with those intrinsics now. At home... The header provides a scalar and an SSE implementation of the full set of Larrabee intrinsics. Once the Larrabee and its development tools will be available your program will then run on LRB and be able to use the vector instructions in no time.

If you don't know why LRB vector instructions are so cool let me tell you: SSE is nice. You can do four floating point instructions in one (or int, or two doubles...). With LRB the vector width is four times bigger: 16 floats/ints, 8 doubles. But the LRB instructions are a lot nicer than SSE. You have a 16/8 bit mask available to select the entries of the vector the instruction should write. You have all arithmetic instructions for float, int and double available (SSE 4.1 finally brought the multiply instruction for int). You have gather/scatter instructions that make it easy to access data that is stored in structs. You have free conversions and swizzles in the loads and stores. (e.g. you can store data as half-floats and compute as floats, halfing the I/O bandwidth your code needs)

Now, intrinsics are already a lot nicer than writing inline assembly. But in the end you want to have a C++ class for this, right? If you do let me know.

Perhaps you remember such a discussion on core-devel quite some time ago. It resulted in a section on Techbase about the topic, with all the explanations why to do it that way. Too bad that the people who create the Microsoft Visual Studio stdlib headers haven't read it. This is too stupid...

I have a project at university where all the filenames start with a long prefix - and that prefix is the same for all the files. Tedious for opening files, even with auto-completion. So I 'ln -s'ed all the files to a filename without the prefix. This broke my build on Windows (the files are made available to a Windows running in VirtualBox, which is why I can use ln -s) as there now was a Math.h file in the directory. And guess what the MSVC compiler did... The <cmath> include has a

line which made MSVC include my Math.h file instead of the math.h file lying in the same directory as the cmath file. Just to prove my point I fixed the cmath file to use and now it compiles fine.

So if you write a library and don't know the difference between #include <...> and #include "..." look at that Techbase page again, so that your library won't waste somebodies time like Microsoft just did to me.

Last night we were at the Philipp Poisel gig in Schwetzingen. Great music and excellent musicians. It was great fun to listen and watch.

If you have a chance to see Philipp as he's doing the remaining gigs from his tour, don't miss it!

Last night was the first time I played our (my wife plays the guitar as well, actually I initially learned it from her) new guitar on stage. And for quite some time that night I could fall asleep because I was still too happy about the sound and ease of playing. So here's my full recommendation for the Yamaha CPX900. Before that I was playing a guitar from the mostly invisible korean company Phil. It sure was a good instrument, but the pickup system was bad - especially considering that this was a mini-Jumbo electroacoustic... The CPX900 is a normal sized Jumbo with a very good pickup system. With it, I now feel confident enough to play alone. Before I always felt the sound was too thin.

Oh, and the CPX900 in Mocha Black also just looks gorgeous.

On some KDE related news: while browsing the Yamaha store for a bit I saw a device that looks so much like a Zaurus - just different symbols on the outer buttons. And it's running Opie and the accompanying computer system (installed below the grand piano's keyboard) is supposed to be running a free and open system. Congrats to Yamaha to what I think are some really good choices there.

So, there's much interest in the Phonon + Quasar code - as I had hoped

To reproduce the result on your computer you need to get current phonon, current phonon-xine (with libxine >= 1.1.12) and current quasar from SVN. For those that don't know where Quasar lives, you can find it here: http://websvn.kde.org/trunk/playground/base/quasar/. To compile quasar you need to set the KDEDIR environment variable to the prefix where you installed phonon and then run qmake and make in the source dir. Then go to the examples/phonon subdir and run

./phonon /path/to/video.ogg

. With S and Shift-S you can change the edge detection threshold.

Have fun detecting edges in your videos ...

I've got it working a long time ago, but since this Akademy it is finally available in KDE trunk: Phonon now can give the raw video frames (as RGB, YV12 or YUY2) to an application and Quasar gained a node to upload those frames as textures and uses Shaders to convert YUV formats to RGB and then do arbitrary effects with them. The cool part about that, obviously, is that the data intensive calculations are happening on the graphics card (you need OpenGL 2 for this to work). To demonstrate the power of this I wrote a simple example that connects the PhononInputNode to an EdgeDetection node and then to a RenderNode. I did a screencapture of the result, but that looks a lot worse than the real performance, which is totally smooth and, of course, doesn't show much CPU usage.

You can also see me adjusting the threshold value of the edge detection filter with a keyboard shortcut.

Here's the code:

Things to note:

• the PhononInputNode is both a Phonon::MediaNode and a Quasar::Node
• the Quasar API is not final, especially wrt. PhononInputNode

As and there will surely be a few more people traveling the same way, I wanted to ask if there's interest in traveling together - or to share a car ride. I've already talked to Martin Gräßlin who lives in Mannheim (I'm in Heidelberg, in case you didn't know already), and we'd probably take a train together. Neither of us owns a car, but if you do and drive by Mannheim/Heidelberg (A5) and want company and people sharing the high fuel cost with you, let me know. If not, you still might want to try to meet up in the train... in that case also let me know.

For the train I'd probably take the ICE 610 (12:35 Mannheim - Köln) and ICE 14 (14:44 Köln - Bruxelles-Nord) on Fr, 8th, of course. But sharing a car ride would probably be cheaper.

Now back to exam preparations...