Radeon KMS, New TTM Code Works But Needs Testing

[nanonyme]

Btw, just as a comment: Could the conversation not about the new ttm code please be moved to new question threads so this could be kept relatively focused to the feedback on the new ttm code? I'm sure bridgman reads them too and not just this thread. It would be more helpful when one actually wants to go through the bits of wisdom that might come out during the conversation.

[Davy]

I don't think it's "marketing reasons" that stop the distro makers from providing that information, it's just the effort required to keep track of all the constantly changing data vs the resources they can afford to invest.

Distro makers are not alone they have a large community to help them "keep the track" and test things. That's precisely what I clumsily try to do.

The installer and restricted driver managers aren't supposed to let you upgrade on a GPU that isn't supported. If you're seeing that happen, please let us *and* the distro packagers know. Downgrading should be a non-issue if the upgrading doesn't happen in the first place.

Well, upgrade is actually possible, the free driver is used, but 3D apps are freezing on some hardware. The only possible solution would be to ship both X servers 1.6 and 1.5 only to run fglrx legacy driver. This have been taken in consideration before the latest fglrx added support for X server 1.6, but then canceled. I reported the freezing problem with the free drivers a little bit too late. But they put a section in the errata...

If you are seeing freezing with the open drivers please make sure that there are current bug reports filed at bugs.freedesktop.org.

This bugzilla is a little too messy. I'm not able to perform any relevent search. Tough I'm convinced it is the right thing to do.

As Nanonyme said if it were trivial to add and validate new distro support we would probably still be doing it.

I don't say that. We volunteer for this job, but this can be done with open source drivers only, because it can be done before the releases.
And that's not what he said. He was talking about X server 1.6 support for fglrx legacy driver.

As Nanonyme said too, we are a little off topic and we should continue this interesting discussion (at least for me) somewhere else. Sorry for the noise guys.

We are not supporting new OS versions on 5xx and earlier for any OSes, this is not just a Linux thing.

I didn't know that. Does it mean that it won't be possible to use Win$ 7 on those GPUs?

I don't understand what you mean about waiting for AIGLX for a year, we added that in September 07. If you mean waiting for RDR (which is what users were really looking for even though they asked for AIGLX) then that shipped in the Cat 9.3 release and it should work for you today on a supported distro (say Ubuntu 8.10).

I was waiting for compiz to work with fglrx and AIGLX (it was missing something like texture_from_pixmap extension). And yes your right what I wanted to see too is Redirected Direct Rendering. I've never been able to see RDR on my desktop, because the cooker is using X server 1.6 for months (in fact it was 1.5.99.3, since December 30th).

Your card doesn't have any video decoding hardware other than an MPEG-2 IDCT engine; UVD starts with the RV610 and higher.

One more bad news. Perhaps, in the future, there will be a way to use the GPU power for video offloading through the VA API but in a more generic way as we are now talking about GPGPU...

Supporting open driver development requires a much bigger ongoing resource commitment than you might think. It's not a question of "just making a decision".

You are talking about legal issues for IP or something more technical?

No. 85% of performance would mean that we wouldn't sell any cards in the workstation space. I meant what I said -- that fglrx is not going away any time soon. You should probably try fglrx on a FirePRO card with a supported workstation OS, running typical workstation apps and workloads, before judging the functionality.

Well, let's say 95%, if you prefer. I don't think 5% more would be significant. Perhaps it could even be faster than the fglrx. Who knows?

[agd5f]

One more bad news. Perhaps, in the future, there will be a way to use the GPU power for video offloading through the VA API but in a more generic way as we are now talking about GPGPU...

MC (which is a significant portion of decode) is done on the 3D engine. The 3D engine programming information has been released, so the code could be written. There is even code to do it in gallium.

[sobkas]

After loading radeon module with option modeset=1
monitor doesn't get any signal from card(No Signal).
Output from dmesg(drm debug=1)

http://www.pastebin.ca/1412230

It's also contains output from blindly starting X(gdm actually).
Log from X:

http://www.pastebin.ca/1412248

Radeon X1650 pro
Philips 200VW
Asus M2A-VM

[fat_chris]

After loading radeon module with option modeset=1
monitor doesn't get any signal from card(No Signal).
Output from dmesg(drm debug=1)

http://www.pastebin.ca/1412230

It's also contains output from blindly starting X(gdm actually).
Log from X:

http://www.pastebin.ca/1412248

Radeon X1650 pro
Philips 200VW
Asus M2A-VM

After loading radeon, you need to modprobe fbcon or build it into the kernel.

[sobkas]

After loading radeon, you need to modprobe fbcon or build it into the kernel.

I already have this, but by try and lots of errors I was able to pin my problem to the presence of vesafb and/or vga16. After turning it off I was able to get console but X still doesn't start.