You are viewing tirdc

tirdc
04 June 2010 @ 08:38 am
This is totally unrelated to Radeon development, but I couldn't find a good guide for that.

I'm using a Laptop with an external TFT attached to it for my work. It works great using gnome-display-properties to setup the displays when I'm logged in. But it really lacks a "Apply for all users" setting. So it always bothered me that gdm was using mirror mode (or clone mode) for the login. That looks really awful. And since I'm not a big fan of hard coding display settings in my xorg.conf(.d) (and the external display is not connected all the time as this is a laptop) I came up with the following solution:

1.) Open /etc/gdm/Init/Default in your favorite editor

2.) Put the following code right before "/sbin/initctl -q emit login-session-start DISPLAY_MANAGER=gdm"


VGA1_PRESENT=`xrandr | grep "VGA1 connected"`
if [ "x${VGA1_PRESENT}x" != "xx" ]; then
xrandr --output LVDS1 --auto --pos 0x0 --primary
xrandr --output VGA1 --auto --right-of LVDS1
fi


3.) Restart X.org

There might be better solutions to this but I could not find any. I hope it helps other that face the same issue.
 
 
tirdc
02 June 2010 @ 01:01 am
Due to technical reasons (the logging daemon was not running) the IRC logs of the last two days are missing. I fixes that and now my favorite site is back online.

Now to the interesting part:

The r300g driver keeps moving forward thanks to Marek Olšák. He's picking up the work that Corbin Simpson started and implements more features and improves stability. He also started looking at the r600g driver started by Jermone Glisse (and others).

Jerome now work for Red Hat after he finished his academic studies. I'm not sure what he's doing exactly but the r600g was done in his free time.

Dave Airlie is doing a great job maintaining the DRM stuff in the kernel. The merge window for 2.6.35 is just over and he got plenty of good stuff pushed upstream. He's also doing experiments to do TFP in the software rasterizer.

Corbin is our 'information dispatcher'. Whenever a user pops up on IRC having a question or a weird problem Corbin is on the spot delivering information to users and gathering information from users.

And finally Alex Deucher is still at AMD/ATI helping out with information and documentation.

We also saw contributions from Maciej Cencora about 2 month ago regarding bugfixes in the class r300 driver.

(I'm sure I missed some people involved in this effort to bring free open source drivers for ATI/AMD Radeons to the world)

Generally speaking: The progress on this topic might be slow, but static. New features keep popping up, performance improvements are made from time to time. I completely dropped fglrx from my system some time ago and I'm using compiz on an old X1650 graphics card without any flaws.

Good job, guys! Thank you!
 
 
tirdc
01 October 2009 @ 11:14 pm
I could restore most parts of the frontend (major parts written in Javascript) from google cache so I proudly present the quick and dirty frontend to the dri-devel IRC logs. I'm currently investigating in using the logs from pq and jcristau from IRC to restore the most recent logs. A big "Thank you" goes to both of these guys. Another "Thank you" goes to krh who happily tested if the logging works and was the first to notice that is was back :-)
 
 
tirdc
01 October 2009 @ 08:53 am
As noted by Daniel Stone and Adam Jackson people.freedesktop.org went down due to power failures and therefore lost /home. Unfortunately this was the main hosting place for the dri-devel IRC logs. Unfortunately again, there are no backups. What does this mean?


  • All logs are gone (more than 2 years)

  • The PHP frontend is gone

  • The IRC logging tool is gone



I currently don't have the time or the will to set it up again so I'll add a redirect to the (IMO) completely crappy phoronix IRC logs.
 
 
tirdc
28 August 2009 @ 04:04 pm
A colleague recently asked me why I'm using commit messages that sound like commands or work orders (e.g. "Fix bug XYZ", "Replace method X by Y", etc.). I was wondering myself how I came to do that. So I started looking at http://cgit.freedesktop.org/ and pick several repositories. Among them mesa and glitz. All of these use this comment style. Next I looked up http://git.kernel.org/ and found that the repositories found there also use this commit message style.

Is this the normal way to express something you've done? I'm not a native speaker, but thinking about it I came to the conclusion that "Fixed bug XYZ" and "Replaced method X by Y" sound better to me.

Dear Interweb, what do you think?
 
 
tirdc
01 July 2009 @ 11:24 pm
(I know, this blog is supposed to hold news about radeon development, but I just read something really cool on IRC)

09:02 #dri-devel: < Weiss> awesome - first picture on the screen using KMS on my FreeRunner! :D

Yes, that's right. KMS is being worked on to run on the OpenMoko FreeRunner mobile devices. It's especially cool since I own such a thing :-D
 
 
tirdc
09 June 2009 @ 03:53 pm
Do I need to add something else? Yes? Ok. Corbin Simpson got to the point where you can run glxgears on top of a gallium accelerated mesa. He figured out what the actual issues were and pushed the changes to git a few hours ago. Good job, Corbin!

Next to that Dave Airlie will be looking into gallium, too. He's interested in porting over code (the fragment shader) form the radeon-rewrite branch of mesa to gallium to see if there are any performance improvements. Corbin objected though. He thinks that this part of code should be rewritten so that it could be maintained and extended. Currently nobody is working on it, so we'll see what the future brings.
 
 
tirdc
17 May 2009 @ 10:34 am
Once in a while I need my system to do software rendering and not using any hardware acceleration. A few years ago (before the age of AIGLX) we had a environment variable named LIBGL_ALWAYS_INDIRECT. But that does not disable hardware accelerated rendering. And since I'm forgetting the new variable to force software rendering every time I need it I'm going to explain both here.

LIBGL_ALWAYS_INDIRECT

This variable is used to force an application to always go the indirect rendering path. This means that the libGL (i.e. mesa) does not access the hardware directly but uses the X-servers GLX protocol for the access. The X-server will then use the hardware to render the request.

LIBGL_ALWAYS_SOFTWARE

This variable causes libGL to always use the swrast driver to render the frame in software. This will use no hardware acceleration (i.e. GPU acceleration) at all.

I hope I can finally remember it now :-)

edit:

Of course there is another important environment variable:

LIBGL_DRIVERS_PATH

This variable causes mesa to search in the given directory for DRI drivers. This is handy when doing development since you can have a working driver installed by default and test your driver without breaking your installation.

edit from Corbin Simpson:
Two more useful ones for Radeon people:

RADEON_SOFTPIPE, when set, forces the Gallium Radeon driver into softpipe mode. This makes it quite slow, but it won't ever misrender or die. It even runs glxgears well.

RADEON_NO_TCL for Gallium or R300_NO_TCL for classic r300, will disable HW TCL even if you're not on an IGP chipset. This is useful for testing shaders, and doubly useful on Gallium since HW TCL is very broken there.
 
 
tirdc
10 May 2009 @ 12:13 am
Corbin Simpson has been working on getting Gallium for Radeon into a more stable shape. Today he got the non-tcl code running more or less stable.


00:47 #dri-devel: < MostAwesomeDude> Okay, so with what I've just pushed, you can run glxgears with RADEON_NO_TCL for minutes upon minutes. Maybe even longer, didn't really try. Of course, it's still microgears.
00:47 #dri-devel: < MostAwesomeDude> But yeah. BO handling's pretty stable now.
 
 
tirdc
09 May 2009 @ 11:49 pm
I took the time to test drive Jerome Glisses KMS/TTM/CS code. From a first test it is solid and working fine. I haven't had a crash or lockup, so I'm pretty happy with the code. I don't have any performance issues that bug me. I use it for my every day usage at my private computer and I'm actually writing this entry while using it. So for me it's definitely ok for every day usage as long as you can accept a few issues:


As you can see in this picture there there seem some issues in the radeon-rewrite branch. I only could trigger this in blender.


I noticed a few rendering issues when looking web sites using epiphany that use background images for the body. Nothing worse because only the background looks weird while the content is looking normal.


Video scaling is broken. You only see the upper left quarter of the video. As you can see in this picture clipping caused by windows in front of the window cause an even more strange behaviour. The upper part seems to be working more or less fine. The rest is ... well, weird :-)

And last but not least:

glxgears is noticably slower ... but who cares? glxgears is not a benchmark. And ioquake3 bases games are running slower without me ever noticing it.

Respecting the changes done to radeon this is a rather short list of issues. Large central parts of the radeon driver at all levels have been rewritten. There is a new kernel module using TTM and providing KMS. You got a brand new command submission method used by the DDX and by mesa. You are using DRI2 and a rewritten radeon mesa driver. I must admit that I'm pretty impressed of the stability of such early code. Let's say thanks to Jerome Glisse, Dave Airlie, Nicolai Haehnle, Alex Deucher and who else was involved working on the radeon code. Thanks guys!