You are viewing tirdc

tirdc
24 August 2013 @ 03:53 pm
I'd like to announce an update for the dri-log Android app users, the mobile version the DRI IRC log. The app recently gained with a complete redesigned UI and now is in a really good state for everyday use. Feel free to test it, use it, grab the code (GPL-2) or report bugs and feature requests. It will work from Android 2.2 (Froyo) and later and should be good to use one phones and tables.

dri-log-App
 
 
 
tirdc
02 April 2012 @ 12:04 am
Until now Clover was developed in a separate git repository (and some forks on github as well). But today Francisco Jerez started preparing to add Clover to the mesa tree. Right now the work is happening in the 'gallium-compute' branch. Just a few hours ago the Clover state tracker was imported into that branch.

Right now one still needs a separate branch to use this state tracker, but it's a good sign that Colver is finally moving upstream (i.e. the mesa git repository). And there are also customizations to gallium to allow the AMD LLVM backend to be used. All in all: great achievement.
 
 
 
tirdc
29 March 2012 @ 08:02 pm
Did you ever wonder what is discussed between graphics hardware developers? If so, you might have found the IRC Logs. It is a handy and small web tool to read IRC logs of #dri-devel, #radeon and #nouveau. It is also open source (GPL-2) so you could easily host your own IRC log webpage.

But today everybody just loves to use Apps for everything, because Apps provide direct access to information you are interested in. That's why a DRI-log App was written. It is a free of charge Android App, supporting Android 2.2 and newer. But what can be done with it? It allows show the IRC log of selected users, so you can easily follow the latest communication regarding your favorite topics.

Feel free to test this App and give feedback!
 
 
 
tirdc
05 March 2012 @ 09:38 pm
Just a quick note about the great new of OpenCL running on R600+ hardware using open source drivers:

http://dummdida.blogspot.com/2012/03/they-did-it-smallish-opencl-example.html

It's great to see that the work done over the years is slowly but finally reaching the (almost) average user.
 
 
 
tirdc
As of now pretty much everyone has heard of systemd, the next generation init system for Linux. Next to the fact that if provides a really fast boot (on different systems tested approximately 50% of the original boot time) and a clean solution for dependencies of services it also offers the capability to write services in a very simple manner. So today we are going to write a simple service to set your power profile (as introduced last year). Note that you (obviously) need a systemd enabled system like Fedora 15.

First of all we need to know how to set set power profile. This requires three things: a fairly recent kernel, a Radeon graphics card that supports power modes on Linux and sysfs enabled in your kernel. A simple way to test this is to execute the following command:

test -f /sys/class/drm/card0/device/power_profile && echo "power_profile supported" || echo "power_profile NOT supported"

Note: This assumes that your Radeon card is the "first card" (i.e. "card0"). This might vary from system to system.

The will show you if the power modes are supported by your system. If your system is supported you need two files:

1.) The systemd service file in /etc/systemd/system/radeon-power_profile
[Unit]
Description=Radeon Power Profile

[Service]
Type=oneshot
ExecStart=/usr/local/sbin/radeon-power_profile low

[Install]
WantedBy=multi-user.target

2.) A small helper script to set the power mode in /usr/local/sbin/radeon-power_profile
#!/bin/sh

EXEC_NAME=`basename $0`;

TARGET="/sys/class/drm/card0/device/power_profile"
CURRENT_PROFILE=`cat ${TARGET}`

append_profile() {
        local PROFILE=$1
        echo -n "  ${PROFILE}"
        if [ "x${CURRENT_PROFILE}x" == "x${PROFILE}x" ]; then
                echo -n " (current)"
        fi
        echo
}

if [ $# != 1 ]; then
        echo "usage: ${EXEC_NAME} "
        echo
        echo "Valid profiles:"
        for AVAILABLE_PROFILE in low high default auto; do
                append_profile ${AVAILABLE_PROFILE}
        done
        exit 0
fi

PROFILE="$1"

if [ "x${PROFILE}x" == "xlowx" ] || [ "x${PROFILE}x" == "xhighx" ] || [ "x${PROFILE}x" == "xautox" ] || [ "x${PROFILE}x" == "xdefaultx" ]; then
        echo "${PROFILE}" > ${TARGET}
else
        logger "[${EXEC_NAME}] WARN: Invalid power_profile '${PROFILE}'"
        exit 1
fi

exit 0

Note: If your card is not "card0" you need to change the value of TARGET to the proper value.

After you create the scripts you should test if this works for you. The service is meant to set your power mode to low which is the best for mobile devices running on battery or to cool down your system. To test the service call:

/usr/local/sbin/radeon-power_profile

This will print out which profile is currently active ("default" in most cases). Now you can start the service

systemctl start radeon-power_profile.service

This will most likely cause a single flicker of the display (this might be a bug as it does not happen when GPU and memory clock changes happen on Microsoft Windows). After that a second call to /usr/local/sbin/radeon-power_profile should show your clock is now at "low". Verify that your system is running stable and smooth as before. Note: Setting the power mode to low will obviously cause your 3D rendering to be slower. If everything works as expected you can enable the service by default using

systemctl enable radeon-power_profile.service

Now your system will set the power mode during boot. On my systems it really extended the battery life time and my passive (fan-less) card went from 70°C to 45°C.
 
 
 
tirdc
11 March 2011 @ 09:36 pm
Marek Olšák has made some bug fixes to the libtxc_dxtn library (a library for mesa to allow S3TC). First of all you can download the updated version from http://people.freedesktop.org/~cbrill/libtxc_dxtn/libtxc_dxtn-1.0.0.tar.gz. Next to that the source code location changed (the code can be found at http://cgit.freedesktop.org/~mareko/libtxc_dxtn/). Marek also replaced the build system of the library by autotools, but this is not released yet.

A recent discussion about if this library should be added to mesa shows that this is not a desired option. This is because it would require the end user to recmpile the whole mesa instead of this single package.
 
 
 
tirdc
13 October 2010 @ 08:49 pm
Sadly the site http://homepage.hispeed.ch/rscheidegger/dri_experimental/s3tc_index.html is no longer available.

I got the latest release form my local archive and put it to http://people.freedesktop.org/~cbrill/libtxc_dxtn/libtxc_dxtn070518.tar.gz (md5sum 03beb907c13df6484cde210ce219f4b8) for anyone interested.

I also put a copy of the website to http://people.freedesktop.org/~cbrill/libtxc_dxtn and updated the links to point to the freedesktop DRI-pages instead of the abandoned sourceforge ones.
 
 
 
tirdc
26 August 2010 @ 11:35 am
Dave Airlie made a small commit changing the name of the R300 gallium driver from radeong to r300.

And what does that mean? It basically means that the classic r300 driver and the gallium based one share the same filename. So you can switch between the two drivers by simply replacing the one with the other.

This is really helpful for developers. And it might also be the first sign that the gallium based driver might become the default driver for r300.

Update:

From an anonymous comment:

It also means that you cannot easily package both drivers in rpm packages.
 
 
 
tirdc
22 August 2010 @ 02:27 pm
This is a totally radeon-unrelated rant:

<rant>

I decided to import some old photos into f-spot today to check for duplicates and organize them to folders corresponding to the date (i.e. yyyy/mm/dd). I assumed that f-spot would read the EXIF-metadata to extract the date (which is what it did before). After the import I was shocked to see that all images where put into 2001/01/01 ... which is totally wrong (the pictures dated 2005)! After looking at the images names (e.g. "01010008.jpg") I found out that the date was extracted from the filename (which is wrong as the camera does not name the images by date but by whatever else). I though: Ok, forget f-spot and let's use shotwell. Sadly shotwell imported the pictures into the same folders. I looked at the exif metadata of the images before and after the f-spot import ... before the date was correct, after the import the date was wrong.

f-spot replaced the exif timestamp by something that it assumed to be the correct timestamp. That's really evil.

Next to that f-spot was not able to import a large library (~10000 pictures) without using ~2.5GB RAM ... which caused my system to be swapping a lot (while still importing). This slowed down importing a single photo to ~5 seconds. Unusable.

I happily dropped f-spot and will never return. Shotwell performs much better (though it's still not as feature-rich). I'm happy to use a .NET/mono application less and I can only recommend that to you, too.

</rant>

Next to that Jerome Glisse and Dave Airlie keep rocking implementing r600g.
 
 
 
tirdc
15 June 2010 @ 09:37 am
Lately Marek Olšák has been focusing on r300g performance. He did a bunch of commits the last days that remove useless code and duplicated security checks. While doing so he also wrapped some debugging code to be enabled/disabled at compile time.

When a developer is focusing on performance this is generally a good sign, because it basically means that the groundwork is done.

On his way he also rewrote occlusion queries. The following commit line shows his intention:

This fixes flickering in Enemy Territory: Quake Wars. The driver now renders everything correctly in this game and the graphics is awesome.

I'll most likely grab myself a copy of the Enemy Territory: Quake Wars demo and test his latest achievements.