Fedora 17 Alpha declared GOLD - Try the shell in qemu.

Robyn Bergeron announced: Fedora 17 Alpha release (RC4) was declared GOLD [Source].
This release ships Mesa with llvmpipe (and several other enhancements to allow software rendering), this way gnome-shell can actually be run in a non-accelerated graphics environment - like qemu is.

Just fetch - today or the 28th - an ISO of your flavor (live CDs come in GNOME, KDE, LXDE and XFCE) and run it with qemu:

$ sudo qemu-kvm -smp 2 -m 1024 -net user -net nic \
  -cdrom Fedora-17-Alpha-x86_64-Live-Desktop.iso

Sadly qemu's curl support is still broken, otherwise we could just run:

$ sudo qemu-kvm -smp 2 -m 1024 -net user -net nic \ 
  -cdrom "http://dl.fedoraproject.org/pub/alt/stage/\
17-Alpha.RC4/Live/x86_64/\
Fedora-17-Alpha-x86_64-Live-Desktop.iso"

Give spice a try - or: Smooth VNC.

Who doesn't know it: You are controlling your laptop via VNC, but all youtube videos scrolling through windows seems to be sluggish and parts of the window don't get updated - you see black patches everywhere.
Being in such a situation I wanted to try spice.

On Fedora 16 there is a spice Xserver where you can launch any program like you are used to do. So how does this help to improve the situation? Well, spice has an highly optimized protocol to deliver data from a server to a client e.g. it detectes videos played fast moving content on the server side, which are transmitted using mjpeg (AFAIK).
Anyhow, here we go (on the server side):

$ export CLIENT_ADDR=cut-n-paste
$ sudo yum install --enablerepo=updates-testing \
    xorg-x11-server-Xspice
$ sudo iptables -I INPUT -s $CLIENT_ADDR -j ACCEPT
$ Xspice --port 59007 --disable-ticketing :1.0 & 
$ { sleep 2 ; \
    export DISPLAY=:1.0 ; \
    metacity & \
    gnome-terminal ; }

This launches an Xspice server, listening on port 59007 and starts a metacity and gnome-terminal instance after 2 seconds within that server. The first line opens the appropriate ports.
Afterwards fetch spicec, the spice client (something like remmina, oh, has remmina already a spice plugin?) and connect it to the server:

$ export SERVER_ADDR=cut-n-paste
$ sudo yum install --enablerepo=updates-testing \
    spice-client
$ spicec -h $SERVER_ADDR -p 59007

A nice thing about spice is, that it's an xserver, so you can use xrandr to change the resolution at runtime. Nice.

$ xrand -s 1680x1050
$ firefox
# or, to connect to your original desktop via 
# VNC, but to transmit the desktop via spice 
# to your client. yey.
$ vncviewer localhost

Maybe this helps some lost soul to get a saner my-remote-desktop-over-a-network experience.
A last thing: Does someone know how to tell Fedora what X server to start on boot?

Linking OpenCL - Oh, wait ...

OpenCL is a nice way to utilize vector processors or multi cores.
But when it comes to writing and linking our software against a OpenCL it doesn't seem to open anymore. Because currently you need to link to one specific OpenCL implementatio, like AMD's or Intel's.
Okay, that might in the normal case not be to problematic, but as Fedora Packager I don't want to link some software to one specific implementation, if there are several.
This problem already appeared to the arch people and they just pulled the - so called - ICD loader out of one of the available implementations into the libCL package, to solve this problem.

ICD loader
So how does this help? ICD is a mechanism specified by Khronos to allow several OpenCL implementations to be installed side-by-side without disturbing each other. And the ICD loader allows to freely choose between one of the available ones (if it supports ICD), as the loader redirects the API calls to the choosen implementation.

What we need is some kind of just-an-ICD-loader which provides /lib64/libOpenCL.so which is the in turn using the actual implementation (e.g. pocl or the upcoming nouveau / clover [hopefully AMD to] thing).

There are already some open ICD implementations available, maybe those can be reused.

gst-plugins-cl - OpenCL plugins for gstreamer, written in Vala.

Some of you may know OpenCL - the open computing language. This language allows us to write kernels in a C99 dialect, which can be run on data - in parallel.
A common use case for such a language - and processing concept - is the classical convolution - which was my motivation. Sure, this can also be realized using the frequency domain, but - hey - I feel fine in the spatial one.

Anyhow, there are bindings for OpenCL - which is vendor (NVidia, AMD, Intel, F/LOSS, ...) and hardware (GPU vs. CPU - AMD, Intel, IBM Cell, ...) independent for many languages, including MatLab, python, C, C++  and so on ...
In my case I needed a way to apply some filter function (or [OpenCL] kernel) to a video stream from some FireWire camera.
The experienced reader might directly associate FireWire with gstreamer our multimedia framework of choice under linux.
I had the option to Gather the data from a gstreamer pipeline reading the FireWire camera or create a gstreamer element providing, as of wrapping, the OpenCL functionality. The mentioned plugin does the latter, it provides a couple of elements to apply some OpenCL kernel to the data of a gstreamer pipeline.

You need vala and some gstreamer sources to build this project:

$ sudo yum install gstreamer-devel vala

.. might be a good start.
You also need some OpenCL implementation, as of today pocl can be used, but it's just intensively tested with the Nvidia implementation of it's GPU SDK and with Intel OCL SDK.
Building the plugin is quite simple

$ ./autogen.sh
$ ./configure
$ make

Testing should also be quite easy:

$ export GST_PLUGIN_PATH=src/.libs/
$ gst-launch audiotestsrc ! clkernel ! autoaudiosink

This doesn't do much, as the default kernel just passes the data - but at least you can test if the OpenCL is available. There are currently three plugins:

• clkernel - An element to manipulate any buffer
• clkernel2d - An element to manipulate a 2D buffer, like an gray image/video
• clvideofilter - An element to manipulate an RGBA image/video

The OpenCL kernel can reside in an external file. You can pass the filename of that file and the kernel to use to the element:

$ gst-launch audiotestsrc \
  ! clkernel kernel-file=mykernellib.cl kernel-name=somekernel \
  ! autoaudiosink

Have a look at the sources or kernel.cl and kernel2.cl files (they are plaintext files, the kernel are build on the fly - heard of JIT?) in the src directory to see what kind of signature the kernel has to provide. (This should be documented more thoroughly).
If you've got more than one platform which is OpenCL capable you can use the platform-idx property to specify a specific platform.

This plugins should help to offload some functionality to one or more devices (like GPU, CPU and accelerator, like the CELL) and you don't need to care about the details.
This can now be used to do things like color conversion, all sorts of filtering, mixing and what else can be done in parallel.
Thos plugins are just a start, it would be nice to be able to provide more sinks which then can be used as an input to the kernels.

~ https://gitorious.org/valastuff/gst-plugins-cl