View Full Version : Avivo Linux R500 Driver v0.1.0 Coming
phoronix
07-10-2007, 09:20 AM
Phoronix News: Avivo Linux R500 Driver v0.1.0 Coming
Jerome Glisse has passed along word that version 0.1.0 of the Avivo Driver will soon be released. This open-source R500 and R600 driver for the ATI Radeon X1000 (and eventually Radeon HD 2000) hardware will have support for some shadow things and will be at least as fast as the VESA driver currently along with a few additional fixes. New PCI IDs for other Radeon R500 parts will also be added in Avivo 0...
http://www.phoronix.com/scan.php?page=news_item&px=NTg4MQ
yoshi314
07-10-2007, 02:55 PM
some shadow things? :D
shadowbuffer perhaps?
What is Shadowbuffer?
I am looking for AVIVO changes everyday and it seems to me that development is very slow at the moment and that only Jerome is developing it (from gitweb). But it also seems that they AVIVO is getting better when they already are as good as vesa and will continue with more features now.
PS: I bet that Fedora 8 will have this driver at least avaible after the fglrx issue they had with Fedora 7 :D
yoshi314
07-10-2007, 05:05 PM
well it was a closest thing involving shadow in the name.
shadowbuffering is a method of detecting 3d objects overlapping, but it's too early to implement it in avivo driver.
i'm not sure how quickly will they figure it out.
i'll have to review the r300 opensource driver development history, as it was a similar process (a bit rev.engineered, and a bit known (from previous generation specs) )
well if your card loves to lock up when it receives incorrect commands - figuring it out is not fast. that's what <=r500 cards do, and what r600 (and nvidia) supposedly don't.
if i were to rev.eng. such a nasty card - i would not make big progress quickly.
Michael
07-10-2007, 05:25 PM
Jerome called it "shadow things" so that is what was mentioned in the news posting :)
Jerome is quite busy right now with his masters thesis, but he is still getting some good progress done. I have been supplying him a number of dumps, etc.
AVIVO now supports nearly all cards (git) and more...
glisse
07-11-2007, 07:17 AM
well it was a closest thing involving shadow in the name.
shadowbuffering is a method of detecting 3d objects overlapping, but it's too early to implement it in avivo driver.
i'm not sure how quickly will they figure it out.
i'll have to review the r300 opensource driver development history, as it was a similar process (a bit rev.engineered, and a bit known (from previous generation specs) )
well if your card loves to lock up when it receives incorrect commands - figuring it out is not fast. that's what <=r500 cards do, and what r600 (and nvidia) supposedly don't.
if i were to rev.eng. such a nasty card - i would not make big progress quickly.
In our case its a lot more simple than that from vesa manpage:
Option "ShadowFB" "boolean" Enable or disable use of the shadow framebuffer layer. Default: on. This option is recommended for performance reasons.
Basicly there is a copy of the framebuffer in ram and all rendering happen in ram and only part that need to be updated are memcpy to VRAM. As currently there is no acceleration (blitting or filling) used in avivo this help a lot.
yoshi314
07-11-2007, 07:52 AM
In our case its a lot more simple than that from vesa manpage:
Option "ShadowFB" "boolean" Enable or disable use of the shadow framebuffer layer. Default: on. This option is recommended for performance reasons.
Basicly there is a copy of the framebuffer in ram and all rendering happen in ram and only part that need to be updated are memcpy to VRAM. As currently there is no acceleration (blitting or filling) used in avivo this help a lot.
i read it somewhere in irc logs some time ago, and i just couldn't recall that name. so my mind jumped into shadowbuffers, somehow :]
my bad.
chrisr
07-11-2007, 09:36 AM
I've just bought a Thinkpad T60p Widescreen laptop with a Mobility FireGL V5250 chip (M56GL, I think), and was very annoyed to discover that the fglrx driver is currently incompatible with Fedora 7. So seeing as I'm stuck using the Vesa driver at ATI/AMDs pleasure, the Avivo driver doesn't have a particularly high hurdle to leap for it to become my new default.
All Avivo needs to do for me right now is:
a) Support the native 1680x1050 resolution. The VESA driver is limiting me to 1400x1050, so the screen looks stretched slightly horizontally. Doesn't 1680x1050 count as a "VESA-compatible" mode, or something? The log suggests that DDC is providing the correct mode-lines.
b) Be as fast as VESA
c) Not crash ;-)
d) Provide DPMS support so that the backlight can be powered down.
I'll probably provide radeondumps just as soon as I get fglrx working too.
chrisr, just hold on a week.
yoshi314
07-11-2007, 10:27 AM
i wonder how is ati going to react to this. people are definitely more enthusiastic towards new driver, than they ever were towards fglrx :]
avivo driver might become serious competition for their fglrx someday (which doesn't seem that hard ;-) ). nvidia decided not to help and not to interfere with nouveau. i wonder what does ati will ati say about avivo once it matures a bit.
sundown
07-11-2007, 04:13 PM
i wonder how is ati going to react to this. people are definitely more enthusiastic towards new driver, than they ever were towards fglrx :]
avivo driver might become serious competition for their fglrx someday (which doesn't seem that hard ;-) ).
I'd say neither will live up to my expectations.
chrisr
07-11-2007, 04:43 PM
i wonder how is ati going to react to this. people are definitely more enthusiastic towards new driver, than they ever were towards fglrx :]
The current Open Source radeon drivers still don't support things like hardware-accelerated DVD playback (XvMC) even though cards as old as the Radeon 9200 are capable of doing so. And there's TV-OUT support, too. So I don't think ATI are going to be worried for a long, long time.
yoshi314
07-11-2007, 05:21 PM
The current Open Source radeon drivers still don't support things like hardware-accelerated DVD playback (XvMC) even though cards as old as the Radeon 9200 are capable of doing so. And there's TV-OUT support, too. So I don't think ATI are going to be worried for a long, long time.
of course not. but i wonder what happens in the long-term. well they don't really have a basis to push out CoD letters or similar actions.
version 0.1.0
I misread this for a split second as "version 1.0".
Hah! Wishful thinking. :)
Michael
07-14-2007, 09:28 AM
The current Open Source radeon drivers still don't support things like hardware-accelerated DVD playback (XvMC) even though cards as old as the Radeon 9200 are capable of doing so. And there's TV-OUT support, too. So I don't think ATI are going to be worried for a long, long time.
ATI/AMD probably won't be frightened for a long time.
yoshi314
07-15-2007, 03:29 PM
i really hope that they don't try to interfere.
Michael
07-15-2007, 03:38 PM
i really hope that they don't try to interfere.
While they don't support the driver by offering up developers or specifications, they will not interfere or try to bring down the Avivo driver. Their server integrated chipset is to the extent that they support the open-source Radeon driver, but it was an AMD developer who had added the initial RS400 series support to the Radeon driver and they do some other things as well. In the (unlikely) event they get any crazy ideas to interfere with the Avivo driver, I would personally interject and raise hell with them.
chrisr
07-16-2007, 05:04 AM
In the (unlikely) event they get any crazy ideas to interfere with the Avivo driver, I would personally interject and raise hell with them.
No offense, but is there a reason why ATI would listen to you if you did :confused: ??
chrisr
07-16-2007, 05:10 AM
Suppose I owned an R200 card and wanted to use its XvMc functionality. Is there anything I could do to get the ball rolling, please? (I have an LCD monitor - the most recent version of fglrx that supposedly supported R200 just resulted in a blank screen.)
And is there anything I could do to ensure that my R530-based laptop's XvMC capability doesn't languish too?
Michael
07-16-2007, 09:28 AM
No offense, but is there a reason why ATI would listen to you if you did :confused: ??
If I created a public firestorm with the millions of readers that Phoronix has, yes.
yoshi314
07-16-2007, 09:47 AM
If I created a public firestorm with the millions of readers that Phoronix has, yes.
talk about modesty. :]
if i were you i might risk saying "thousands".
no need to go down that road..
Every bit helps, don't underestimate the power of the press. OK don't over estimate it either .. :-)
But sure as hell no need to bicker amongst ourselves; I'm pretty sure that ATI/AMD want's all the customers it can get. Not being Evil is a large part of the corporate image.
And i'm pretty sure phoronix the reference when it comes to linux hardware.
Everybody with ati/amd hardware's patience has been tried time and time again. for the past 6months it this hype "just hang in there a little longer" has been maintained by phoronix, i'm pretty sure that if even
phoronic/Michael don't believe in it, we sure as hell wont either.
I wonder how much "if you want to use beryl/compizFuzion, don't buy an ati card" has already cost AMD. I'm pretty sure it's more than I make a year.
And euhm if Michael posts a harse provocative news worthy comment against ati. It will end up on slashdot/digg/.. and I'm pretty sure it'll reach many eyes.
I almost forgot... GO AVIVO, keeping an eye on developments i'll probably start running it soon
chrisr
07-17-2007, 09:17 AM
But sure as hell no need to bicker amongst ourselves;
???????????
Michael
07-17-2007, 09:31 AM
Someone has setup a Digg link: http://digg.com/linux_unix/HOORAY_New_opensource_already_beating_official_dri ver_Avivo_vs_Fglrx
yoshi314
07-17-2007, 10:54 AM
i wonder how is ati feeling about this :]
I don't know if Phoronix has millions of readers but it is the reference for all fglrx related things and everyone knows that, even AMD.
Michael
07-17-2007, 12:01 PM
I don't know if Phoronix has millions of readers but it is the reference for all fglrx related things and everyone knows that, even AMD.
We have over 100 million hits annually.
yoshi314
07-17-2007, 01:20 PM
are those unique hits?
Michael
07-17-2007, 01:25 PM
are those unique hits?
That is roughly our total hits. I don't have the latest numbers in front of me right now, but you can also see our Alexa rankings at: http://alexa.com/data/details/traffic_details?url=phoronix.com
That's pretty impressive, Michael. I guess the advertising will be enough to pay the server's cost :D
Tremendous work, I was expecting the Nouveau driver before the Avivo one, but perhaps the ATI one is the most urgently needed of course ;-).
So much for bashing fglrx drivers, they are after all not that bad as much they are cursed for :p. Yes, it gives 50% performance of the hardware's capability, but it more or less works stable ;-). Aside, its not just Linux, ATI's performance in OSX is equally horrible :D. My sister has a iMac with a x1600, on which doom3 @640x480 gives about 50 fps in OSX, a little better in linux (55fps or so, and a little smoother too - it feels like fps is capped or something ;-) and 120 fps in windows xp. I wonder if iMac users with ati cards have ever bothered cribbing :p.
Meanwhile, XGL does work fine and stable with fglrx (no 3d of course). Even on a modest radeon 200m, its pretty good. On another note, the image quality of fglrx drivers is pretty good too :). Also, I am tempted to say that perhaps X-effects are broken on almost every graphics hardware :o. ATI - no need to mention. Intel - AIGLX is apparently fluid smooth on a 915/945+ say, but I get pretty nagging artifacts when I play video. (Or I might need some work arounds I guess). Smoothest and perfect on Nvidia cards, but people seem to have the turbocache blacking issues after long time. Atleast I must say 'it works' in case of Nvidia.
PS : After seeing the gtkperf benchmark (never heard of it before :), I installed it and was happy to see it giving 160 seconds on the geforce 7400 go in my notebook :). Btw - were the tests performed in that same small default window or full screen ?
yoshi314
07-19-2007, 04:20 AM
Aside, its not just Linux, ATI's performance in OSX is equally horrible :D. My sister has a iMac with a x1600, on which doom3 @640x480 gives about 50 fps in OSX, a little better in linux (55fps or so, and a little smoother too - it feels like fps is capped or something ;-)hmm could it be that these cards are designed primarily with directx in mind?
just a random thought.
Michael
07-19-2007, 08:50 AM
PS : After seeing the gtkperf benchmark (never heard of it before :), I installed it and was happy to see it giving 160 seconds on the geforce 7400 go in my notebook :). Btw - were the tests performed in that same small default window or full screen ?
Default. The only change was setting the number of times to 1,000.
Meanwhile, XGL does work fine and stable with fglrx (no 3d of course). Even on a modest radeon 200m, its pretty good. On another note, the image quality of fglrx drivers is pretty good
strange world you live in. If you don't mind random crashes and the accompanying loss of data.. and various other bugs.
and Xgl is quite dead as codebase too iirc. Other than showing of beryl (and hoping) Xgl is no good.
There really is no point in trying to see the glass as half full, we all know it's nearly empty.
imho.
Michael
07-22-2007, 06:08 PM
There really is no point in trying to see the glass as half full, we all know it's nearly empty.
While the glass may not be full of water, there is a water truck on the away.
And when the truck arrives, it may has overhauled the competition.
Okay that's enough. It sounds philosophic and I don't like that. What I mean is that GF8 has not the full performance on Linux at the moment, so AMD could beat nVidia. That would be funny cause people would laugh at you if you would tell them that your fglrx driver is faster then the nvidia driver.
yoshi314
07-23-2007, 03:49 AM
What I mean is that GF8 has not the full performance on Linux at the moment, so AMD could beat nVidia.i wonder who's primarily to blame for poor gfx performance on better cards - driver programmers, hw engineers, or perhaps linux kernel hackers?
The guys that don't want more driver developers because they cost money.
glisse
07-23-2007, 10:11 AM
i wonder who's primarily to blame for poor gfx performance on better cards - driver programmers, hw engineers, or perhaps linux kernel hackers?
My opinion on this is that DRI/DRM needed some work especially on memory management and once we got memory management properly working and cleverly used i am sure we will have a speed boost (ie at the moment all vertex are memcpy at least once when program render anythings and this is costly, with proper memory management we should not need anymore to memcpy this). There are other bottleneck like some GL stuff which are not handled well enough currently (enemy territory use some of this). Anyway there is work underway to address most of pitfall of current open source driver. What is hard is that we need to keep backward compatibility so we endup doing crazy things just to make sure we do not break old things (new drm should work with new Xserver, new Xserver should work with old drm, new dri driver should work with old drm, ...).
yoshi314
07-23-2007, 10:28 AM
There are other bottleneck like some GL stuff which are not handled well enough currently (enemy territory use some of this). Anyway there is work underway to address most of pitfall of current open source driver. What is hard is that we need to keep backward compatibility so we endup doing crazy things just to make sure we do not break old things (new drm should work with new Xserver, new Xserver should work with old drm, new dri driver should work with old drm, ...).how can one identify bottlenecks in video card driver? i always thought it's nigh impossible.
is it mostly guesswork, or are there actual tools for the job?
While the glass may not be full of water, there is a water truck on the away.now that i think about it, why do we need a whole truck to fill a glass? :>
edit:
on the away.
on the away...ohh, i get it now.
glisse
07-23-2007, 10:49 AM
how can one identify bottlenecks in video card driver? i always thought it's nigh impossible.
is it mostly guesswork, or are there actual tools for the job?
Using a profiler will give place where we spend time and then we can look and check how we can improve this (ie on r300 oprofile shows that we loose lot of time uploading vertex: no memory managment) then we can also hook some performance counter in the driver to see how much time it takes to do somethings like uploading texture or others things. Last things hw have performance counter register to help find out how to optimize things for the card (unfortunately we don't have any informations on this registers anyway today most of the slowdown is in the software driver). Last tools are things like gldebugger.
vBulletin® v3.7.4, Copyright ©2000-2009, Jelsoft Enterprises Ltd.