AMD Releases Open-Source R600/700 3D Code

[rampage7]

I've wanted to try it by myself, but I've got some errors:

(EE) RADEONHD(0): RHDDRIVersionCheck: symbol GlxSetVisualConfigs not available.
(WW) RADEONHD(0): RHDDRIPreInit: Version check failed. Disabling DRI.

My system is Gentoo x86-64, xorg-server 1.5, 2.6.28 kernel with DRI module enabled, with mesa and radeonhd drivers from git repositories.
Have anybody some ideas about that errors?

[Louise]

I just read this blog post, about IBM should open source Domino.

http://feeds.feedburner.com/~r/storm...good-idea.html

Notice the none disclosure part. Scary stuff!

I guess AMD was faced with the same problems, and therefore choose to write the code that we now got

[DeepDayze]

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.



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... ;-).)

For your rig, get an nVidia 7800..that's the final upgrade for it as it's the best card in AGP format

[RealNC]

For your rig, get an nVidia 7800..that's the final upgrade for it as it's the best card in AGP format

Nope, there's also an HD3870 AGP

[elanthis]

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.

Yes, actually. Sales aren't counted so much as average web browser statistics from a number of sites. Your browser reports the OS and CPU architecture along with the browser version, you know.

Some sites are obviously skewed (e.g., Phoronix), but when you take a large cut of websites and average out the results you can get a fairly accurate picture of the OS landscape.

[DoDoENT]

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.

After reading your post, I've given another chance to the radeon driver... and I felt very disappointed. Nexuiz is slow, scorched3d unplayable, and glxgears gives only 1700 FPS (fglrx gives over 3000). Yes, with fglrx Nexuiz makes a mess from my screen resolution, but I solved that by playing nexuiz on 1680x1050 (which is my desktop resolution), and it WORKS well on that resolution (with radeon is slooow).

The only better thing in radeon is faster X startup and a lot faster suspend and resume process, but I think this will be solved in fglrx with the time too. After all, fglrx is consisted of both open and closed source code (as far as I know).

And I didn't experience any faster 2d performance with radeon than with fglrx. The video acceleration is the same. The only difference is when I turn on compiz effects - then fglrx makes no 2d acceleration at all, and radeon 2d performance is faster. But with compiz turned off, radeon driver is no match for fglrx, except in multi-monitor support. In multi-monitor support, radeon driver is a lot better, but since I use my laptop mostly for browsing the web, watching videos, gaming and for study, I rarely use multi-monitor feature.

So, to conclude, fglrx is an excellent driver for me (in comparison what it used to be one year ago).

Happy New Year to everyone!!!

[d2kx]

DoDoENT: Did you enable EXA for acceleration? I don't know why it is not the default option as even the Xorg.0.log advises you to do so. 2D acceleration with Xserver-stable which is 1.5 is better with EXA than fglrx, but it is insane with Xserver-unstable which will become 1.6.

Great improvements coming this year

[DoDoENT]

DoDoENT: Did you enable EXA for acceleration? I don't know why it is not the default option as even the Xorg.0.log advises you to do so. 2D acceleration with Xserver-stable which is 1.5 is better with EXA than fglrx, but it is insane with Xserver-unstable which will become 1.6.

Great improvements coming this year

Yes, I do have EXA enabled. Here is my xorg.conf configuration which I used with the radeon driver:

Section "Monitor"
	Identifier	"Configured Monitor"
EndSection

Section "Screen"
	Identifier	"Default Screen"
	Monitor		"Configured Monitor"
	Device		"Configured Video Device"
	SubSection "Display"
		Virtual	2704 1050
	EndSubSection
EndSection

Section "Device"
	Identifier	"Configured Video Device"
	Option   "AccelMethod" "EXA"
	Option          "DynamicClocks"  "on"
EndSection

I didn't say that radeon's video acceleration is slow. I just said that fglrx's video acceleration is no slower than radeon's video acceleration. At least in my case: I used intrepid ibex's default radeon driver and catalyst 8.12 in my comparison.

[popper]

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.

forgive me for my slapdash long post, times short and i feel you need to consider all these points and take something of them away
with you and the AMD/ATI crews, and give people what they want and need, they did buy the X1xxx/HD2/3650 etc on the PR sales pitch
that they would get hardware assisted Encoding AVIVO HW some day, not just the newest HD4xxxx remember...

bridgman, all due respect to you and your team etc but YOU really need to get out of the developers cave more,

it feels like your surounded by YES men, and no one wants to tell you this, but its is not 2000 anymore, and you seem to
have totally misread the current wants and needs for todays video users and part time video app coders etc.

theres a reason the AVIVO Encoder inside the MS driverset got a lukewarm reception world wide, and its not so much because of the lack of
real hardware assistance in it (ATI did sell X1xxx,HD2.3650 etc as getting GPU hardware assisted ENCODING though and still its doesnt)
, but rather the total lack of end user tweakability of the encoding parameters etc for 360/ps3 playback if you will,
thats getting your focus point totally wrong.

heres what you need to focus on _TODAY_
get some working code out that your average coders and users can see will benefit them ASAP and encurage them to drop the NV only
librays their code is now supporting and start using the likes of the ATI/AMD framework http://sourceforge.net/forum/forum.php?forum_id=764939 .

TODAY the most basic requirement for all the video users and part time coders of x264 and libavcodec/FFMPEG/VLC users world wide is
AVCHD, MBAFF and PAFF decoder options at the very least, curently AMD/ATI are getting forgotten as NV give these people the tools and
librays to do these most basic things and work with their video Encoding....

its simple , forget your ""classic use case" for XvMC was European digital TV" thats long past as the UK (sky),EU and far east moved
or are moving to AVC DVB containers, thats were you need to focus right now,"MBAFF and PAFF" and TS (transport stream) being the key
requirement right now as the major libavcodec/FFMPEG codebase that all the popular video apps use today doesnt do "MBAFF and PAFF"
or AVCHD to well today, and seriously needs to use hardware decoding programatical assistance ASAP, your key use of time right now
would be to simply work with and send in an AMD/ATI HD3650+ hardware patch to the developers at
http://lists.mplayerhq.hu/pipermail/...ry/thread.html developers message board
and sit back as that massive news hits the doom9 and other related message boards and people start downloading and using your ATI libarys
the very next day to add hardware assisted AVC,VC1, and even antiquated Mpeg2 decoding, and perhaps even Encoding and transcoding
into other containers etc....

put simply theres FAR MORE people intersted in ATI/AMD "MBAFF and PAFF",Decoding, ENCODODING, and transcoding to and from other containers
than anything you have written above, that is the focus you should be trying to gather interest around inside AMD/ATI circles with the
X1xxx/HD2/3650/4xxxx GFX cards capabilitys, WE need real working sample code for "MBAFF and PAFF" hardware assisted decoding patchs for
libavcodec at the very least.

a massive or even smaller but better than realtime code drop to the libavcodec/FFMPEG code base developers board
http://lists.mplayerhq.hu/pipermail/...er/018442.html
, not to mention the likes of http://www.kdenlive.org and ther linux video editing app thats trying to work with and find
working AVCHD HDcam support for editing could benefit massively if you just took the time to read up and help out TODAY, and make
AMD/ATI the talking point for weeks to come on the likes of the AVC focused http://forum.doom9.org/forumdisplay.php?f=77 threads
http://forum.doom9.org/showthread.php?t=143744&page=6 threads.

for to long the focus has been 3D with linux, wereas today it should really be GPU assisted video ENCODING and other related apps,
NV ARE taking the spotlight today because of that re-focus, and so your seeing the likes of ATI's
http://forums.amd.com/forum/categories.cfm?catid=328 being forgotten .part time coders want easy access to fully working
APIs that make todays HD video Encoding/Decoding work better and faster make that happen and go talk live and in person with them
on the message boards nad you will sell an lot of Gfx cards they can finally use, no matter what OS.


will you infact be including these essential MBAFF and PAFF decoder options in your base example code/apps.

http://en.wikipedia.org/wiki/H.264
"Flexible interlaced-scan video coding features, including:
Macroblock-adaptive frame-field (MBAFF) coding, using a macroblock pair structure for pictures coded as frames,
allowing 16×16 macroblocks in field mode (compared with 16×8 half-macroblocks in MPEG-2).

Picture-adaptive frame-field coding (PAFF or PicAFF) allowing a freely-selected mixture of pictures coded as MBAFF frames
with pictures coded as individual single fields (half frames) of interlaced video.
"

key points, you need to do a HW assisted GIT patched code drop to libavcodec, and include "MBAFF and PAFF" decoder options
therin, perhaps also AVCHD, and lossless Intra too, as per the latest x264 software freeware encoder etc....


as a side note to your assumed DVB Europe and the antiquated Mpeg2 you might want to read up on this.
DVB-SCENE27.pdf shows you the realitys of were its all going soon enough, and less than stadard H@L4.1, divx7 20Mbit max isnt it for your average end users paying the bills, and buying the kit to make your longterm profits, outside the US OC.

http://www.dvb.org/news_events/dvbsc...VB-SCENE27.pdf

page 4 of 16
"DVB-S2 Enables 140 Mbps Super Hi-Vision By Satellite At IBC 2008
Dr Alberto Morello,
Director of RAI Research and Technology Innovation Centre, Turin, Italy & Chairman of DVB TM-S2 Group

One of the highlights of this year’s IBC in Amsterdam is the first broadcast, live by satellite, of Super Hi-Vision (SHV)
using DVB-S2, from the RAI Research up-link station in Turin.

SHV, the 4000 line x 8000 pixels/line television system under development by NHK,"

Since the native SHV signal bit rate is a massive 24 Gbit/s, the major part of the challenge has been in developing technical ways of delivering the service to the final user. SHV is in our case compressed using MPEG-4 AVC at a final bit-rate of around 140 Mbit/sand delivered to IBC in Amsterdam from the up-link station of the research headquarters of Italian public broadcaster RAI in Turin, over Ku-band satellite capacity provided by Eutelsat.
"

[popper]

> > 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?

thats the day those USA people turn off analogue and start using Digital i assume!.

the US version isnt as popular as DVB-T and the rest of the DVB spec around the world today OC, and thats why when you talk about developers, you are forgatting almost everyone through nessesity are uing MS OS and NV freeware tools to make and process their DVB contained AVC Encodings....

the fact is as sad is it may be, unless AMD/ATI start helping out and encuraging (PPC) linux devs to start using the likes of the http://sourceforge.net/forum/forum.php?forum_id=764939

and http://forums.amd.com/forum/categories.cfm?catid=328
to write/port the required freeware Video apps and can help in the HW assisted "MBAFF and PAFF decoder options and AVCHD departments, we are not going anywere fast.....today.


and make it extreamy simple to use