Drawing Open-Source Triangles On The ATI RV770

[phoronix]

Phoronix: Drawing Open-Source Triangles On The ATI RV770

On Monday AMD released the open-source R600/700 3D code to begin fostering the development of an open-source 3D driver for their newer ATI hardware while the related programming documentation still on the way. This code that's finally out in the public domain brings basic EXA acceleration and X-Video support, but on the 3D side there isn't any usable OpenGL support. It is expected that there will be a modest level of open-source 3D support for the ATI R600 and R700 series in the first half of 2008 for end-users, but for now there is just the DRM code and an r600_demo program. In this article we are taking a brief look at this r600_demo debugging utility on the RV770 hardware.

http://www.phoronix.com/vr.php?view=13331

[bridgman]

Whew, it worked :D

For a bit of history, I think this is the first triangle ever drawn on 6xx/7xx with "our own code", back in August :

http://pages.interlog.com/~johnb/ht/rv770_tri.jpg

Note the top of the triangle is missing; it took a few months to go from this point (where the code only worked on Alex's system and only with one specific card) to the point where it worked on most of our systems and all of the cards we had, then another month or so to get through final IP review and out the door.

[hdas]

omg, triangles - and that too open source, yummy :D. holy jesus christ. nope, nothing to take away, its just that i find it funny in the big picture (and to write an article about). its sure awesome to see a baby walking first time though (especially after watching it crawl for years, that too in the world of iron man who learns to run before walking ;)). keep up the good work .

and i am pleasantly surprised at the overwhelming response (close to 100 replies within a day!) at the article regarding amd/ati releasing r600/700 doc/code. just shows the amount of expectation (and frustration :p) ati users have.

would be very interesting now to see how some clean simple (native) and by-and-large full-featured code written from scratch works against a complex bloated (essentially ported?) ultra-featured (including a awesome watermark) fglrx. personally, i am sure david will beat goliath :D.

[sabriah]

It always begins with triangles!

At http://www.fresco.org/screenshots.html, check out the screenshot from 1999-12-13!

Way to go!

:)

[Kano]

Unbelievable, now create some circles ;)

[d2kx]

Unbelievable, now create some circles ;)

Amazing what modern GPUs can do, isn't it :)

Hopefully basic OpenGL support arrives early Q2.

[yoshi314]

Drawing Open-Source Trianglesyeah, i'd hate to see any "proprietary triangles" on my box ;-)

i just hope triangles don't get patented, ever :]

[RealNC]

Microsoft invented triangles, but they're nice enough folks and don't sue people using them.

[Markus]

[...] It is expected that there will be a modest level of open-source 3D support for the ATI R600 and R700 series in the first half of 2008 for end-users, [...]

Either they're running very late, or it's scheduled for 2009? :D

[bugmenot]

Is it supposed to work on RS780 chips, yet? And are bug reports welcome already or do they make no sense in this early state? And where to file the bug reports?

Thanks!

[mshopf]

Is it supposed to work on RS780 chips, yet?
Frankly said, nobody tested it on notebook chips so far. The DRM at least has microcode for RS780, I just verified.

You can try to run r600_demo, but you will have to add your pci ID in r600_demo.c - it's easy to spot where. I assume an RS780 is closest to an RV610 or so. Technically, it comes after an RV635, but it probably doesn't have vertex caches, like an RV610.

And are bug reports welcome already or do they make no sense in this early state? And where to file the bug reports?
Basically, bug reports are always welcome ;)
Currently there is no list for r600_demo, there probably will never be one. Best chances are on dri-devel, or on the radeonhd list.

[DanL]

i just hope triangles don't get patented, ever :]
LOL, sounds like something Rambus or Creative would do if they were in the graphics biz. DEATH TO PATENT TROLLS.

[bridgman]

Before coming to ATI I was actually visited by a team of lawyers demanding royalty payments for the use of "their IP", which was XOR-ing a cursor image onto the screen. At the time I ran a small company designing & building graphics cards and accelerators for other companies selling Mac upgrades.

We told them to get lost and never heard from them again, but I never liked software patents after that experience.

[bugmenot]

Frankly said, nobody tested it on notebook chips so far. The DRM at least has microcode for RS780, I just verified.

You can try to run r600_demo, but you will have to add your pci ID in r600_demo.c - it's easy to spot where. I assume an RS780 is closest to an RV610 or so. Technically, it comes after an RV635, but it probably doesn't have vertex caches, like an RV610.
Currently there is no list for r600_demo, there probably will never be one. Best chances are on dri-devel, or on the radeonhd list.
Hello, thanks for the answer.
I added the pci ID of my card, now it is not an untested chip anymore, but it still does not work.
I installed the R600/700 branches of radeonhd and drm and there are not errors in the xorg.0.log, drm seems to load successful. I assume that there is something with the DRM not ready for my card yet. Also the xserver freezes within 2-20 seconds if I start x with exa enabled. I can move the mouse then, but nothing else. I think DRM is not ready for my device, yet.

Here is the Xorg.0.log of the try to log in with exa enabled: http://pastebin.ca/1297086

...and the try with r600_demo:
http://pastebin.ca/1297156

Thanks for your hard work! I'm looking forward to paint my personal triangle :D

[DanL]

I'm a git n00b. How does one get the r6xx-r7xx-support branch? I have a spare distro and I'd like to play around with it. I tried
git checkout -b r6xx-r7xx-support
but I don't see any r6xx source files.

[TechMage89]

You don't typically use checkout with git to get the source. What you ususally want to do is clone the branch. Are you trying to get the radeonhd branch?

[DanL]

NVM: I figured it out. I needed to create a local tracking branch, switch to it, and then fetch and pull.

Thanks again.

[TechMage89]

Uh... I can't remember how to extract a branch from the trunk, so I would recommend just cloning the branch.
Oh, OK. Hope you can help with the driver!

[DanL]

Uh... I can't remember how to extract a branch from the trunk, so I would recommend just cloning the branch.
It wasn't immediately clear to me how to clone a remote (and non-master) branch. If I did this wrong, please share the correct way. Here's what I did:
git checkout -b <CHOOSE_A_NAME_FOR_LOCAL_BRANCH> origin/r6xx-r7xx-support
git fetch
git pull

I then noted that the r600 files were now in the src directory and proceeded to build as usual. (autogen.sh, make, make install).

I added options for DRI and EXA into my xorg.conf. I rebooted and the X server wouldn't start. Here's the log:
http://pastebin.com/m4477c619

I'm using Ubuntu 9.04 (Jaunty), which has a 2.6.28 kernel, Mesa from a git snapshot on 12/09, and Xserver 1.5.99.3.

[bridgman]

The new code seems to crash if DRI is not available -- either because the "DRI" option is not enabled in the xorg conf, or because the proper drm module was not available.

In your case you had <Option "DRI"> in the conf properly but drm did not open -- did you build and install the drm kernel module from the 6xx-7xx branch of mesa/drm ?

[DanL]

did you build and install the drm kernel module from the 6xx-7xx branch of mesa/drm ?
Well, I did now (thanks). I checked out that branch, built mesa/drm, built mesa from git source, and finally rebuilt radeonhd (with its r6xx.. branch) from source. NO JOY, I still get an empty /dev/dri directory. Do I have to build the entire X server from source?

bugmenot, would you care to describe how you got to the point you did?

[DanL]

Sigh...
So I found that the drm.ko kernel module I built isn't loading properly. It might have something to do with drm being built statically into stock 2.6.28 kernels:
http://radeonhd.org/?page=archive_display&c=radeonhd&m=12&y=2008&d=2008-12-16

I guess I'm going to configure/build a vanilla 2.6.28 kernel. Will report back.

[mshopf]

Hello, thanks for the answer.
I added the pci ID of my card, now it is not an untested chip anymore, but it still does not work.
I installed the R600/700 branches of radeonhd and drm and there are not errors in the xorg.0.log, drm seems to load successful. I assume that there is something with the DRM not ready for my card yet. Also the xserver freezes within 2-20 seconds if I start x with exa enabled. I can move the mouse then, but nothing else. I think DRM is not ready for my device, yet.
Thanks for testing!

You might want to try and load drm explicitly before starting the Xserver with 'modprobe drm debug=1; modprobe radeon' and verify /var/log/messages. This won't help you, but it might help us with debugging :D

[mshopf]

Do I have to build the entire X server from source?


Definitely not!

[bugmenot]

You might want to try and load drm explicitly before starting the Xserver with 'modprobe drm debug=1; modprobe radeon' and verify /var/log/messages
Here we go:

The output of 'messages' and 'syslog' when loading the modules with DEBUG=1:
http://pastebin.ca/1300075

And the output of 'syslog' when doing some testing with r600_demo:
http://pastebin.ca/1300076

If there is anything I can do, just say it. :)
Thanks!

[bugmenot]

Sigh...
So I found that the drm.ko kernel module I built isn't loading properly. It might have something to do with drm being built statically into stock 2.6.28 kernels
I renamed the original radeon.ko files and so on and copied the new compiled modules into the folder, where the original files were. But that is pretty 'unclean' I think, so I do it as described here now:
http://www.x.org/wiki/radeonhd:DRI

Good luck!

[DanL]

-I rolled my own 2.6.28 kernel this morning (from the Ubuntu 9.04 kernel source) and configured it without drm built-in.
-I then proceeded according to that same link bugmenot did (http://www.x.org/wiki/radeonhd:DRI)
-I completely rebuilt mesa/drm, mesa, and radeonhd against the new kernel headers (checked out the r6xx-r7xx-support branches of drm and radeonhd)

At least the drm.ko I built loads now. Unfortunately, X/gdm locks up hard when I load it (can't even Ctrl+Alt+F1). I tried just doing startx and bypassing gdm, but it still throttles the CPU and locks up.

Jan 5 07:46:12 somehost kernel: [ 18.799983] [drm] Initialized drm 1.1.0 20060810
Jan 5 07:46:12 somehost kernel: [ 18.857825] pci 0000:01:05.0: BAR 0: can't reserve mem region [0xd0000000-0xdfffffff]
Jan 5 07:46:12 somehost kernel: [ 18.858749] pci 0000:01:05.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18
Jan 5 07:46:12 somehost kernel: [ 18.858757] pci 0000:01:05.0: setting latency timer to 64
Jan 5 07:46:12 somehost kernel: [ 18.858986] [drm] Initialized radeon 1.29.0 20080613 on minor 0
Jan 5 07:46:12 somehost kernel: [ 18.859094] [drm] Used old pci detect: framebuffer loaded
Jan 5 07:46:13 somehost kernel: [ 18.982927] [drm] Setting GART location based on new memory map
Jan 5 07:46:13 somehost kernel: [ 18.982936] [drm:r600_do_init_cp] *ERROR* Need gart offset from userspace
Jan 5 07:46:13 somehost kernel: [ 18.998321] [drm] Loading RS780 CP Microcode
Jan 5 07:46:13 somehost kernel: [ 18.999346] [drm] Loading RS780 PFP Microcode
Jan 5 07:46:13 somehost kernel: [ 19.014507] [drm] Resetting GPU
Jan 5 07:46:13 somehost kernel: [ 19.014566] [drm] writeback test succeeded in 1 usecs
Jan 5 07:46:13 somehost kernel: [ 19.332859] [drm] dwords:3632
Jan 5 07:46:13 somehost kernel: [ 19.332864] [drm] offset 0xe0222000
Jan 5 07:46:14 somehost kernel: [ 20.531390] [drm] dwords:3632
Jan 5 07:46:14 somehost kernel: [ 20.531395] [drm] offset 0xe0232000

[gururise]

Before coming to ATI I was actually visited by a team of lawyers demanding royalty payments for the use of "their IP", which was XOR-ing a cursor image onto the screen. At the time I ran a small company designing & building graphics cards and accelerators for other companies selling Mac upgrades.

We told them to get lost and never heard from them again, but I never liked software patents after that experience.

Bridgman, count yourself lucky! That was probably the same patent that brought about the demise/downfall of the once mighty Commodore Amiga.

From: Wikipedia Article on the Commodore CD32 (http://en.wikipedia.org/wiki/Amiga_CD32)
The CD32 was released in Canada and was planned for release in the United States. However, a deadline was reached for Commodore to pay a patent royalty to Cad Track for their use of their XOR patent. [1] A federal judge ordered an injunction against Commodore preventing them from importing anything into the United States. Commodore had built up CD32 inventory in their Philippine manufacturing facility for the United States launch, but, being unable to sell the consoles, they remained in the Philippines until the debts owed to the owners of the facility were settled. Commodore declared bankruptcy shortly afterwards, and the CD32 was never officially sold in the United States.

[bridgman]

At least the drm.ko I built loads now. Unfortunately, X/gdm locks up hard when I load it (can't even Ctrl+Alt+F1). I tried just doing startx and bypassing gdm, but it still throttles the CPU and locks up.

There seems to be a problem with the 780 -- all the testing before release was done on discrete GPUs. The devs are going to look at the 780 this week.

[bugmenot]

The devs are going to look at the 780 this week.
Great! Nice to hear that. Thanks! :)

[agd5f]

RS780 is now working, I've just pushed the fixes.

[mshopf]

RS780 is now working, I've just pushed the fixes.

For those who want to test - the fix is in radeonhd (RS780 wasn't detected as an PCIE device), so you have to fetch the git head.

[bugmenot]

Great!
I tested it and were able to draw triangles :D

But: I cannot do anything else, iirc everything with the CP fails (invalid argument and so on are still there, see last log)

And if I try to use exa it seems to work somehow. I can log in into gnome, but if I type something in somewhere, the letters are not drawn fine. And everywhere is a bit graphics corruption from time to time. Also scrolling is very slow, much slower than with the default, but faster than "noaccel". And if I move a window then both cores are used at 100% and if I move on, the computer crashes, I have to turn it off. I cannot enable/disable num lock any more and moving the mouse is working, but mouse pointer flickers somehow.

What shall I do?

Triangles are great anyway, though :D

[mshopf]

Great!
But: I cannot do anything else, iirc everything with the CP fails (invalid argument and so on are still there, see last log)

Not exactly. Drawing triangles already uses the CP :p

The EXA behavior is to be expected. It's not working completely yet.

[bridgman]

Yep. Right now the EXA code is moving one line at a time and (I believe) flushing the GPU pipe and caches after every line when copying overlapping areas, which is really slow (dragging and scrolling both involve copying overlapping src/dst areas). As bugmenot said, it's faster than no acceleration but not as fast as shadowfb. That shouldn't be hard to optimize, but right now we're trying to make sure all the programming information is available and solid before getting into driver optimization.

I'm not sure if we were still expecting corruption, will check with agd5f re: whether corruption reports are useful.

[agd5f]

There is corruption with the EXA composite (which is currently enabled) and occasionally with overlapping blits (I think due to cache flushing issues). At the moment if you want relatively fast and corruption free, disable EXA composite (Option "NoEXAComposite" IIRC) and enable a composite manager (e.g., xcompmgr -a).

Also as to Xv, the current shader is for nv12 formats, other planar formats should be easy (just changes to the swizzles of the incoming components in the texture setup). Currently, you only get a gradient rather than an image.

[bugmenot]

Hello,
I tried that, but the computer crashed again. It also crashes, if I only restart the xserver. Have always to take the pc the power away, I'm afraid this isn't good for my computer, if I do this too often.

Any way I can help to debug?
Thanks!

[monraaf]

I also get some ugly fonts and the server also locks up after a short time on my 780G with exa-acceleration. If I run X with just an xterm an no desktop and window manager it's more stable and even mplayer with Xv output does work! Xaa acceleration seems stable, but I get motion sick scrolling a web page and the Xv port is gone.

Looking at the Xorg log file from a locked up X session with exa-acceleration it gets spammed with a lot of:

[mi] EQ overflowing. The server is probably stuck in an infinite loop.
[mi] mieqEnequeue: out-of-order valuator event; dropping.

[agd5f]

Xaa acceleration seems stable

There is no XAA acceleration. It's falling back to shadowfb or none.

[monraaf]

There is no XAA acceleration. It's falling back to shadowfb or none.

Ok, It's still documented in the radeonhd(4) man page as an option however but maybe that's for the older cards.

[bridgman]

It is definitely an option, and it is supported on older GPUs with a dedicated 2D acceleration block, we just didn't write any R600 code for that option ;)

The 3D engine is not a particularly good match for the common XAA functions, and modern apps seem to make more use of the operations offered by EXA. Since we already use the 3D engine for most of the EXA functions, and since 6xx/7xx only have a 3D engine, we only implemented EXA and not XAA for those GPU generations. There was some discussion about whether we should implement XAA later, but I don't know what the right answer is there.

Alex mentioned that turning off Composite (Option "NoEXAComposite" in the Device section of your conf file) frequently eliminated the corruption.

monraaf, could you try that option if you have not already done so ?

[monraaf]

Alex mentioned that turning off Composite (Option "NoEXAComposite" in the Device section of your conf file) frequently eliminated the corruption.

monraaf, could you try that option if you have not already done so ?

Ok with:

Option "EXANoComposite" "true"


I get normal readable fonts, however on some places there are lines above them. Adding this option gets rid of these lines.


Option "MigrationHeuristic" "greedy"


And it looks like the X server is stable now.

[bridgman]

Great. It's possible that the MigrationHeuristic option is completely disabling acceleration, but I'm not sure about the current code. Do you see a big performance drop when you set it to "greedy" ?

[monraaf]

Whoops, I spoke to soon. I just had another lock-up, well It's not completely stable yet but definitively more stable. One guaranteed way to lock-up the system seems to play a movie with mplayer (Xv output) and then enter and leave full screen mode.

Regarding the MigrationHeuristic option I don't see any performance differences.

[bridgman]

Regarding the MigrationHeuristic option I don't see any performance differences.

Interesting; so the option is affecting stability but not totally disabling acceleration. That's probably useful -- thanks !

[DanL]

So I found that the drm.ko kernel module I built isn't loading properly. It might have something to do with drm being built statically into stock 2.6.28 kernels:

Just an update for those using Ubuntu Jaunty's stock kernel. This bug was fixed for both i386 and amd64 kernels in a recent update: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/312721

There was also an X server update for Jaunty today (1.5.99.3 -> 1.5.99.901). I'm going to rebuild DRM, Mesa, and radeonhd and see if anything's improved for the RS780. Will report back.

[DanL]

The updated X server didn't help :\
The system still locks up if I move a simple terminal window around too much, even with the EXANoComposite and MigrationHeuristics options. (I also have AIGLX and the composite extension disabled)
/var/log/messages shows:
Jan 19 20:54:39 somehost kernel: [ 23.908796] [drm] Initialized drm 1.1.0 20060810
Jan 19 20:54:39 somehost kernel: [ 23.955318] pci 0000:01:05.0: BAR 0: can't reserve mem region [0xd0000000-0xdfffffff]
Jan 19 20:54:39 somehost kernel: [ 23.956215] pci 0000:01:05.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18
Jan 19 20:54:39 somehost kernel: [ 23.956429] [drm] Initialized radeon 1.29.0 20080613 on minor 0
Jan 19 20:54:39 somehost kernel: [ 23.956536] [drm] Used old pci detect: framebuffer loaded
Jan 19 20:54:39 somehost kernel: [ 24.151804] [drm] Setting GART location based on new memory map
Jan 19 20:54:39 somehost kernel: [ 24.167188] [drm] Loading RS780 CP Microcode
Jan 19 20:54:39 somehost kernel: [ 24.168187] [drm] Loading RS780 PFP Microcode
Jan 19 20:54:39 somehost kernel: [ 24.183350] [drm] Resetting GPU
Jan 19 20:54:39 somehost kernel: [ 24.183408] [drm] writeback test succeeded in 1 usecs
Jan 19 20:54:40 somehost kernel: [ 24.476944] [drm] dwords:3632
Jan 19 20:54:40 somehost kernel: [ 24.476950] [drm] offset 0xe0222000
And drm just goes on and on generating the last two messages with different numbers every few seconds. Xorg.log doesn't have anything out of the ordinary in it.
If I can do anything else to generate a more useful "bug report", let me know.

[bridgman]

Just to be sure, is it only the "dwords" and "offset" messages which are repeating ?

[DanL]

Just to be sure, is it only the "dwords" and "offset" messages which are repeating ?
Yes, although occassionally strange "garbage" shows up
Jan 19 20:55:26 somehost kernel: [ 70.496037] [drm] offset 0xe0272000
Jan 19 20:55:26 somehost kernel: [ 70.496092] [drm] dwords:3648
Jan 19 20:55:26 somehost kernel: [ 70.496044444444444 444444444444444 444444444444444455555 5505555555 5555 5555 555555555555555555555555555555550504816] [drm] offset 0xe0372000
Jan 19 20:55:26 somehost kernel: [ 70.504870] [drm] dwords:3648
Jan 19 20:55:26 somehost kernel: [ 70.504872] [drm] offset 0xe0382000
Jan 19 20:55:26 somehost kernel: [ 70.504928] [drm] 55555 55555555 555555555555555555507555555555085555 5555555 555555555555555555555555 5555 555555555555555555555 5555555555555555555515555555555555 555555555555555555555555555555555555555555 555555555555 5555555555555555555555555555255555555555 5555 5555 555555555 555555 555555555 5 55555555555555555555555555555555555555 5555 553555 5555 5555553536901] [drm] offset 0xe0252000
Jan 19 20:55:26 somehost kernel: [ 70.536955] [drm] dwords:3648
Jan 19 20:55:26 somehost kernel: [ 70.536958] [drm] offset 0xe0262000
Jan 19 20:55:26 somehost kernel: [ 70.537012] [drm] dwords:3648
Jan 19 20:55:26 somehost kernel: [ 5555555555555 555555555555555555555 55555555 555555555415555555555555555 555555555555555555555555555555555555 5555555555555555555555 55555555555555555555555555555 55555555555555555555555555555 55555 555555 555 55555555555555555555555555555555555555555 56555555555555555555555555555555 55555555555555555555555555 5555555 5555 555555 5555555 5575321] [drm] offset 0xe0342000
Jan 19 20:55:26 somehost kernel: [ 70.575377] [drm] dwords:3648
Jan 19 20:55:26 somehost kernel: [ 70.575379] [drm] offset 0xe0352000
Jan 19 20:55:26 somehost kernel: [ 70.5754345557565555555555555555 55555555555555555555555555 5555 55555555555555555555555555555555555555 555555585555555555555555555555555555 55555555555 5555 5555 5 555555555555555555 5555555555555 55555555 555555555555556666666666666 6666666666666066 66666666666666666 66666 66666666666 666666666666666606 66666666666666666666666616666 6666 66661613109] [drm] offset 0xe0242000
Jan 19 20:55:26 somehost kernel: [ 70.613190] [drm] dwords:3648
Jan 19 20:55:26 somehost kernel: [ 70.613193] [drm] offset 0xe0252000
Jan 19 20:55:26 somehost kernel: [ 666 6666666166666666666666666666666666 6666666666666666617666666666666666666666666666 6666 666666 66666666666666666666666666666666666666666666666666 66666626 66666666666666666 66666666666666666666666666666666666666666666666666 6 6666 6666666666666 666666466666666666666666666666666666666 666666666 6666666 666666666666666 66666664666666 665650592] [drm] offset 0xe0332000
Jan 19 20:55:26 somehost kernel: [ 70.650647] [drm] dwords:3648
Jan 19 20:55:26 somehost kernel: [ 70.650650] [drm] offset 0xe03466666666666666666 6665266666 666666656666666666 66666666666666666666666666666 666666 66666666666666666666666666666 66666 666666666 666666666666666666666666 66 666666 6666666666666666666 6666 66666666666 666666666666676666666 6666666 66666666866 666666666 666666666666666666666666 6666666 666666666 6666666666666686666666666666666666666668688662] [drm] offset 0xe0232000
Jan 19 20:55:26 somehost kernel: [ 70.688714] [drm] dwords:3648
Jan 19 20:55:26 somehost kernel: [ 70.688717666886666 66666666666 6666 66666666666666 6666 6666666666666666666666666 6666666666666666666666666666 696666666 6666666 6666666666666666666777 777777 777707777777 77777777777777777777777777777777777770777777 7777 77777777777777777777777 777777777777777777777777 777777777777777 777777 7 7777777721 77 7777777777777777777 77777777777777772724904] [drm] offset 0xe0312000
Jan 19 20:55:26 somehost kernel: [ 70.724958] [drm] dwords:3648
Jan 19 20:55:26 somehost kernel: [ 77777 7 77777777777777777777777777777777777777777777777777 77777777777777777777777777777777327777 7777 77777777777777777777777 7777777777777777 777777 7777 77777 77777777777777 777 77477777777777777 7777777777777777777777777 777777 7777777777777777777 7777777777777777777777 777775777777 77777777777 7777 777777777777777 77777777776760565] [drm] offset 0xe0202000
Jan 19 20:55:26 somehost kernel: [ 70.760620] [drm] dwords:3648
Jan 19 20:55:26 somehost kernel: 7607777777777777 7777777777777777 777777777 7777777777777 777777 77777777777777777 7677777 7777777777777 777777 7777777777777 7777 7777 7777777777777777777777777 7777777777 7777777777777777 7 777777777777777777 77 777777777777777777777 777777777777777 7777 7 777777 7777777 77777777777777777777777777777777777 77 77777777777777777779795502] [drm] offset 0xe02f2000
Jan 19 20:55:26 somehost kernel: [ 70.795555] [drm] dwords:364777777777777 7777777777777777777 77 77777777777777 77777 88888888888888888 88888888888888888888888888888888888888 8888 888 8888888888888888888 88888888888888888888888888888888888888888888888888 8888888 888888888888888888888 8888888888288888 888888 888888888 8888 88888888888 8888888888888888888888 8 888888888 8888888888888888888882828894] [drm] offset 0xe03e2000
Jan 19 20:55:26 somehost kernel: [ 70.828947] [drm] dwords:3648
Jan 19 20:55:26 somehost kernel: [ 70.828950] [drm] offset 0xe03f2000
Jan 19 20:55:26 somehost kernel: [ 70.829004] [drm] dwords:3648
Jan 19 20:55:26 somehost kernel: [ 70.829007] [drm] offset 0xe0202000
Jan 19 20:55:26 somehost kernel: [ 70.829062] [drm] dwords:3648
Jan 19 20:55:26 somehost kernel: [ 70.829064] [drm] offset 0xe0222000

[monraaf]

The updated X server didn't help :\
The system still locks up if I move a simple terminal window around too much, even with the NoEXAComposite and MigrationHeuristics options.


Did you use NoEXAComposite or EXANoComposite? I think only the latter is a valid option. You should check out your Xorg log file if the options you use are accepted. Also EXA has a man page with some more options you can try out. Just type man exa.

[bugmenot]

I just want to underline that it crashes here reproducible, too. RS780 (radeonhd 3200 IGP) and it does not matter which options I choose. :(

And I'd like to do some debugging, too, if it helps.

[DanL]

Did you use NoEXAComposite or EXANoComposite?
Sorry, I meant EXANoComposite. I looked at the man page for exa, but I don't see anything that looks relevant beyond the aforementioned options. I guess I'll just have to wait for the drivers to be a little more stable.

[bridgman]

I just want to underline that it crashes here reproducible, too. RS780 (radeonhd 3200 IGP) and it does not matter which options I choose. And I'd like to do some debugging, too, if it helps.

Can you pop up on #radeonhd IRC tomorrow ? Today agd5f is away and it's pretty late in the day for emmes.