A few questions about video decode acceleration

[Redeeman]

"Hmmm. Any chance you could post the log somewhere ?"
Ill see if i can get access to the box again.

"Tearing like "big ugly diagonal lines across the image" or tearing like "video not synced to vertical refresh" ? What vertical refresh rate are you running, and do you have vsync enabled (sorry I don't remember the exact option string)."
its sortof hard to explain, it looks like its synced to vsync, but then again, not, easy to explain, but its definetly not right. I did enable vsync and stuff. 60hz flatpanel output.

"Agreed; once you have the driver working on a distro for a few versions it will often tend do stay working, but it takes a bunch of testing/fixing to get there in the first place."
I dont believe its about getting it working on distributions, and then it continues to work, i believe its just about getting it working on specific software versions, like X and the kernel. Distributions change all the time, but the drivers really shouldnt care, like nvidia does not. On gentoo or slackware for instance, i could compile myself heaps of different versions of xorg, and it works with nvidia, i wish this too with fglrx(well, actually i dont much care, i just want the free drivers, and this problem goes away instantly.)

"I'm not sure. It used to with some drivers; don't know if FGLRX cares today. I believe that we set some defaults at install time depending on which card you have, ie 5xx and above cards default to textured video while earlier cards default to video overlay, there could be more serious ones as well."
now you are scaring me.. this should really not be done at build time, it _WILL_ cause problems.

"Our crash numbers on Windows tend to lower than most (frequently lower than anyone if you consider market share); not sure where the numbers are published but they probably make an interesting read."
Yes, as said, like 20-25% of crashes on vista, nvidia were like 40%+ - its a significant difference, but the numbers are still WAY too high for me being comfortable.. intel was a great deal lower than this.

[TechMage89]

Windows drivers are kind of messy because a large amount of the code goes in-kernel. Hopefully, Windows 7 should fix that, but you have to expect that the Windows graphical system will be less stable than the Linux graphical system.

[bridgman]

Nope, but i did read the xorg.log file, and it detected the resolution perfectly, it appeared from the log as if it tried to set the virtual screen size larger, however, it wasnt the virtual size being larger at all..

Hmmm. Any chance you could post the log somewhere ?

Tearing.

Tearing like "big ugly diagonal lines across the image" or tearing like "video not synced to vertical refresh" ? What vertical refresh rate are you running, and do you have vsync enabled (sorry I don't remember the exact option string).

I really dont think nvidia does testing on all these distributions, their driver just works with mostly all versions of X and the kernel, and thus works on all distros.."

Agreed; once you have the driver working on a distro for a few versions it will often tend do stay working, but it takes a bunch of testing/fixing to get there in the first place.

Nah, allthough installing fglrx before you insert the card, or after, shouldnt make a difference, should it? it does not for nvidia..

I'm not sure. It used to with some drivers; don't know if FGLRX cares today. I believe that we set some defaults at install time depending on which card you have, ie 5xx and above cards default to textured video while earlier cards default to video overlay, there could be more serious ones as well.

The numbers i saw there were vista only, but when the numbers were done on xp, ati was a large portion too, as was nvidia...

Our crash numbers on Windows tend to lower than most (frequently lower than anyone if you consider market share); not sure where the numbers are published but they probably make an interesting read.

[bridgman]

Is there a chart somewhere that shows which chips have which features

We're working on one so we can contribute some testing for the open source driver. We're producing it as an internal document but I think it would be useful as a wiki page as well.

> If we EOL the closed driver and focus resources on the open source driver
> you are going to get a very nice open source driver but you are *not*
> going to get the features and performance of the Windows driver. Ever.

Ignoring wintel features that are useless/stupid, why not?

Simple. By having common code between OSes we are able to get the benefit of development work done for those other OSes. If we had a Linux-specific open source driver then it would only get the benefit of Linux-specific development resources, which (because of market share realities) have to be much smaller. Having a much smaller development team means fewer features & less performance.

Closed source drivers are 100% useless. Document how to use the chip. Developers then write device drivers and other code (hopefully much of this can be shared across OSes). Users are happy.

Already doing that.

If the R600/R700 UVD isn't going to be documented, then put the R600/R700 at the bottom of the list, and concentrate on documenting *everything* (video decode, 3D, power saving modes, etc.) for Rage through R500, and on assisting developers with those chips. Once the open source drivers properly support these chips, then the users can go out and buy the chips. Then go back and try to find a solution to the UVD problem.

The R6xx family has the same video decode hardware as R5xx *plus* UVD, so I had assumed that users would want it on the list as well since it can do all the same video tasks as 5xx. What do you think ?

[Redeeman]

"Did we ever get an X log from your system ? That incorrect resolution sounds like a bad EDID read or something."

Nope, but i did read the xorg.log file, and it detected the resolution perfectly, it appeared from the log as if it tried to set the virtual screen size larger, however, it wasnt the virtual size being larger at all..

"What problems are you seeing with video these days ? The only one I'm seeing still is the video rendering figthing with conmpiz, resulting in flicker. "
Tearing.

"Agreed. Right now NVidia has a larger list of supported distros than we do. We can also fix this by testing on more distros and continuing to refine the install/packaging system, which is what we are starting to do now."
I really dont think nvidia does testing on all these distributions, their driver just works with mostly all versions of X and the kernel, and thus works on all distros.."

"I think you're also suggesting that you install the driver once then plug in different cards, rather than having the driver install on the card you plan to run with. Is that correct ?"
Nah, allthough installing fglrx before you insert the card, or after, shouldnt make a difference, should it? it does not for nvidia..

"Vista crashes doesn't mean linux crashes, if XP works, then it's a problem with the OS-specific parts"
The numbers i saw there were vista only, but when the numbers were done on xp, ati was a large portion too, as was nvidia...

[Dieter]

Chart with chips vs features?

Is there a chart somewhere that shows which chips have which features
(a) documented, and (b) open source code that works?

        Xv      Xvmc    ...
Rage
R100
R200
R300
...
R700

(I'm assuming that Rage is the earliest chip still being sold, right?)

> If we EOL the closed driver and focus resources on the open source driver
> you are going to get a very nice open source driver but you are *not*
> going to get the features and performance of the Windows driver. Ever.

Ignoring wintel features that are useless/stupid, why not?

Closed source drivers are 100% useless. Document how to use the chip.
Developers then write device drivers and other code (hopefully much of this
can be shared across OSes). Users are happy.

If the R600/R700 UVD isn't going to be documented, then put the R600/R700
at the bottom of the list, and concentrate on documenting *everything*
(video decode, 3D, power saving modes, etc.) for Rage through R500, and on
assisting developers with those chips. Once the open source drivers
properly support these chips, then the users can go out and buy the chips.
Then go back and try to find a solution to the UVD problem.

[some-guy]

Vista crashes doesn't mean linux crashes, if XP works, then it's a problem with the OS-specific parts

So (afaik) there a reasonably common codebase, and a OS-specific codebase, this should do modesetting, 2d, maybe video, and some of 3D, the rest (power saving, advanced 3D stuff, etc) is handled by the common codebase

[bridgman]

It's possible. I was told that the numbers were based on available market (ie all vendors combined) not just what we were selling, but I'll check. We can tap into marketing info for the CPU side of the business as well now, so that should also help.

[duby229]

The only point I would make here is that if you had bought a workstation (FireGL) card and plugged it into a PC running one of the supported distributions and ran a typical mix of workstation applications there's an extremely good chance that it *would* have worked very well. We included IDs for consumer cards but most of the testing was on workstation cards and apps.

What we started last fall was trying to extend that same support to consumer users, with a wider range of cards and distributions. Right now we're ramping up coverage on Ubuntu, for example.

Last time I looked at the numbers, if you considered market size, % using Linux, typical selling price, typical margin, and tendency to buy a new board rather than use retired HW from another system, workstation ended up at a bit over half of the total Linux desktop market (I'm not counting server here). I will take a fresh look at the numbers though...

The problem is that your looking at a catch 22 here.... Before ATi started this new code base, ATi users were stuck with 9250 Pros or less in order to get decent compatibility and performance. It wasnt until late last year when R300 and R400 started getting decent performance, and they still have a ways to go. R500 support was just announced this week, and R600 is just starting to be worked on...

The bottom line is that you need to have decent drivers before you'll sell the hardware, and all of the numbers you have are based on the --need-- for older hardware.

I think you basing critical decisions on faulty information.

[bridgman]

If you happen to run some magic SLED combination of patched weird versions of software.. I do not.

Well, not so much "patched wierd versions" as much as the "out of the box" versions our typical workstation customers run, but I understand your point

I do however find it relatively disturbing that it sets incorrect resolution, seems to be left in weird broken states by wine after it closes, requiring me to execute another opengl all (most seem to work, and then "correct" the issue).

Did we ever get an X log from your system ? That incorrect resolution sounds like a bad EDID read or something.

Video is still completely broken and useless in fglrx, and this is not just me having this issue.

What problems are you seeing with video these days ? The only one I'm seeing still is the video rendering figthing with conmpiz, resulting in flicker.

No, however i do find it to be of a very big concern, the amount of times "THIS" issue comes up, seriously, if you buy 10 pc's, install ubuntu, gentoo, sled, fedora, rhel, arch, debian, opensuse, slackware, mandriva. One distribution on each PC. Then insert an nvidia OLD to NEW card, and try the driver, i think you will find that their closed driver will work on all of them, without problems(well, except for the lousy quality of their driver), but now insert an old (say.. X300) to new (Say, 3870, let alone the X2's) in them, and attempt fglrx, well.. you are maybe looking at it working on 1 or 2 without tinkering, after tinkering, maybe 5 or 8, and 2 of them flat out not working with fglrx. This isnt a stability issue, but a serious compatiblity issue nonetheless, something the free driver will completely remove.

Agreed. Right now NVidia has a larger list of supported distros than we do. We can also fix this by testing on more distros and continuing to refine the install/packaging system, which is what we are starting to do now.

I think you're also suggesting that you install the driver once then plug in different cards, rather than having the driver install on the card you plan to run with. Is that correct ?