AMD Releases Open-Source R600/700 3D Code

[phoronix]

Phoronix: AMD Releases Open-Source R600/700 3D Code

Since earlier this year we have been waiting for AMD to release documentation and/or code on the ATI R600 series concerning 3D acceleration so that the open-source Linux drivers can begin to support the newer ATI graphics processors. It has taken longer than expected for AMD to complete and release this information, but it's now available. AMD has released the fundamental Linux code needed to begin fostering the development of an open-source R600 3D driver. Furthermore, this code also concerns the latest R700 series of graphics processors! The microcode for the newest GPUs has also been released.

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

[izual]

Well, THAT's a late christmas present!
Thx to everyone involved in this!

[Kano]

I just don't get why radeonhd will get it faster than radeon when agd5f works for ATI and on the radeon driver?

[bridgman]

I just don't get why radeonhd will get it faster than radeon when agd5f works for ATI and on the radeon driver?

Alex has been working on acceleration code in radeonhd for quite a while. We are trying to keep the acceleration code relatively common between the two drivers anyways.

[izual]

...We are trying to keep the acceleration code relatively common between the two drivers anyways.

Well that leads to the question about the reason for two drivers(:)) but don't listen to me, that has been discussed several times here let's not do it again. :)

[sim0nx]

Aaaaaah now that's some awesome news ... thank you very much to everyone involved !

/me hoping to soon be able to drop those barely working, crashy buggy proprietary drivers :-)

[StefanHamminga]

I just don't get why radeonhd will get it faster than radeon when agd5f works for ATI and on the radeon driver?

I'm glad they did, this way at least I can enjoy both perfect HDMI audio AND 3D! :D

Where do I send the champagne? ;)

[bridgman]

let's see... Nuremberg is closest to you, send the champagne to SuSE ;)

[chrisr]

A Radeon 4670 with an AGP connector...

[bridgman]

Don't do it man... get a PCIE motherboard. Seriously. Please don't make us support AGP again.

[hobbes]

Congratulations to everyone involved.

For awhile I'll still own a R500 VPU, please don't forget about us?

;)

[chrisr]

Don't do it man... get a PCIE motherboard. Seriously.

Dual P4 2.66 GHz Xeon, 2 GB RAM, non-standard ATX power supply...

I hate throwing away perfectly useful and fully working hardware. And besides, the 4670's reduced power consumption makes it an ideal "final" upgrade for this machine.

Please don't make us support AGP again.

That's surely up to your hardware partners! I'm hardly likely to magic an AGP version of anything out of my (err)"boat". (Or similar... ;-).)

[[Knuckles]]

Yes! I can feel kernel mode setting coming to my X1300 soon :)

[oibaf]

Very nice news! :)

I have a question, however. What about the source of the DRM microcode? Without that the driver can't be considered fully open source.

Note that Intel is shipping full source for their assembler code (source in .g4a files, compiled microcode in .g4b files), making it a fully open source driver:
http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/tree/src

[StefanHamminga]

Congratulations to everyone involved.

For awhile I'll still own a R500 VPU, please don't forget about us?

;)

The R500 is perfectly supported, full 3D and all!

[chrisr]

The R500 is perfectly supported, full 3D and all!

I have a laptop with a FireGL 5250 chip (R535, or thereabouts) and Wine, and its rendition of World of Warcraft with Mesa leaves a lot to be desired.

Mind you, WoW with fglrx is hardly flawless either. 8-12 was the first fglrx driver in months that I didn't swear at - once I'd managed to mend the Fedora packaging scripts again.

[hobbes]

The R500 is perfectly supported, full 3D and all!

Yes, it is for sure, and I'm using it now.

But, I believe there are still some room to optimization.

real 720p HD video playback, for one.

So, just what I'm saying is.

Keep showing us some love in the future.

:)

[bridgman]

I have a question, however. What about the source of the DRM microcode? Without that the driver can't be considered fully open source.

I didn't think the Intel GPUs used loadable microcode, but I could be wrong. All of the .g4a and .g4b files I saw looked like driver code (shader code called by the driver, to be precise). Anyways, the use of microcode blobs seems to be generally accepted, although there are occasional pushes to have them loaded from user space so the kernel guys don't have to feel dirty.

EDIT - geez, Intel shader code is nearly as hard to read as ours ;)

re: ongoing 5xx love, I think the plan is to implement KMS/MM all the way back to R100 and Gallium3D/GL2 as far back as R300, so no worries.

[gururise]

Finally! Thanks AMD! I look forward to being able to use my new 4670 card that has been putting along with only 2d graphics up till now!

[StefanHamminga]

I have a laptop with a FireGL 5250 chip (R535, or thereabouts) and Wine, and its rendition of World of Warcraft with Mesa leaves a lot to be desired.

Mind you, WoW with fglrx is hardly flawless either. 8-12 was the first fglrx driver in months that I didn't swear at - once I'd managed to mend the Fedora packaging scripts again.

On the bright side, my FireGL V5200 can play 'bluray bitrate' 1080p smoothly on a aging 2GHz C2D T7200, something I couldn't do in either XP32, XP64, V32 or V64, so they are doing something right...

[octoberblu3]

Absolutely fantastic! Thank you everyone for working towards a better ATI/AMD tomorrow.

[hobbes]

On the bright side, my FireGL V5200 can play 'bluray bitrate' 1080p smoothly on a aging 2GHz C2D T7200, something I couldn't do in either XP32, XP64, V32 or V64, so they are doing something right...

Now I'm felling envy.

I can't play under any circumstances 1080p (even with less bitrates) with my AGP x1600pro + Pentium D

Full 720p is kind of problematic with some actions scenes (explosions) where are too much decoding on the scene background.

But, is it improving...

:o

[chrisr]

On the bright side, my FireGL V5200 can play 'bluray bitrate' 1080p smoothly on a aging 2GHz C2D T7200, something I couldn't do in either XP32, XP64, V32 or V64, so they are doing something right...

The radeon xorg driver has at least one feature that makes it better than fglrx when playing textured video: it doesn't crash the X server when playback ends.

The xorg driver also has "no more tears" support; I'm not sure if fglrx has its own version of that.

[Nighthog]

Quite nice future AMD will have whit linux and such now I see :)

Can't wait to get my HD3200 to be useful in Linux etc.

[lucky_]

Yeah, that's a good news, strange to see that it didn't hit slashdot yet. (where are the hard slashdoters..)
By the way I was wondering what will be the requirements to experiment with those nice bits. (Xserver from git ?)
Supporting 3D (compiz, dri2 and not broken opengl within compiz ) by the of the first quarter of 09 ??
Is it reallistic considering the hardy way you went through and the unpleasant surprise you had to deal with ?
Anyway can't wait to have a proper opengl 2(+1) compatible driver ...
Thanks !
Let's see who from Intel or ATI will have the best driver by the end of April for my Lenovo t400 (two graphic card inside).
Within compiz every opengl app is completely garbeled (Intel).
And there is no way for me to get the ATI card working (read X starting) with the radeonhd driver.
It would be ironic to see AMD be first, hehe
(like the challenge)

[chaos386]

So in just over a year, AMD has added open-source modesetting, 2D, 3D and Xv support to all of their GPUs? I'm quite impressed! Hopefully this means R800 2D/3D support will come much sooner after the release of the hardware. :)

I'm currently using an Intel IGP, since my graphics needs aren't that high at the moment, but once GPGPU takes off and/or the open-source drivers perform better with Wine, I intend to upgrade to a discrete AMD/ATi GPU.

[»John«]

Looks like Christmas came a little late this year... Anyway, seeing you guys kept your promises despite all the stupid DRM hardship finally made me stop regretting the day I decided to support you for your FOSS iniciative.
Now I believe I'm not only speaking for myself when I promise that I'm gonna reward you with buying your stuff and recommending it to every GNU/Linux user I know as long as you keep supporting us this way. Keep up the excellent work, AMD!
And John, please relay our sincere thanks to everyone responsible for this wonderful late-Christmas present :o

P.S.: I found out fglrx wasn't the only thing responsible for all my trouble - one of the memory modules was corrupting data on several addresses which seems to be where most of the deadlocks came from. I'm just about to toss the whole RAM kit back the store for warranty claim.

[grantek]

Woohoo! Thanks AMD!

...and thanks to Bridgman for copping all of the flak around here :)

[dungeon]

I'm happy to see this:).

[Extreme Coder]

Now I'm felling envy.

I can't play under any circumstances 1080p (even with less bitrates) with my AGP x1600pro + Pentium D

Full 720p is kind of problematic with some actions scenes (explosions) where are too much decoding on the scene background.

But, is it improving...

:o

As far as I understand, there should be no differences in playback performance between fglrx and radeon/radeonhd driver, since both just use Xv for playback. and the CPU has to do the decoding in both cases.
Maybe this will change after AMD's XvBA for fglrx is released. Hopefully something for the OSS driver is implemented too.

[korpenkraxar]

Congrats to all of us AMD/ATI users and developers! Let the gates to the bazaar open!

Now we just need to see a timely release of some new supported, powerful, green and affordable cards available around summer or so to go with this.

Great job!

[hobbes]

As far as I understand, there should be no differences in playback performance between fglrx and radeon/radeonhd driver, since both just use Xv for playback. and the CPU has to do the decoding in both cases.
Maybe this will change after AMD's XvBA for fglrx is released. Hopefully something for the OSS driver is implemented too.

OSS driver. That's my only hope. It doesn't appear that will be XvBA or something in fglrx that I actually can use it to smooth Full 720p / 1080p playback on my hardware (AGP x1600pro)

Let's hope for the best.

[paul]

re: ongoing 5xx love, I think the plan is to implement KMS/MM all the way back to R100 and Gallium3D/GL2 as far back as R300, so no worries.

Unfortunately, R500 support is not complete in all aspects. While I can run compiz and watch movies at the same time on radeon, I still have googleearth tearing with compiz, and tv and vga out support are lacking (see bug http://bugs.freedesktop.org/show_bug.cgi?id=16781 ). Even arlied's latest tv out patch does not work here (M54, aka X1400 Mobility). So, I still have to keep a dumb M$ partition for when I want to use the S-video out. While fglrx supports tv and vga out, it does not allow compiz while watching videos. So, switching to it does not provide a full featured driver either. It would be nice if you could take fglrx's support for tv / vga and slap it in the radeon or radeonhd.

So, as requested, please don't forget about r500.

regards,
paul

[Pseus]

This is awesome! I'm considering getting a 4670 and this certainly makes my decision much easier :)

Keep up the good work, AMD :)

[Nille]

The R500 is perfectly supported, full 3D and all!

Sorry but for "perfectly" we miss some Features http://www.x.org/wiki/RadeonFeature

[RealNC]

Yes, we know. That doesn't mean there should be no support for R600/700 because of that.

[ig-88]

thats some pretty nice news! lets see what next year brings...

[Dieter]

Look at

http://www.x.org/wiki/RadeonFeature

XvMC is listed as TODO across the board. When can we expect to
see FLOSS AMD/ATI drivers supporting XvMC?

[bridgman]

There hasn't been much interest in XvMC so far -- general feeling seems to be that even a laptop CPU can handle MPEG2 decoding well enough. There seem to be an increasing number of HD MPEG2 use cases, and we have already released enough information to implement MC on 5xx (and, as of today, 6xx/7xx I guess) but nobody has even asked how to implement it, which surprises me. We have IDCT on the list of hardware to try and open up, but given the lack of interest in MC it doesn't seem like a real priority (MC eats more CPU time than IDCT and is probably easier to implement).

If the issue is simply that not enough developers know how to implement XvMC then we could probably put together a sample implementation to get things started, but nobody seems to even ask about XvMC let alone show any interest in implementing it. I guess the issue is that the only place XvMC really buys you much these days is playing HD resolution MPEG2 streams, typically from off-the-air HDTV (ATSC, DVB), and not many people seem to do that.

EDIT -- I might have found the answer. The "classic use case" for XvMC was European digital TV, which was heavily standardized on MPEG2 at HD resolutions. Looks like many countries have already jumped ship to MPEG4 for most of their HD broadcasts, so the demand for HD MPEG2 acceleration seems to have evaporated. Given that, I think interest in XvMC is going to continue to be lukewarm until there is some agreement on an API which cleanly handles H.264 and VC-1 as well, whether it be an XvMC extension or something new like VAAPI, XVBA or VDPAU.

[soros]

from the article,

Today's Drop

What's encompassed by today's drop is a working DRM (for the newbie, Direct Rendering Manager, not to be confused with Digital Rights Management), working EXA acceleration, an initial X-Video implementation and the working r600_demo program. There was about 180 pages of 3D register specifications set to be released, but all of the AMD officials didn't come to a consensus before leaving for the holidays. This documentation should be publicly released within approximately one month.

You'll likely never see those registers. The powers that control AMD have already decided to stonewall the opensource movement.. probably led by a dominant faction controlling microsoft.

linux will never see 3d opensourced.. just ain't gonna happen.

[TechMage89]

I bet you think the moon landing was a hoax, too...

Honestly I'm a bit tired of this, it borders on trolling.

[bridgman]

You'll likely never see those registers. The powers that control AMD have already decided to stonewall the opensource movement.. probably led by a dominant faction controlling microsoft.

linux will never see 3d opensourced.. just ain't gonna happen.

:confused:

Both r600_demo and radeonhd include a header file containing all of the register names, offsets, field names, shift and mask info from the register spec document. If you're having trouble sleeping you can take a look at :

http://cgit.freedesktop.org/mesa/r600_demo/tree/r600_reg_auto_r6xx.h

Register info and sample code using the registers is already out. The only additional information in the register spec document is comment information with tips & guidelines for the fields. I didn't feel we had enough review coverage on that part of the package so pulled it out for now to avoid holding up the rest of the information.

[Dieter]

> There hasn't been much interest in XvMC so far

Perhaps you missed Phoronix's "2008 Linux Graphics Survey"?

The #1 activity was video playback, listed by 37.90%

"the second area with the most interest is seeing video improvements to X.Org"
Chart says 21.26%

Video playback/acceleration was listed by 15.09%

"When it comes to video playback improvements, the leading open-source solution
right now is through XvMC"

A related feature, TV-out was listed by 19.6%

http://www.phoronix.com/scan.php?page=article&item=lgs_2008_results&num=1

> I guess the issue is that the only place XvMC really buys you much these
> days is playing HD resolution MPEG2 streams, typically from off-the-air
> HDTV (ATSC, DVB), and not many people seem to do that.

Does the date 2009-02-17 mean anything to you? Do you actually think that
not many people watch TV?

So there is need/interest. When will FLOSS drivers accelerate mpeg decoding
on AMD/ATI GPUs?

[BlackStar]

> > There hasn't been much interest in XvMC so far

> Perhaps you missed Phoronix's "2008 Linux Graphics Survey"?

Bridgman is probably talking about developer interest, not general interest. We may not like it, but unless someone with the technical knowhow becomes motivated, neither XvMC not tv-out will see the light of day. That's the way the open-source world works.

What's so signifcant about 2009-02-17?

[bridgman]

I started a new thread to get the XvMC discussion out of the r6xx/7xx thread :

http://www.phoronix.com/forums/showthread.php?p=56755#post56755

BlackStar, Feb 17/09 is the cutover date from analog to digital broadcasting in the U.S., ie the date your analog TV stops working unless you have a set-top box to convert digital broadcasts to analog. Other countries have different cutover dates.

[sylware]

Indeed...
Bravo to AMD and Intel.

[charlie]

Thanks AMD/ATI. And especially thanks to bridgman for your documentation work and involvement on the Phoronix forums.

As I will most likely be auto compiling radeonhd daily where should I send my driver experiences (bug reports) to or who will be working on the R600 (HD 3850) driver?

[Louise]

I was wondering, if it would be possible to make GPU load monitor for Gnome/KDE just like there is for the CPU?

Or can such a thing not be made for a GPU?

[EmbraceUnity]

Great Work! I have already started spreading the good word about your cards. My next card will definitely be from AMD again.

I am so excited now with this documentation drop and the recent Gallium3D developments. We're almost there!

Would all this allow open source GPGPU? Your recent cards are such beasts it seems a shame to let them go to waste for even a second.

[yoshi314]

In the past we have talked about CAT, KGrids, and TCore, which are all internal ATI/AMD software projects used by their driver developers, but these are no longer being open-sourced. now i finally understand what does "imminent" mean in phoronix-slang ;-)

aside from that - more great news for ati+linux users.

[Nille]

I have Try it but i think i have make something wrong.

http://img152.imageshack.us/img152/2131/bildschirmfotozm9.th.png (http://img152.imageshack.us/my.php?image=bildschirmfotozm9.png)

if i try to move window the cpu usage grows up to 100% and the Video Playback give only a Black field.

glxinfo (http://pastebin.com/f23b032e2)

xvinfo (http://pastebin.com/f3766c6dc)

Xorg.0.log (http://pastebin.com/m709a6ee9)

xorg.conf (http://pastebin.com/f2b33d235)

PS: smt is Spamming in the xorg.log he is about 31 MB o_O with stuff like this Klick (http://pastebin.com/f63133689)

NOTE: I use a Radeon HD 3850 with Ubuntu 8.10

[val-gaav]

Although I'm more interested in r300-r500 things (I have an rs690) I'm all happy for those who own r6xx r7xx ... I can still remember when I had to wait for support for my card and struggling with fglcrapx... It wasn't that long wait though (only about half year).

It's a good moment to wish all the devs and team involved with AMD open source strategy/initiative a happy new year :) May your wishes/dreams be fullfiled in 2009 :)

[bulletxt]

Hey...if somehow my terrorist complaints on this forum about AMD was helpful to make them work faster, yeah! I'll continue then!!

Nah, I can officially say thanks to AMD and I'll for sure start year 2009 with a smile on my face when I look at my ATI 2600Xt card.

Well, good job then to all developers of these open source drivers and I'll hope one day you can give a lesson to NVIDIA and make them understand no one wants blob drivers, even if somehow they work well.

Good year to all, including you Bridgman and Michael which of course today is really happy I guess :) we are all happy:D

[dm0rais]

Good job AMD, Thats y I chose my radeon over nvidia offerings :up:

Now bring Deneb :p

[disturbedsaint]

Thanks AMD/bridgman!

Will be buying a new AMD mainboard and graphics card to support you!

edit: bought a HD 4550 to start with! :)

[russell_h]

Is there a place we can easily donate to development of these drivers?

Or do any of the teams involved have some sort of booze fund? Wouldn't want to distract you from your efforts, but wouldn't mind showing my appreciation either ;)

[val-gaav]

I'll hope one day you can give a lesson to NVIDIA and make them understand no one wants blob drivers, even if somehow they work well.

Not to look far away even on this forum there are many people who would take nvidia blob over any other open solution.

But I hope a day comes when open drivers will be better then the blob in almost every aspect... then nvidia may learn that lesson. Right now they are the best so obviusly they do not see any reason to open up, or see things from different perspective.

[Uber]

There hasn't been much interest in XvMC so far -- general feeling seems to be that even a laptop CPU can handle MPEG2 decoding well enough. There seem to be an increasing number of HD MPEG2 use cases, and we have already released enough information to implement MC on 5xx (and, as of today, 6xx/7xx I guess) but nobody has even asked how to implement it, which surprises me. We have IDCT on the list of hardware to try and open up, but given the lack of interest in MC it doesn't seem like a real priority (MC eats more CPU time than IDCT and is probably easier to implement).

If the issue is simply that not enough developers know how to implement XvMC then we could probably put together a sample implementation to get things started, but nobody seems to even ask about XvMC let alone show any interest in implementing it. I guess the issue is that the only place XvMC really buys you much these days is playing HD resolution MPEG2 streams, typically from off-the-air HDTV (ATSC, DVB), and not many people seem to do that.

EDIT -- I might have found the answer. The "classic use case" for XvMC was European digital TV, which was heavily standardized on MPEG2 at HD resolutions. Looks like many countries have already jumped ship to MPEG4 for most of their HD broadcasts, so the demand for HD MPEG2 acceleration seems to have evaporated. Given that, I think interest in XvMC is going to continue to be lukewarm until there is some agreement on an API which cleanly handles H.264 and VC-1 as well, whether it be an XvMC extension or something new like VAAPI, XVBA or VDPAU.

Congrats on finaly showing of the docs.

I'm sure in a few years the driver could be very useful. (No sarcarms intended.)

I like to highlight the need for supporting the XvMC API.

1. Did you forget what codec that's in DVD ? :) -> Mpeg2
2. Did you forget that most legacy cam recorders record in Mpeg2 ?
3. Did you forget that many applications such as Mythtv, Xine, Mplayer etc have good and useful support for this API ?

I also like to pinpoint that bulding an HTPC mediacenter based on ATI cards are terrible ? I worked with it for an hole year with an ATI2600 card and after picking up an used Nvidia 6600 I got an hole new life.

But yes, I'm in Euro and while there are a few Channels having an H.264 streams in the ts, most are still Mpeg2.

But yeah, I welcome something like VDPAU for ATI cards, but there are to many bugs with the curent closed driver and mythtv that should be fixed first.

Cheers and thanks for the hard work.

I might swap my Nvidia card when you catch up with them :)

[RealNC]

1. Did you forget what codec that's in DVD ? :) -> Mpeg2
2. Did you forget that most legacy cam recorders record in Mpeg2 ?
3. Did you forget that many applications such as Mythtv, Xine, Mplayer etc have good and useful support for this API ?


Did you forget that any CPU, even an old Pentium 2, can handle that? :P Even on Windows, where the drivers support everything, MPEG2 acceleration is not used by most people because it's totally unnecessary. They prefer software decoding due to the software being able to enhance the picture that way.

[curaga]

Thanks AMD. You did what you promised, and in an OK timeframe. Expected nothing less.

Some days ago I bought an r500 card, because I have the choice of drivers. If that choice is soon brought to the newer cards, might get one of those too.

Booze fund, heh ;)

[elanthis]

As far as I understand, there should be no differences in playback performance between fglrx and radeon/radeonhd driver, since both just use Xv for playback. and the CPU has to do the decoding in both cases.

You'd be surprised what a difference you can make when you properly optimize that CPU usage, though. :) It's entirely possible for there to be a vast gulf between the two drivers' performance achievements.

[LurkerMan]

I bought a 3850 a while back before the 4800 series came out. My only regret is not buying a 3870. :)

Thanks for the hard work bringing this to the community. I hope the community repays AMD/ATI in kind.

Trying to do my part. Just bought a 780g motherboard (Foxconn A7GM-S) and an X2 cpu. The board I replaced had an Nvidia chipset (Biostar 6100 -M9).
Been very happy with it so far.

Now if I could use the 3850 for graphics while offloading the onboard 3200 for other tasks (like physics..hint...hint).

Anyways thanks again.

[Redeeman]

seriously, effort is spent MUCH better elsewhere than trying to implement video acceleration, ESPECIALLY useless mpeg2 acceleration.

Even my AMD64 S754 2ghz can do 1080i/p mpeg2 decoding. What does this tell me? well.. today we have an enormously bigger amount of cpu. Even today, the cpu's that are becoming mainstream can almost do 1080p h264 in realtime, and that is despite the fact that the branch in ffmpeg for properly threaded h264 decoding isnt even merged. Now consider that ffmpeg at some point will merge that, plus everyone is getting better cpus constantly, and 1080p H264 acceleration is gonna be as non important for us, as mpeg2 acceleration was back when our cpu's couldnt handle DVD playback!! we are talking at MOST 1 year.. and for enthusiasts, which we probably could be qualified as, we already have by far the capability to simply choose our hardware purchase, and most of us, probably already have the capable hardware.

So its simply not the trouble worth to do these things, when so many other, more important, more FUN areas can be worked on.

Also consider, that eventually in the future, with gallum3d, gpgpu etc, we are gonna simply implement the decoding using THOSE facilities(of which work is already in progress by atleast one person, with promising results). This further strengthens the plan of simply not borthering with conventional video acceleration right now.

What will do the most gain, is just getting plain old Xv working.


:)

[bugmenot]

Thank you AMD/Bridgeman/Alex/Egbert/others so much for this!
This is a really great moment and a big step.


re: ongoing 5xx love, I think the plan is to implement KMS/MM all the way back to R100 and Gallium3D/GL2 as far back as R300, so no worries.
It is so great that you don't forget about "old" devices. Many people still have these and are so happy about improvements.

What are the next steps?
Are you going to extend GEM to be able to be used with radeon/-hd?
DRI 2 for flicker free video watching is coming, too?
For video decoding there are many possibilities, you probably know better what makes most sense...via gallium3d, extended xvmc or vaapi or via openCL... I'm sure you are gonna make a wise decision.
Power management would be really sweet, too, but for that, a new interface to user-space would be needed, in order to control the usage and so on...


Thank you, thank you, thank you. I can't say it too often. :D

[agd5f]

I have Try it but i think i have make something wrong.

http://img152.imageshack.us/img152/2131/bildschirmfotozm9.th.png (http://img152.imageshack.us/my.php?image=bildschirmfotozm9.png)

if i try to move window the cpu usage grows up to 100% and the Video Playback give only a Black field.

PS: smt is Spamming in the xorg.log he is about 31 MB o_O with stuff like this Klick (http://pastebin.com/f63133689)

NOTE: I use a Radeon HD 3850 with Ubuntu 8.10

As mentioned in the release notes, this is targeted more at developers rather than users. Most features are incomplete at this point.

[RealNC]

I'm sure this sounds really bad, but you guys should be thanking the companies that are customers of AMD and pressured them into doing all this, because otherwise, AMD wouldn't give a rat's ass about you and me (= the Linux user) :P

[Dieter]

> Bridgman is probably talking about developer interest,
> not general interest.

I'm talking about customer interest. If AMD/ATI wants to
sell me a GPU, it *must* have FLOSS support for mpeg
decode (and working Xv and s-video out code as well).
Code that actually works, none of this tearing/purple/crashing
stuff I read about with the half-baked Xv code.

I realize that the profit margins are higher selling high
end chips to extreme gamers. But the volumes are higher
for video, nearly everyone watches tv.

AMD/ATI puts out binary-only drivers that decode video.
Obviously the chips can do it, and code exists to do it.
There is no reason AMD/ATI can't put out FLOSS code to
do it.

> What's so signifcant about 2009-02-17?

Analog TVs and VCRs in the US become boat anchors.
The obvious solution is to add ATSC tuner(s) to your computer
and have it be a DVR. There are FLOSS drivers for some
ATSC tuners. With ATSC the data arrives already compressed
(mpeg2 transport stream), so it takes very little CPU to record.
Basically just copy the data from the tuner to a disk file.
The problem is playback. Most channels are HD, so you have to
decode HD regardless of the display's resolution. This takes
a LOT of CPU if you decode in the CPU. Yes the latest CPUs
may be fast enough, but if your CPU is 2-3 years old you have
a problem. Buy a new CPU? AMD keeps changing the sockets,
so you have to buy at *least* a new mainboard and memory as
well as CPU, and maybe a new P/S as well. At that point you
might as well get a new case so you can use the old machine to
google for answers to the problems encountered bringing a new
machine up. Maybe you don't have the time and money to invest
in an entire new computer during Great Depression 2.0? Maybe
you object to wasting CPU on a job better done by a GPU? Maybe
you have other things for your CPU to be doing? A CPU takes more
energy to decode video than a GPU, so decoding with the CPU isn't
very green. Buying an entire new computer instead of just a video
card isn't very green either.

Or... AMD/ATI's developers that write the binary-only drivers could
write some FLOSS code and submit it to X.org or whoever.

[elanthis]

AMD/ATI puts out binary-only drivers that decode video.
Obviously the chips can do it, and code exists to do it.
There is no reason AMD/ATI can't put out FLOSS code to
do it.

I don't know the specific, but there are certainly MANY reasons why AMD might not be allowed to put out FOSS code for it. For starts, the video decode chip might not even be designed by AMD's engineers but instead might be a third-party part used by AMD under agreement to keep its interfaces secret.

There also might be patent issues at stake, such as the chip interface or the driver code using something that AMD had to license under very restrictive (and expensive) terms.

Finally, there's the security issue brought up -- the chip might heva some design flaws that allow parts of it to be used to bypass system security under Windows (I can think of some contrived examples of how that might be, but again I don't have any specifics) and the sad fact is that making the FOSS drivers at the expense of losing Windows certification would be corporate suicide.

It may be totally possible and safe for AMD to release specs to use the video decode hardware in FOSS drivers. We can't assume that's the case, though.

[Pfanne]

I don't know the specific, but there are certainly MANY reasons why AMD might not be allowed to put out FOSS code for it. For starts, the video decode chip might not even be designed by AMD's engineers but instead might be a third-party part used by AMD under agreement to keep its interfaces secret.

There also might be patent issues at stake, such as the chip interface or the driver code using something that AMD had to license under very restrictive (and expensive) terms.

Finally, there's the security issue brought up -- the chip might heva some design flaws that allow parts of it to be used to bypass system security under Windows (I can think of some contrived examples of how that might be, but again I don't have any specifics) and the sad fact is that making the FOSS drivers at the expense of losing Windows certification would be corporate suicide.

It may be totally possible and safe for AMD to release specs to use the video decode hardware in FOSS drivers. We can't assume that's the case, though.

nope its not possible ;)
if i remember what bridgman said correctly it took a lot of time to make sure its "impssible" reverse-engineer certain parts of the gpu with the given documentation to ensure amd/ati wont face legal problems...
and on top of that this videodecoding can be done with gallium3D in a "few" months, so its not that bad!

[bridgman]

You're both right :D

What I said was that we would spend some time to see if it was possible to open up the UVD hardware, but unless you hear me say otherwise you should assume that it's not going to happen.

On the other hand, MC can be done with the information we have already released, and I'm pretty sure we will be able to open up the IDCT hardware on 6xx-and-earlier parts. That said, I'm not convinced that the old IDCT hardware is worth using unless you have a *really* old CPU and GPU.

My guess is that a shader-based implementation for IDCT will be the way to go as well, particularly since all of the subsequent functions (filtering, MC, render stuff like CSC, scaling etc..) can be done in shaders as well so no need to push information back and forth between system and video memory. Anything upstream of IDCT will probably stay on the CPU, but AFAIK that runs pretty efficiently on CPUs today.

The only thing I'm not sure about is IDCT performance on shaders since it will probably require some texture indirection on most current GPUs that and I don't have a good feel for the performance implications of that. If it turns out that IDCT on shaders does run efficiently (as I expect) then I think we will probably go in that direction before trying to open up the old IDCT hardware.

[rbmorse]

I'm sure this sounds really bad, but you guys should be thanking the companies that are customers of AMD and pressured them into doing all this, because otherwise, AMD wouldn't give a rat's ass about you and me (= the Linux user) :P
When your market share is less than 1 percent (and after all this time, to boot) it's hard to get people very interested in you. Fact of life.

[_txf_]

You're both right :D

What I said was that we would spend some time to see if it was possible to open up the UVD hardware, but unless you hear me say otherwise you should assume that it's not going to happen.


Any chance that later uvd implementations will be more opensource friendly?

*dreams of os hardware bitstream decoding...then slaps himself for being so presumptuous*

[kraftman]

When your market share is less than 1 percent (and after all this time, to boot) it's hard to get people very interested in you. Fact of life.

Bullshit, stop repeating myths about this holly 1 percent. It was good few years ago. Only idiot can say it's just 1 percent and no matter if some company etc. said that. Do they have magical way to count every Linux machine? If someone buys computer with Windows and then he replaces that system to Linux only Windows is counted. Not only market share matters but quality.

[d2kx]

@News:

http://img296.imageshack.us/img296/7134/iloveatiwh9.th.jpg (http://img296.imageshack.us/my.php?image=iloveatiwh9.jpg)
(Source (http://news.ati-forum.de/index.php/news/58-intern-ati-forumde/205-ein-jahr-ati-forumde), made by the girlfriend of a friend of mine)

[rbmorse]

Bullshit, stop repeating myths about this holly 1 percent. It was good few years ago. Only idiot can say it's just 1 percent and no matter if some company etc. said that. Do they have magical way to count every Linux machine? If someone buys computer with Windows and then he replaces that system to Linux only Windows is counted. Not only market share matters but quality.
How do you determine market share? Pull numbers that make you feel good out of your ass?

But...I'll make you feel better. When your market share is less than 2 percent (and after all this time, to boot) it's hard to get people very interested in you. Fact of life.

[bridgman]

Any chance that later uvd implementations will be more opensource friendly?

*dreams of os hardware bitstream decoding...then slaps himself for being so presumptuous*

We are trying to make future GPU hardware more open source friendly and we have made a bit of progress already but most of the "ideal solutions" from an open source POV, particularly those related to video processing, end up raising the build cost for all markets so those changes tend not to make it into the product. The design pipeline is pretty long though, so the chips we can influence today won't be shipping for 2-3 years.

Bullshit, stop repeating myths about this holly 1 percent. It was good few years ago. Only idiot can say it's just 1 percent and no matter if some company etc. said that. Do they have magical way to count every Linux machine? If someone buys computer with Windows and then he replaces that system to Linux only Windows is counted. Not only market share matters but quality.

So far the best numbers we have for PC market share come from analyzing web site hits, since that measures which OS is running on the machine "right now" rather than what it was sold with. Those numbers put Linux at just under 1% share and relatively constant, Windows at around 90% and dropping slowly, MacOS at around 8% and growing slowly. There are some quirks with web browser and OS reporting so our guess is that Linux is slightly under-reported as a result -- I use 2% for planning which I believe is higher than today's market share but I do expect to see some additional growth.

Using web site hits obviously leaves out embedded systems and PCs without internet connections but for consumer PC market analysis that is probably reasonable (since we have other channels for embedded support).

The server market is significantly different -- Linux is closer to 25% than 1% -- but servers tend to use stone-age graphics so again I think it's reasonable to exclude those numbers. The commercial workstation market also has a higher percentage of Linux users (mostly coming over from the proprietary Unix world) but workstation is pretty much entirely a closed-source business because of the extremely high performance expectations.

[DoDoENT]

The R500 is perfectly supported, full 3D and all!

I can't say that. I'm using a R500-based card (Mobility X1600), and I'm stick to fglrx, because open source radeon driver lacks PowerPlay support (which I really really need on my laptop), and the framerate on most of the games (nexuiz, open arena, scorched3d, counter strike over wine) is at least two times higher than with the radeon driver.

For that reason I can't use compiz effects, because I can't watch video while effects are on. I would really like to know how can tearless video work with radeon driver, but not with fglrx. Even 3D applications don't flicker with compiz turned on, and all that without DRI2. I'm not the driver developer, but my guess is that while using fglrx, compiz always redraws the whole screen, while while using radeon, it redraws parts of the screen where changes occurred. I can see that when I start a full screen 3D game with compiz turned on: with radeon, the only part of the screen that flickers is the one where is conky placed (or any other window that has to be redrawed often), and with fglrx, the whole screen flickers.

Btw., keep up with good work, AMD! Thank you very much for releasing the documentation for your graphics cards. Please, release the PowerPlay documentation ASAP - all ATI laptop users would be very grateful.

[bridgman]

Power management info for 5xx is mostly out there already (in the AtomBIOS header & tables) and is gradually being included into the open source drivers. Power management for 6xx and up is quite different; that's next on our list but is going to be both time-consuming to document and difficult to use.

Right now most of the open source power management work is being done in the userspace drivers, which limits the amount of power saving possible -- eventually power management is going to have to be done in the drm (kernel module) if we want to match what the proprietary drivers can do.

3D apps *should* flicker under Compiz even with the open source drivers, unless you have the "don't redirect fullscreen windows" option set in Compiz and are running a fullscreen app (that works with fglrx as well). The video code in fglrx is being upgraded so you should continue to see improvements there.

[kraftman]

How do you determine market share? Pull numbers that make you feel good out of your ass?

Let's say Linux usage on desktops. Like Bridgman said: market share come from analyzing web site hits. That's correct, but some people count it as I mentioned before. Many Linux users just keep as far as possible from some sites that are being used to count Linux market share. It's enough for me just to use highest quality system to feel good. How do you explain that few years ago people was repeating same myth about 1%? Linux is growing faster than before, so it's strange.

But...I'll make you feel better. When your market share is less than 2 percent (and after all this time, to boot) it's hard to get people very interested in you. Fact of life.

This way you made yourself feel out of your ass better?

EDIT:

What time to boot?

@bridgman

Btw. Now I'm sure that my next card will be AMD/Ati :> Thanks for that!

[sundown]

I can't say that. I'm using a R500-based card (Mobility X1600), and I'm stick to fglrx, because open source radeon driver lacks PowerPlay support (which I really really need on my laptop), and the framerate on most of the games (nexuiz, open arena, scorched3d, counter strike over wine) is at least two times higher than with the radeon driver.

Let me tell you, I'm a Mobility X1600 camper and so far I'm happy with the open-source driver.

PowerPlay is WIP, as John mentioned, don't worry.

I will happily play Nexuiz with the crappy OpenGL 1.3 implementation of this driver anyday over fglrx that hangs my computer upon exiting Nexuiz.

Compiz is waaaaaaaaaaaaay faster than what fglrx delivers. 2d is waaaaaaaaaaaaaay faster. Even probably OGL 1.3 is faster than OGL 1.3 in fglrx.

Tear-freaking-free video playback!
Flicker-freaking-free video playback with compiz!

So to me, why you use fglrx, is a bit unjustified when you have in mind all the goodies coming in 2009 like Gallium, KMS, DRI2.

I will not be using fglrx anytime soon, even if they decode video with the GPU, but that won't be possible on r500 anyway. Fglrx is just one long, boring drag. I've had enough of it.

[RealNC]

workstation is pretty much entirely a closed-source business because of the extremely high performance expectations.

That explains why they're running Linux along with a crapload of open source GNU software. Yeah, closed source ftw ;)

[bridgman]

Yeah ;)

It's probably obvious but when I said "high performance expectations" I was talking about the graphics subsystem where the drivers are hugely complex and proprietary drivers still have an edge.

Seriously, I think a lot of the Linux workstation users are there not because GNU/Linux is "free like speech", but rather because the "free like beer" aspect of GNU/Linux killed off most of the commercial Unix vendors so they shifted to Linux instead. Most of the workstation market is running RHEL or SLED/SLES for the commercial support so for them it's "just like Unix" and software freedom just gives them something interesting to read about on the internet.

On the other hand, those users (and the commercial Unix vendors) also drove a good chunk of the $$ investment in Linux graphics over the last 10 years, so be nice to them :D

[rbmorse]

How do you explain that few years ago people was repeating same myth about 1%? Linux is growing faster than before, so it's strange.


Easy, and it's not at all strange. Linux may be growing -- I see no substantiation of this oft-quoted folklore -- but even if it is, it's not growing as fast as the total number of computers in use. Ergo, market share stays where it's been for the last several years, fairly constant at just under 1%.

I'm finished with this. If you come up with some real data as opposed to wishful thinking, start a new topic.

[RealNC]

Seriously, I think a lot of the Linux workstation users are there not because GNU/Linux is "free like speech", but rather because the "free like beer" aspect of GNU/Linux killed off most of the commercial Unix vendors so they shifted to Linux instead. Most of the workstation market is running RHEL or SLED/SLES for the commercial support so for them it's "just like Unix" and software freedom just gives them something interesting to read about on the internet.

I think it's more than that. We all tend to forget a bit what "open" means. It mainly means that those corporations have access to the source and that brings some benefits, like being able to adapt the code or pay someone to adapt it (or fix it) to their needs. The romantic part of "open" is nice to read about, but we mostly care about the practical benefits. It would be nice if I could fix or pay someone to fix fglrx for me, no? ;)

[hobbes]

Besides performance improvements, there is a old problem who persists on R500 radeon driver.

I'm using a x1600pro, with the latest radeon package on Jaunty Alpha 2.

Xorg.conf Settings:

Section "Device"
Identifier "Configured Video Device"
Option "AGPMode" "8"
Option "EXAVSync" "1"
EndSection


_ _ _ _ _ _ _ _


(==) RADEON(0): Using EXA acceleration architecture
(==) RADEON(0): Not using accelerated EXA DownloadFromScreen hook
(II) RADEON(0): Setting EXA maxPitchBytes
(II) EXA(0): Offscreen pixmap area of 116195328 bytes
(II) EXA(0): Driver registered support for the following operations:
(WW) RADEON(0): Option "EXAVSync" is not used



http://i41.tinypic.com/iw3k10.jpg

This picture is not from my PC.

I couldn't screenshot it, but I've found this picture taken but a Windows user at guru3d that shows exactly what happens with my hardware.

So, It will (When will) be possible to get rid off this horizontal line?

KMS, GEM, DRI2 or Gallium3?

Anyone?

Thanks for reading

[NuShrike]

Phoronix: AMD Releases Open-Source R600/700 3D CodeAny chance AMD will spread the wealth eventually and provide the same sanitized support for their Imageon processors?

It's kinda dirty that AMD can on one hand provide open-source support on the PC, but then completely deny the existence and documentation of their Imageon GPUs still shipping in new phone devices including Android and Windows Mobile. Makes this release look more like a PR stunt than a real, internal, culture shift.

Maybe AMD really doesn't care about the embedded market, nor that the victor is solidifying around PowerVR with their much more generous documentation and support.

[duby229]

Besides performance improvements, there is a old problem who persists on R500 radeon driver.

I'm using a x1600pro, with the latest radeon package on Jaunty Alpha 2.

Xorg.conf Settings:

Section "Device"
Identifier "Configured Video Device"
Option "AGPMode" "8"
Option "EXAVSync" "1"
EndSection


_ _ _ _ _ _ _ _


(==) RADEON(0): Using EXA acceleration architecture
(==) RADEON(0): Not using accelerated EXA DownloadFromScreen hook
(II) RADEON(0): Setting EXA maxPitchBytes
(II) EXA(0): Offscreen pixmap area of 116195328 bytes
(II) EXA(0): Driver registered support for the following operations:
(WW) RADEON(0): Option "EXAVSync" is not used



This picture is not from my PC.

I couldn't screenshot it, but I've found this picture taken but a Windows user at guru3d that shows exactly what happens with my hardware.

So, It will (When will) be possible to get rid off this horizontal line?

KMS, GEM, DRI2 or Gallium3?

Anyone?

Thanks for reading


Your not alone, I have exactly the same tearing. In addition to that I cant switch VT's. The light on the monitor turns amber, and I lose the connection to the monitor.

[bridgman]

Besides performance improvements, there is a old problem who persists on R500 radeon driver.

I'm using a x1600pro, with the latest radeon package on Jaunty Alpha 2.

<snip>

(==) RADEON(0): Using EXA acceleration architecture
(==) RADEON(0): Not using accelerated EXA DownloadFromScreen hook
(II) RADEON(0): Setting EXA maxPitchBytes
(II) EXA(0): Offscreen pixmap area of 116195328 bytes
(II) EXA(0): Driver registered support for the following operations:
(WW) RADEON(0): Option "EXAVSync" is not used

<snip>

So, It will (When will) be possible to get rid off this horizontal line?

Based on the error message, I expect the radeon code in the latest package might not be new enough. Can you get a date or commit number from your log ? The tear-free code only went in a couple of weeks ago.

Any chance AMD will spread the wealth eventually and provide the same sanitized support for their Imageon processors?

It's kinda dirty that AMD can on one hand provide open-source support on the PC, but then completely deny the existence and documentation of their Imageon GPUs still shipping in new phone devices including Android and Windows Mobile. Makes this release look more like a PR stunt than a real, internal, culture shift.

Maybe AMD really doesn't care about the embedded market, nor that the victor is solidifying around PowerVR with their much more generous documentation and support.

NuShrike, as I mentioned before AMD have announced plans to sell the Imageon division. I have asked internally about the possibility of providing open source support for the handheld products, but I don't think that is likely to happen until new owners have a chance to participate in the decision.

[agd5f]

So, It will (When will) be possible to get rid off this horizontal line?


that's called tearing. It should be gone for most users with the latest driver from ati git or the 6.9.0.91 rc release.


(WW) RADEON(0): Option "EXAVSync" is not used


Looks like your driver is too old.

[hobbes]

Based on the error message, I expect the radeon code in the latest package might not be new enough. Can you get a date or commit number from your log ? The tear-free code only went in a couple of weeks ago.

X.Org X Server 1.5.99.3
Release Date: (unreleased)
X Protocol Version 11, Revision 0
Build Operating System: Linux 2.6.24-15-server x86_64 Ubuntu
Current Operating System: Linux jaunty-desktop 2.6.28-4-generic #5-Ubuntu SMP Fri Dec 26 22:48:55 UTC 2008 x86_64
Build Date: 17 December 2008 03:13:46AM
xorg-server 2:1.5.99.3-0ubuntu3 (buildd@crested.buildd)
______

apt-cache policy xserver-xorg-video-radeon
xserver-xorg-video-radeon:
Instalado: 1:6.9.0+git20081003.f9826a56-0ubuntu6
Candidato: 1:6.9.0+git20081003.f9826a56-0ubuntu6
Tabela de versão:
*** 1:6.9.0+git20081003.f9826a56-0ubuntu6 0
500 http://ftp.ubuntu.com jaunty/main Packages
500 http://archive.ubuntu.com jaunty/main Packages
100 /var/lib/dpkg/status
________


full log: http://pastebin.com/m13b7c9c7

very latest packages.

[hobbes]

that's called tearing. It should be gone for most users with the latest driver from ati git or the 6.9.0.91 rc release.



Looks like your driver is too old.

Hmm, thanks for the info.

I'll look into it.

[bridgman]

Yep, from the log messages your driver is a couple of months old, which would normally be fine but it won't include the recent tear-free work.

[NuShrike]

Based on the error message, I expect the radeon code in the latest package might not be new enough. Can you get a date or commit number from your log ? The tear-free code only went in a couple of weeks ago.Is that tearing the driver itself or bad vsync? Seen plenty of that kind of tearing in (unrelated) landscape-mode for Opera Mobile currently.


NuShrike, as I mentioned before AMD have announced plans to sell the Imageon division. I have asked internally about the possibility of providing open source support for the handheld products, but I don't think that is likely to happen until new owners have a chance to participate in the decision.Thanks for an answer, even if it seems to me there would be complications with the Imageon sharing some internal elements with older Radeons such as raster op codes.

At least there's some information for moving forward. :)

[TechMage89]

Tearing is caused by drawing to the same part of the screen that's being scanned out. Right now, there isn't a good way to get rid of it without a performance hit (the radeon anti-tearing code stalls drawing until the scanline has passed the part of the screen the program wants to draw to.) In the future, there's talk of making a double-buffered framebuffer and pageflipping between scanouts.

[sundown]

Guys, tearing is fixed on R500!!! Don't spread an old myth, now. (or at least it doesn't work for TechMage89)

You should always use the most up-to-date stuff, though :)

I'm just soooo happy about the tearing being gone, I placed it as my status in Facebook... I'll keep repeating it over and over... and over... :D :D :D :D :D :D

[bruno08]

Absolutely fantastic! Thank you everyone for working towards a better ATI/AMD tomorrow.

Having todays HW tomorrow!

Well.. It would be really great if communications developed to the point of having programming specs earlier than cards...

(Yes if coding specs change last minute then drivers need minor change + rebuild.)

[bridgman]

It's already happened. Alex has been sitting in on some of the next-generation GPU design meetings and we are already going through the internal docs for the next couple of generations. We still don't plan to write much more than sample code until after the product launches, but we should at least know how to make the chip run by launch time. For some products we will want to have completed drivers at launch, but those will be handled on a case-by-case basis.

Catching up quickly with 6 years of hardware development was really difficult. We're hoping that keeping up will be easier.

[Kano]

Yes, this is a good idea. When you think of the delay from Windows driver support to Linux (fglrx) for some series ATI did not look good at all - NV always provided beta drivers for new products. Longest delay maybe 1-2 weeks.

[russell_h]

I think part of the problem is the fglrx release cycle. It works great for open projects because you can always get the latest features as soon as they're coded while at the same time providing a predictable release schedule for distros that include your program.

But for closed software like fglrx you really lose both of those benefits, since it often means long waits for the release of implemented features, plus, since you can't easily test pre-release code you can't even rely on features to be available or stable at release.

Making "test" builds easily available might fix a lot of that problem, but would probably also be a lot of extra work on such a frequent and rigid release schedule.

Just my thoughts.

/me off to pray to the video acceleration gods for documentation + fglrx support

[yesterday]

I think it's more than that. We all tend to forget a bit what "open" means. It mainly means that those corporations have access to the source and that brings some benefits, like being able to adapt the code or pay someone to adapt it (or fix it) to their needs. The romantic part of "open" is nice to read about, but we mostly care about the practical benefits. It would be nice if I could fix or pay someone to fix fglrx for me, no? ;)

For example movie studios like Dreamworks who build render farms and workstations with high performance needs have a bunch of in-house techs customising their linux workstations and servers for their specific benefits. Under a closed Unix model they had to rely on the OS provider for customisations which invariably means more cash.

Of course the film processing apps they themselves develop and sell are all closed sources, but surprisingly most of them have linux versions