"Ask ATI" dev thread

[hmmm]

If you guys come up with the questions, I will get the answers - Michael

Post any questions that you have for ATI fglrx devs here...

[yoshi314]

how can you guarantee any ati dev will answer them?

all i care about is : (not really to the devs)
> when can we expect the rest of the docs?

[d2kx]

What would be most interesting is "what are you working on for the next releases?", but they won't answer that.

[hmmm]

What apps/tools/games do the devs use for testing regressions and speed? In particular, has there any testing of wine wrt the awful performance noted by wine devs More like your video drivers broken / misconfigured. ATi's craft known to by
buggy beyond repair.
from http://bugs.winehq.org/show_bug.cgi?id=10487

Any likelihood of AVIVO support?

[ZedDB]

I wonder if there is any plans on having hotfixes in the future. For like bugs like soname and the memleak...

[Uchikoma]

My only question to the developers:

Are you aware of the existing memory leak in 8.41, 8.42 and seemingly fglrx 7.11?

That's about it. Xv works fine for me, as does all the other features I use. I just want to know that they know about said (fatal) memory leak.

[Kano]

Besides other stupid issues with the driver: why are the FireGL ids removed when they could be patched back easyly? I think it should be the users choice which driver they want to use - even buggy ones. And another one: why not use lzma compression? I have sample scripts that can already repack any driver (with static decoder) and its size drops dramatically. Example:

47667647 (100%) ati-driver-installer-7-11-x86.x86_64.run
28335222 (59%) ati-driver-installer-7-11-x86.x86_64.run.lzma-static-decompressor

[hobophobe]

Why do the KB numbers in the driver's release notes not directly link to the KB articles?

Why is the card state (sometimes?) not reinitialized on reboot:
1. related to the vesa framebuffer console bug, when I reboot (via ctrl+alt+del) sometimes the 'dead' state that caused me to need to reboot persists forcing another restart
2. possibly X.org's fault(?) upon reload of X.org/gdm I see a garbled version of the previous state of the screen (ie, what was shown before the reboot), then it loads as normal. Contrasted with windows where that doesn't happen. This happens in versions of the driver with or without the vesa framebuffer issue.

How does the driver team ascribe priority to what will be developed in each release?

What code management do they use and are team members allowed to keep private branches in order to target specific issues (like new kernel or X.org support)?

Related to ZedDB's question:
Are the devs regularly frustrated by having fixed issues but not being able to push them out to their users because of the dev cycle (or other restrictions) imposed by management?

How much easier would development be if there were lower-end GPUs targeted specifically for linux (similar to the Intel GPU offerings)?

[yelo3]

Simple question:
do you know of this bug? or you think you have fixed it as you've written in the release notes of 8.37.6?

bug link: http://ati.cchtml.com/show_bug.cgi?id=239

[Compxpert]

Question:

You just released the most useless driver update ever...
How does that make you feel?

Real/other question: Are you aware of the other MORE important bugs that need fixed like the memory leak?

[Malikith]

Yeah, I got a question for ATI, what do they smoke? What do they do 8 hours a day 5 days a week and release a 3 bug fix release on the most simple things that could possibly be added to a release. I like AMD, I really do, but with all the outstanding issues and bugs in fglrx, they could only manage to fix 3 extremely minor issues over the course of a month?

I don't care if you have 1 or 3 guys working on that driver, 8 hours a day, 5 days a week, you can accomplish alot more than that. I almost think they are playing ping pong in the office. Going around with beer bongs and getting completely wasted then they sit down and well.. Okay! Time to get to work! Lets see... Oh yeah, we need to add 2.6.23 kernel support, okay, that should take us about a month to add that.

Now, you can say, well they are preparing for the now called 7.12 driver, I think thats bogus. So they're going to have everyone wait yet another month and don't even fix at least one major issue? We aren't concerned with new features at this point, we really could care less, we want bug fixes, and stable drivers. Something we honestly never had. Yeah now they can run pretty fast when they want to, but that doesn't solve the issue.

Alright I'm done venting. I still have faith in AMD, and we better see some decent results in the releases to come since they are hiring more people for their Linux driver development. Because if we see another release like this, I'm going to hold my end of the bargain and give Phoronix a video called "What happens when you have a ATI card and a baseball bat?". You want action, I'll dish it out in full. Haha.

Alright well anyway, I hope to see better releases from them in the future, this release was a joke. I think at this pace, the Open Source driver will pass fglrx in about a year to year in a half from now.

[ivanovic]

@Malikith:
Did it ever come to your mind that there might be fixes, that are not listed in the changelog? I do know that *many* devs are rather sloppy when it comes to writing down the real changes for mundane stuff like a "changelog".

The problem is that users do not have a way to check if their problems are fixed when the changelog is this incomplete. I think one of the main problems AMD/ATI had so far was communication with the community. But I think the posts from Bridgman indicate some change in that area. The real things I would love to know are simple:

- Will there be an official bugtracker that gets frequented by the devs so that users do have a way to see if their problems are fixed?
- Will there eventually a more complete listing of the fixed/known problems? Currently the list is really abysmal.

[yoshi314]

Did it ever come to your mind that there might be fixes, that are not listed in the changelog? I do know that *many* devs are rather sloppy when it comes to writing down the real changes for mundane stuff like a "changelog".i'd rather see super-detailed changelog even if it would contain boring stuff. they must have some SCM for their code - see how easy it is to make a detailed linux kernel changelog without too much work.

the only explanation for me is - they still have tons of problems with the new codebase, and trying to get it to compile (oh, and work :D) takes lots of time.

[macmus]

the only explanation for me is - they still have tons of problems with the new codebase, and trying to get it to compile (oh, and work :D) takes lots of time.

i think they are reverse-engeenering the nvidia driver trying to tailor it for ati card, cause i seriously doubt they realy can come up with they own bugfixes ..

[fettouhi]

I would like to know why the new driver (8.43.3 & 8.42.3) makes the screen go black for 2-3 secs when you start a video file (with or without compiz)? Is the driver switching screens when I runs a video?

Regards

André

[kirù]

I would like to know if you really are devs

[mal13]

When do we start to get official support for Ati linux users?

Why don't you make install packages available as .DEB AND .RPM's??

[gorgorbay]

I heartily agree with Malikith's post.

Here are my questions:

* Why is there no real customer support for fglrx? (bug tracker, official forum and so on) and why does ATI people answer to me when I point one of their driver's shortcomings, "ask the linux community".

* Are ATI linux users one day going to be considered with respect? a decent driver would be the first step towards that.

* Why should I keep my current Radeon HD 2600 and not buy a nVidia card instead? Indeed, your drivers don't provide full support to linux applications (some as old as tvtime) and you are absolutely silent as per when proper support will be available (there I re-join Malikith and his urge for baseballing his GC)

[platform]

* Why is there no real customer support for fglrx? (bug tracker, official forum and so on) and why does ATI people answer to me when I point one of their driver's shortcomings, "ask the linux community".

This is not really specific to ATI but a lot of other companies do this too. This is just a nicer way of saying "we don't really care about your problems because you are not using Windows, so sort them out yourself". This becomes really annoying when the problem is in a binary driver or in the device itself.

[metala]

i'd rather see super-detailed changelog even if it would contain boring stuff. they must have some SCM for their code - see how easy it is to make a detailed linux kernel changelog without too much work.

the only explanation for me is - they still have tons of problems with the new codebase, and trying to get it to compile (oh, and work :D) takes lots of time.

I'm PHP devel, and i wouldn't make even changelog, there is a general TODO list, and finished list, and some colors (dokuwiki). No bug tracker, nothing like that, cause it needs time the idea to hit you into the face, and if you comment everything, you will loose the trail. I would rather write about general things done, and this thing that were difficult to resolve.
Said short : Writing every change, makes you loose focus on the project. Wasting of time.

[Kano]

Well I would not require changelogs if the problems just would disappear ;) Some problems exits for years (like ModeLine bug), some since a few releases (like Xserver 1.4 problems) and I am 100% sure the dev know about em... So the question is: are these bugs unsolveable for ATI or not?

[metala]

Agreed.
They should be in two groups of devels.
The first group to "get inside the code" and to fix old and/or important stuff.
The second to implement new features, and for everything to consult with the people that "are in the code", that "can think like the driver", to have best implemented feature.

[sabriah]

If you read forums like these, how come you don't ask people to "s*** *** **** up"?

[Snake]

The current technical issues set aside, my biggest question is why on earth AMD/ATI does not pay more attention to what the users report on the "inofficial" bug tracker (http://ati.cchtml.com) :confused:

I do understand that

devs like to avoid the stress of arguing with users
(judging by the style of some posters here I don't even dare to imagine what would happen as soon as the first bug is set to CLOSED/WONT FIX :D)
devs like to avoid being threated with metrics like "average fixed bugs per time unit" ;)
depending on "culture" a company may find having a public list of "confirmed" bugs embarrassing


However, users do look at the bug tracker as soon they have problems. And as the bug tracker currently seems rather "unmaintained", they find lots and lots of "unresolved" bugs there, although IMHO many of them are actually INVALID, DUPLICATE, FIXED or at least WORKAROUND.

I bet the net result means more damage to the AMD/ATIs image than if they would simply "admit" the real bugs and close the others.

And with regards to the real bugs, many posters here seem to have really good technical skills. AMD/ATI could gain a lot of "hard facts" by "arguing" with them, or even provide a "please try this and report back"-patch now and then (possibly per private mail).

Even if the devs choose not to use the bug tracker themselfs, we (the users) would greatly benefit from concise and up to date bug reports. But of course it would be nice to see a "official" reaction now and then, just to fight the feeling that no one cares anyway.

BTW, who is the admin of http://ati.cchtml.com/ ? Perhaps some of us could join and have a "squash the bug" day, to at least close or consolidate the most obviously obsolete or duplicate reports?

[daniel of sarnia]

I'd just like to know when they expect this driver to become stable a feature complete.

Oh and a side note, I fix/build computers for all my family and friends and as a job to pay for school. Since I spent $500 on an ATi card that has been garbage in Linux I have not put one ATi card into another computer and strongly recommend to everyone I know or work for not to buy them. I'm sure there are a lot of other people here that have done the same. That's what happens when you alienate your most technical users. The people around them that get help from or employ those technical people will do and buy whatever they say, weather or not they run Linux, Windows or Apple.

/rant

[Malikith]

@Malikith:
Did it ever come to your mind that there might be fixes, that are not listed in the changelog? I do know that *many* devs are rather sloppy when it comes to writing down the real changes for mundane stuff like a "changelog".

Yeah, and I know there was some "minor" improvements that weren't mentioned in the change logs, but nothing that made or broke the driver, well, its been broke forever so I guess thats not really a option.

If what you say is true and the ATI devs are so lazy to put down more than 3 fixes in their changelogs, those guys are some of the laziest people I have ever seen.

Heres my point, lets take a look at the 7.11 Linux Release Notes:

Resolved Issues

The following section provide a brief description of resolved issues with the latest version of the ATI Catalyst™ Linux software suite. These include:

* Launching a new terminal un RHEL5 32bit version no longer results in an inconsistent background colors appearing each time the window is minimized and maximized
* The kernel module is now working on kernel version 2.6.23
* An error message no longer appears during installation if dash is used as /bin/sh

Alright, we know those release notes very well for resolved issues, now, lets take a look at the Windows ones real quick.

Resolved Issues for the Windows XP Operating System

This section provides information on resolved issues in this release of the ATI Catalyst™ Software Suite for Windows XP. These include:

* Enemy Territory: Quake Wars: Corruption is no longer noticed with the use of rectangle textures. Further details can be found in topic number 737-29954
* Enemy Territory: Quake Wars: The game no longer fails to respond when triple buffering is enabled. Further details can be found in topic number 737-30544
* Unreal Tournament 2004: Enabling CrossFire™ followed by attempting to change the in-game display resolution no longer results in a loss of vsync. Further details can be found in topic number 737-29950
* On certain products, dragging player window from the primary to the secondary display no longer results in hardware acceleration being disabled which resulted in the CPU usage increasing. Further details can be found in topic number 737-28516
* With some h.264 titles that have MPEG2 introductions; playback no longer switches from hardware accelerated to software once the introductory content is finished. Further details can be found in topic number 737-28517
* With some h.264 titles that have MPEG2 intros, playback no longer switches from hardware accelerated to software once the introductory content is finished. Further details can be found in topic number 737-28517
* Enabling extended desktop mode following by launching the Windows Media Player no longer results in the player failing to appear on the secondary display device in full screen mode. Further details can be found in topic number 737-29555
* The CrossFire™ option found in the Catalyst™ Control Center is now available on systems containing an ATI Radeon™ X1800 series of product and running the Windows XP operating system. Further details can be found in topic number 737-30010
* Users running Windows XP on a system containing an ATI Radeon™ HD 2600 no longer experience a drop in performance from single card mode to CrossFire™ mode when software CrossFire™ is enabled in certain applications. Further details can be found in topic number 737-29980
* Pressing the power button to resume from an S3 state no longer results in only the mouse cursor being visible and the screen remaining blank until the mouse is moved. Further details can be found in topic number 737-29948
* Dragging the WinDVD player from the primary display to the secondary display no longer results in the player failing to respond. Further, closing the WinDVD player using the Task Manager may result in the operating system failing to respond. Further details can be found in topic number 737-29955
* Enabling extended desktop mode and dragging the PowerDVD window to the secondary display device no longer results in the PowerDVD window becoming black with only the audio being heard. Further details can be found in topic number 737-29952
* Catalyst™ Control Center: German character are no longer truncated in the Profile Manager Applications tab. Further details can be found in topic number 737-29930
* Connecting a Dell 30" LDC display device to an ATI Radeon™ HD 2600 series of product no longer results in flashing or no display image. Further details can be found in topic number 737-30545
* Corruption is no longer noticed when enabling Theater mode and enabling clone mode. Further details can be found in topic number 737-30546
* The Enable ATI OverDrive™ clocks for 3D applications only checkbox is now checked and grayed out when the OverDrive™ option in the Catalyst™ Control Center is unlocked. Further details can be found in topic number 737-30600
* Ending playback of a Blu-ray title followed by toggling the CrossFire™ settings (on or off) no longer results in the Windows XP operating system failing to respond. Further details can be found in topic number 737-30543
* Enabling CrossFire™ and setting the display resolution to 2560x1600 no longer results in HD DVD titles playing back as if in fast forward mode when using a Cyberlink player. Further details can be found in topic number 737-30530
* Corruption is no longer noticed when dragging a window across the desktop edge in four monitor configuration under Windows XP. Further details can be found in topic number 737-30531
* Connecting a single display device to a secondary graphics adapter no longer results in extended desktop mode being applied. Further details can be found in topic number 737-30538
* Playing the online game TianLongBaBu for an extended period of time (2 hours or more) on a system containing an ATI Radeon™ HD2400 or HD2600 no longer results in the operating system failing to respond. Further details can be found in topic number 737-30542

And thats not even all the fixes in their release, thats just the Windows XP Fixes, they got more for Vista too. I understand the Linux team is a little understaffed, but if they REALLY did fix more than 3 things, at least they could jot it down because in the Windows release notes, they put it every single detail for the most part. So if there is anything I want to see in the future, and that is more in depth release notes, either that or they really didn't actually fix some of the things that weren't listed and instead were just magically fixed.

[butdie]

while their fglrx (aha, renamed now) have driven enough number of linux users away.

The shitty GPU driver would hurt their CPU business for sure.

at least, I have no interest in amd cpu any more. I have to admit that I was an AMD fan, I ordered 64+ CPUs for work and even bought an anthlon-mobile laptop for myself(bad choice indeed).

many reasons for not touching AMD anymore, but fglrx is just the last straw.

I'd just like to know when they expect this driver to become stable a feature complete.

Oh and a side note, I fix/build computers for all my family and friends and as a job to pay for school. Since I spent $500 on an ATi card that has been garbage in Linux I have not put one ATi card into another computer and strongly recommend to everyone I know or work for not to buy them. I'm sure there are a lot of other people here that have done the same. That's what happens when you alienate your most technical users. The people around them that get help from or employ those technical people will do and buy whatever they say, weather or not they run Linux, Windows or Apple.

/rant

[mlau]

Malikith:

Also note that the windows changelog almost exclusively
mentions games (In fact I believe the windows driver
team at ati only fixes games and hardly anything else,
because in my experience 3D performance is very crappy
if app!=game [or one of a few select CAD tools], and display
configuration leaves a LOT to be desired even in
windows)

The linux team surely has completely different goals.

[rdvaughan]

Post any questions that you have for ATI fglrx devs here...

Please ask the developers for:
1) Better aticonfig documentation for “--validate-cvmode” argument including a few examples. Examples are the most important.
2) A “xorg.conf” file for a working component video configuration. (e.g. crt1 and a component video 1280x720p@60Hz HDTV output)
3) Does the current driver (7.11) have component video working even if the HDTV monitor does not return EDID information of the HDTV's acceptable formats (e.g. 720p, 1080i ... etc)?
4) Is there any way to force HDTV formats into the Catalyst Control Center for selection?
5) Please add the abilty to aticonfig or the Catalyst Control Centre to force display on to a digital TV (HDTV) as is available under ATI's Windows utilities.

Thanks

P.S. - Feel like I am making a list for Santa. :)

[Karel]

I love the topic, I think it sums up a lot of things.

Spot one difference:

"Ask ATI" dev thread



"Ask ATI" devs thread.


There is nothing else to be added. Maybe one question for the (only) ATI Linux driver developer - is it part-time job or are you from other department, just assigned to Linux for one afternoon per week?

[mirv]

One for the ati devs: with OpenGL 3.0 currently being formed, are the devs starting to look at that, or is it a case of "wait until the specs are out"?
And a completely random question: what do you usually have for lunch?

[Alexander Heß]

It may be wishful thinking, but it could be possible that the devs (I can't imagine there is only one developer working on fglrx) are working on something bigger like adding “real” FireGL support which probably isn't done in a month.

This month they released just a driver with the small fixes they could do besides the big stuff to satisfy their “a driver a month” release cycle.

[Tillin9]

Questions:

1) Are you aware of the artifacts in many programs (ivview, as of 8.42 now glxgears, fgl_glxgears) with R300 cards and are there any plans to fix this bug? This was originally only a bug with FSAA in 8.28, but with every revision it seems to get worse.


2) When do you think the R300 3D specs will be released to the DRI project?

I agree with a lot of the sentiment that the release quality seems to be going downhill.

[Snake]

Question:

Dear dev(s), will you ever answer to any question posted here? Or at least have Mr. "Deep Throat" speak to us unworthy morons?

[DarkFoss]

Is it possible to have a complete list of aticonfig options..so far with the new drivers several are depreciated.
(WW) fglrx(0): Option "NoTV" is not used
(WW) fglrx(0): Option "FSAAEnable" is not used
(WW) fglrx(0): Option "FSAAScale" is not used
(WW) fglrx(0): Option "DMAMode" is not used
(WW) fglrx(0): Option "DynamicClocks" is not used

Thats all I've found from my old xorg files so far.
*edit 2 more
(WW) fglrx(0): Option "EnablePageFlip" is not used
(WW) fglrx(0): Option "ColorTiling" is not used

[Snake]

Is it possible to have a complete list of aticonfig options..so far with the new drivers several are depreciated. ...

Personally I prefer to have as little fglrx options set as possible, as for me it seems to work best with most left with their default values.

But perhaps more important: I found that the "old" way setting options via hacking the xorg.conf does not always work. Most (all?) of the driver options are (must be?) also mirrored in /etc/ati/amdpcsdb to take proper effect. This is what aticonfig does automatically, so I stick with the options provided there (see "aticonfig --help").

Currently these are (8.42.3 / X1400 with XOrg 7.2 on Gentoo):

aticonfig --overlay-type=Xv --tls=1 --max-gart-size=256

This corresponds to the xorg.conf options "VideoOverlay", "OpenGLOverlay", "UseFastTLS" and "MaxGARTSize" being set. And thats all. Additionally I commented out my whole "Module"-Section, as the XOrg defaults work fine for me here, too.

The only non-standard option is "XaaNoOffscreenPixmaps" set to "on" in my "Screen"-Section (IMHO this option does not apply to the "Device"-Section as stated elsewhere, see "man xorg.conf"). On my HW this prevents the infamous artifacts around the cursor and in the lower right corner from appearing.

[theotherme]

My only question is:

Why must you torture us linux guys month after month? :(

Thank you in advance.

[x86xlat]

What about ARB_texture_non_power_of_two? glxinfo says that we've got OpenGL 2.1 (on 8.43 or 7.11), but NPOT textures are part of GL2.0...

[hmmm]

Intervieew with AMD's Bridgman from Beyond3d:

http://www.beyond3d.com/content/interviews/43/

[d2kx]

Intervieew with AMD's Bridgman from Beyond3d:

http://www.beyond3d.com/content/interviews/43/

Great interview, thanks for the link!

[Michael]

Bump, since it looks like there will be a Q&A in January...

[Svartalf]

One of the questions I have for the devs would be how long have you been doing Linux driver development?

Do you know of the very useful Linux based debugging tools available such as Valgrind and Oprofile that can help you find most of the performance, memory loss, memory corruption, and wild pointer problems within the OpenGL and other code cores for Linux and indirectly for Windows?

[mirv]

How has the workplace changed since amd took over? (that's a very broad question I know...things like is there better communication between management & devs, do you have more resources at your disposal, etc)
What's your favourite linux distro / which one do you use at home? at work?
Are there feature deadlines? Or is it just "when it's done"?
Which tools do you use? e.g eclipse, or just use emacs/vim/pico and command line?
Is there any sort of push to 64bit, or does it sit primarily with 32bit? Or does the new code base allow equal doses of each?
and I put this in the last post I made in this thread, but still:
what do you have for lunch?

[mlau]

Do you intend to support other archs in future?
Currently only x86/x64 is supported; however there are lots
of other archs with pci/pci-e and working linux support
(ppc, mips, sparc, alpha, i even think there are arm's and SH's planned with
pcie)

[val-gaav]

all i care about is : (not really to the devs)
> when can we expect the rest of the docs?
I second that. I would love to see a almost complete radeonhd driver on summer 2008.

[werdz]

Will there be a documentation release any time soon for the R300/R400 parts? I have a mobility X700 in my laptop - the fglrx driver can't (and never could, ever) suspend and wake up again successfully. The radeon driver can do it perfectly, but it has an odd bug that causes X to freeze up at random. Both seem to be terrible at power management. I have a suspicion that proper documentation would help the radeon dev team to solve the last two problems.

Is there any concept of a "blocker" bug prior to the release of a version of fglrx? I.e. how big does a bug have to be before it means delaying a driver?

Do any of you have nvidia cards in your PCs at home? Would you recommend them? :p

[hmmm]

Fusion - will you release it along with open source drivers or documentation beforehand to at least prepare the radeonHD for it?

How are you/ will you go about the driver design/development for fusion?

Will you rebase the fglrx's on the radeonhd base? Is it being considered for the not-too distant post 3d radeonhd future?

Do you have clear idea of how you want the fglrx's to evolve - or is it jst bugfix - break bug - bugfix new bug?
What ideas have you borrowed from open source drivers and what have the windows dev team borrowed from you?


Whats your schedule for doc releases for 2008? Will this be an ongoing thing?

Mobile GPUs - Imageon etc. - with all the eepc, mids, nanobooks heading our way are considering using these or underclocked mobile hd series chips? If so, can we see imageon documentation being released? How about documentation for gaming sys gpus?

How do you go about marketing/evangelising the linux driver to devs/publishers? (Other then phoronix) Are you starting to see any/more interest in the driver from companies /publishers such as Valve?

Do you see the linux gaming landscape changing drastically in the future? What is the relationship with fglrx's upstream and downstream like?

Do you look at the performance of your drivers under the current wine? Will you be looking at it once wine 1.0 is released (apparently some time 2008)

Will you port current/future video card demos (ruby etc) to linux?

Has the driver train way of doing things changed at all? What apps do you use to test the fglrxs?

Michael - will all previous questions in this thread be answered?

Is a q&a with nvidias linux team planned? Also a radeonhd/nouveau q & a session would be nice?

I hope it's a massive q&a session. ;)

If the devs are too time pressed for answering every qs, perhaps a quick and dirty "yes, no, maybe, no comment" section can be made at the very end for the rest.

[mo0n_sniper]

Will there be a documentation release any time soon for the R300/R400 parts?

I am interested in that too.I have a Ati Radeon Xpress Mobility X1150.I saw many laptops with this card including new ones.Because it is Mobility it is not based on r500 but on r400.This means that no open source driver has proper support for it or even supports it at all(Radeon,RadeonHD,Avivo).
So I would like to know when can we expect the r400 specs?

[DarkFoss]

Will agp continue to be supported in the foreseeable future ? I've read at DriverHeaven that the last recommended Cats were the 7.7's ..Omega was modding the 7.10's to add agp support.

[givemesugarr]

I am interested in that too.I have a Ati Radeon Xpress Mobility X1150.I saw many laptops with this card including new ones.Because it is Mobility it is not based on r500 but on r400.This means that no open source driver has proper support for it or even supports it at all(Radeon,RadeonHD,Avivo).
So I would like to know when can we expect the r400 specs?

i don't know if it's feasible what i've suggested in the x200m status thread in the opensource ati forum, ie. provide some nda documentation about the igps to devs who needs it so that they could do some adjustments for these boards, specially with regarding of powerplay-standby-suspend and with info for fixing the casual xorg crashes, but it would be nice for these boards' owners to see some of these feature working acceptable in the near future. for example on my board, suspend to ram works, but the second time i try to do it the pc doesn't suspend anymore. the suspend to disk has the same issue, and sometimes it even doesn't restart well. from what i've read around here this issues are present in all igps and if there would be a way to fix them in a quite rapid way (fglrx of via a nda in the opensource driver) it would be great.
delivering info for only the igps would be troublesome since there are different types of series (i don't know how much they're different from the non-igp boards and how much proprietary stuff have included inside). for me fglrx is usable and quite stable but still has some issues that aren't good enough (performance is very low and power management is not as i'd like).


so my question is: will these boards' user receive a good driver (power management and performant 2d and 3d) in the near future (about a quarter of an year)?

[djdoo]

Will there ever come support for XV video and Textured Video for IGP cards by FGLRX???

All of us that use the RS690 chipset cannot playback video (if not at all) not with good quality.

I can only watch DVD Video fullscreen with Xine(only Xine works) and openGL driver but sometimes Xine crashes too...

[eregular13]

i'm running a x2600xt on a msi 790X mobo and i installed the RadeonHD driver, or at least i thought i did, i still can't up the resolution and the display manager says its still running vesa.

i treid to install the linux drivers from amd/ati site, 8.443.1-x86.x86_64.run and i get the error message of vcdk missing installation aborted.

I'm using 7.10 (gutsy gibon?)

[Michael]

i'm running a x2600xt on a msi 790X mobo and i installed the RadeonHD driver, or at least i thought i did, i still can't up the resolution and the display manager says its still running vesa.

i treid to install the linux drivers from amd/ati site, 8.443.1-x86.x86_64.run and i get the error message of vcdk missing installation aborted.

I'm using 7.10 (gutsy gibon?)

eregular, please create a new thread for your problem. This thread is just asking about ATI/AMD general questions and not seeking technical support.

[eregular13]

PEACE homies

[Dandel]

I wonder how the answers to the questions so far will go, and i am interested in various media questions..

1) when will WideScreen support for 1680x1050, 1900x1200, and etc, appear in the amdccle and on the xrandr for the fglrx driver?

2) When will the information about accessing the gpu fan and temperatures appear?

3) when will fglrx have GLX fixed for multiple monitors be fixed( broken since 8.41.x, and usable in 8.40 )

4) when will the driver completely support all posible options of aiglx, namely the errors that appear when it is enabled.

5) when will alpha blending appear as implemented in linuxmce.

[Malek]

when will I be able to run two monitors in dual-head mode (--dtop=horizontal switch) that:

a) have working GLX on either monitor (both would be nice, but I could live with one), and

b) doesn't fill my Xorg.0.log with a billion errors of:
(EE) fglrx(1): [DRI] Unlocking inconsistency:
Context 136430108 trying to unlock lock held by context 2
(EE) fglrx(1): [DRI] Locking deadlock.
Already locked with context 136430108,
trying to lock with context 2.
And more to the point, do you even know about this problem? I've posted bug reports and sent support mails, but they both seem to be getting ignored...

[Melcar]

When will fglrx provide video capture/input support for your All-in-Wonder and VIVO cards?

[toxigenicpoem]

1) When will AMD stop falsly claiming they support Linux with the ATI drivers?

2) Will the drivers ever be as good as those for OSX or Windows?

3) When will AMD start the refund program to get my money back for thier faulty products?

[DarkFoss]

Will Crossfire support be implemented this year ?

[givemesugarr]

Will Crossfire support be implemented this year ?

maybe it's better to have a fully working accelerated driver before doing that. it wouldn't be very useful to have 2 boards connected if the single one wouldn't be able to work perfectly.... and it wouldn't also be so easy to implement.

[Ole-Martin Broz]

CF if easy done. dunno bout it, since i dunno damn thing about it.
CF with quad displays would be crazy cool.
Howto for HDMI audio.

Well, questions.

When will CF be supported.

When will we be able to overclock in linux, watch temps or anything like it.

Videoplayback issues fixed when ?.

Aiglx improvements.

and will the open source driver be anyhow supported with 3rd party closed source ati developed software ? prioritary. for stuff the open source cannot have due to licence and all that crap ?.

pretty satisfied with hd 3870 under linux :)

[kmolazz]

Question:
Are there plans to introduce user controlled powerplay settings in the linux control center, in a similar way to what exists in windows?

I know one can use aticonfig, but we can not for example prevent the card from going to a lower powerstate when switching to battery mode.

[ejs1920]

I'd also like to know what programs are used to test fglrx, but more specifically, what open source programs, if any, are used?

BZFlag? RSS-GLX screensavers? XScreenSaver's OpenGL hacks? Mesa's demo programs?

Is fglrx tested with anything like glean http://glean.sourceforge.net or the official SGI OpenGL conformance tests?

Also, since the Windows drivers are supposed to be able to detect GPU lockups and reset the hardware, are there any plans to implement this functionality on Linux? Even if it killed the X server, it would be better than hard locking the entire system.

[Vighy]

Question:
Are there plans to introduce user controlled powerplay settings in the linux control center, in a similar way to what exists in windows?

I know one can use aticonfig, but we can not for example prevent the card from going to a lower powerstate when switching to battery mode.

they did it!

[kmolazz]

they did it!

you mean we can expect it in the upcoming releases? :)

[Melcar]

Why does my card only work in low power mode?

[Vighy]

you mean we can expect it in the upcoming releases? :)

I mean they already did it for the 7.12 release! (Linux Catalyst Control Center 1.7)

[kmolazz]

hum... i don't have anything related to powerplay in the amd linux control center. I have a X700M, what card are you using?

[Vighy]

hum... i don't have anything related to powerplay in the amd linux control center. I have a X700M, what card are you using?

HD2600 Mobility, it's there even if powerplay is not supported yet (on my card).

it should be there..

[Berniyh]

My question:
Could there maybe be two branches for the fglrx driver?
One driver, where _only_ fixes go in (and it is branched off the other one in bigger intervals), so something like a stable branch.
8.40.4 was _a bit_ like that.
And one branch where features go in (AIGLX), but which might have more bugs and for which not every release might work for everyone.

Mainly what I'm asking here is:
Can we get fixes for already released driver versions?
The current policy to not touch drivers, that have been released is really not the best.

So, lets consider, that 8.40.4 maybe was a version, that worked for most people, so there could be a verion 8.40.4-rev1, which brings kernel 2.6.23 (Yes, that is a fix, not a feature!), or if it had this resolution thing (that 7.12 currently has), then there could be a -rev2 for that.

[Vighy]

My question:
Could there maybe be two branches for the fglrx driver?
One driver, where _only_ fixes go in (and it is branched off the other one in bigger intervals), so something like a stable branch.
8.40.4 was _a bit_ like that.
And one branch where features go in (AIGLX), but which might have more bugs and for which not every release might work for everyone.

Mainly what I'm asking here is:
Can we get fixes for already released driver versions?
The current policy to not touch drivers, that have been released is really not the best.

So, lets consider, that 8.40.4 maybe was a version, that worked for most people, so there could be a verion 8.40.4-rev1, which brings kernel 2.6.23 (Yes, that is a fix, not a feature!), or if it had this resolution thing (that 7.12 currently has), then there could be a -rev2 for that.

do you mean something like the kernel way?

could be nice, but with reduced man power it's the end of the development.

[Berniyh]

do you mean something like the kernel way?

could be nice, but with reduced man power it's the end of the development.
Yes, and No.
The kernel people stabilize every release, that's not what I asked for.

Every once in a while (lets say every about every 6 monts) there is a driver version, that seems to work for most people quite good, but as always there are some issues.

Take 7.11 for example, that seemed to work for most people, but it has bugs, that simply prevents it from going stable on some distros, like the soname bug. I guess that one is not a really big deal, 7.12 fixed it. Now for most people 7.12 was a disappointment, because if the resolution bug and various other issues. If now ATI would backport the soname fix (maybe a few others), that are known to not open one of the new bugs, that 7.12 has, there would be a more stable 7.11, maybe one, that most distros could use as a stable driver.
Now as I said, not every driver version has to get fixes, obviously 8.42.3 and 8.41.7 were not good enough to deserve a living beyond there release.

Would it really be that hard, to maintain (in addition to the normal release) lets say two branches, that are known to be worth maintaining?
I don't think, that someone would really care if they get dropped after a year (I mean, who cares about 8.36 or 8.30 these days?).

[Vighy]

Yes, and No.
The kernel people stabilize every release, that's not what I asked for.

Every once in a while (lets say every about every 6 monts) there is a driver version, that seems to work for most people quite good, but as always there are some issues.

Take 7.11 for example, that seemed to work for most people, but it has bugs, that simply prevents it from going stable on some distros, like the soname bug. I guess that one is not a really big deal, 7.12 fixed it. Now for most people 7.12 was a disappointment, because if the resolution bug and various other issues. If now ATI would backport the soname fix (maybe a few others), that are known to not open one of the new bugs, that 7.12 has, there would be a more stable 7.11, maybe one, that most distros could use as a stable driver.
Now as I said, not every driver version has to get fixes, obviously 8.42.3 and 8.41.7 were not good enough to deserve a living beyond there release.

Would it really be that hard, to maintain (in addition to the normal release) lets say two branches, that are known to be worth maintaining?
I don't think, that someone would really care if they get dropped after a year (I mean, who cares about 8.36 or 8.30 these days?).

and what about 8.28? :-P the last one for r200 chipsets :-)

but I think they don't have enough manpower to do what you suggest...

but let's see what they say :-)

[givemesugarr]

Yes, and No.
The kernel people stabilize every release, that's not what I asked for.

Every once in a while (lets say every about every 6 monts) there is a driver version, that seems to work for most people quite good, but as always there are some issues.

Take 7.11 for example, that seemed to work for most people, but it has bugs, that simply prevents it from going stable on some distros, like the soname bug. I guess that one is not a really big deal, 7.12 fixed it. Now for most people 7.12 was a disappointment, because if the resolution bug and various other issues. If now ATI would backport the soname fix (maybe a few others), that are known to not open one of the new bugs, that 7.12 has, there would be a more stable 7.11, maybe one, that most distros could use as a stable driver.
Now as I said, not every driver version has to get fixes, obviously 8.42.3 and 8.41.7 were not good enough to deserve a living beyond there release.

Would it really be that hard, to maintain (in addition to the normal release) lets say two branches, that are known to be worth maintaining?
I don't think, that someone would really care if they get dropped after a year (I mean, who cares about 8.36 or 8.30 these days?).

to me the idea is not good. your idea would split the development more, than actually focusing it. having different driver versions to maintain is stupid. if i were to choose how to set the development schedule, i'd say:
1. ok for monthly releases of patches for open bugs and compatibility with new software versions.
2. immediate retirement of patches that cause regressions in the driver
3. 2 major releases twice a year with new features.
so the schedule would be:
on june the driver would be released with schedule for the 15th of the month. the second major release with new features would came on 23rd of december as a christmass present.
the other months of the year the driver would remain as is and will only get monthly patches if they would correct bugs. otherwise there wouldn't be any patch released. this new type of development that amd has adopted is somehow stupid and useless. the differences between 7.10 and 7.11 have been only in the known bugs actually.

[Berniyh]

to me the idea is not good. your idea would split the development more, than actually focusing it. having different driver versions to maintain is stupid. if i were to choose how to set the development schedule, i'd say:
1. ok for monthly releases of patches for open bugs and compatibility with new software versions.
2. immediate retirement of patches that cause regressions in the driver
3. 2 major releases twice a year with new features.
so the schedule would be:
on june the driver would be released with schedule for the 15th of the month. the second major release with new features would came on 23rd of december as a christmass present.
the other months of the year the driver would remain as is and will only get monthly patches if they would correct bugs. otherwise there wouldn't be any patch released. this new type of development that amd has adopted is somehow stupid and useless. the differences between 7.10 and 7.11 have been only in the known bugs actually.
What you are suggesting is exactly the same, you just name it differently.

[bridgman]

The difficulty with that kind of release model is new ASIC support. If we are going to support new ASICs in a timely manner we can't go six months between major releases... and it's not really practical to push support for anything but the most trivial ASIC spin into a side branch while maintaining development in a mainline.

[Kano]

Wow, that took really long get the problem... Maybe use your biggest competitor as example how it could be done.

[bridgman]

Not sure I understand. Neither of our big competitors release Linux drivers on a six month cycle (unless I'm thinking of the wrong competitors ;)). Both average a couple of months between releases and both branch off a mainline like we do.

[Kano]

Well usually you don't get drivers every X month but as soon as there are problems with the current one or when new hardware is out. For 8800 GT it took a bit long (compared to former new cards) to get updated drivers but you could at least adopt that there will be _public_ beta drivers and ones marked as stable. Next will there will be new ATI cards, I hope you don't forget the ASIC for that in the new driver. Also you should think about crossfire and multi gpu support - NV has SLI and mulit gpu running on Linux since long time.

[bridgman]

Ahh, OK. We're already doing a bit of that -- you probably noticed the release numbering changed a while back -- and we can cover that more in the Q&A.

[Kano]

Then do bugfix releases not only monthly especially when the error is a major regression like in the last driver. Do you think ignoring is the best way to solve something? It was the first driver with FireGL support and now they still have to hack the pciids of older releases...

[Berniyh]

Well usually you don't get drivers every X month but as soon as there are problems with the current one or when new hardware is out. For 8800 GT it took a bit long (compared to former new cards) to get updated drivers but you could at least adopt that there will be _public_ beta drivers and ones marked as stable. Next will there will be new ATI cards, I hope you don't forget the ASIC for that in the new driver. Also you should think about crossfire and multi gpu support - NV has SLI and mulit gpu running on Linux since long time.
Naah, please no new features, just get the current ones running without too many bugs. ;)

(I would say, that presenting crossfire for linux together with hybrid crossfire would be perfect, but I guess, that hybrid crossfire will be presented too soon.

[bridgman]

Do you think ignoring is the best way to solve something?

Sorry, what did I say to make you think that ?

[Kano]

Well that was about "you probably noticed the release numbering changed a while back". I saw that ATI "skipped" one driver and increased the Q&A. But:

The last driver 7-12 demonstrated why ATI makes me sick:

"Connecting a display device that supports 1680x1050 to a system running Linux may result in a maximum display resolution of 1280x1024 only being available"

this may not be in a driver release note, no and never. It was 4 weeks ago and no bugfix was released. The 7-11 driver had a "warning" like

"AMD recommends that this release of the AMD Catalyst™ Linux software driver not be used for distribution packages. Distributors should continue to use the AMD Catalyst™ Linux driver version 8.40.4"

But this 7-12 driver deserves that even more and is implicit remommended. All drivers since 8.39.4 have got at least beta quality (I don't like 8.40.4 due to the googleearth bug). No driver on the new codebase renders correctly (try gl2benchmark) and bugs which are definitely a major regression should be fixed immediately.

[homerhomer]

Dear AMD/ATI

I want to be your customer.

I have been using AMD CPU procs for at least 10 years. I have been the defender for old bullshit like AMD not being compatible and whatever else arises to smear the name. I believe in the best deal for my situation (Capitalist style!). And through all the backlash AMD has always came though for me. ATI on the other hand has been not.

This sort of "build it yourself" attitude got me to Linux and where I'm today.

My question to ATI is, why does the software ruin good Hardware? I understand that this is a simple way of looking at everything, but really at this point in time I can't recommend ATI hardware to my friends. This is not only from the Linux side of things but I have heard grips from VISTA too.

What I do like is that they are making there drivers open source. On the contrary, this makes me feel that ATI is letting the community fix the issues that they can't get straight. I'm excited that the drivers will finely work, and I'm concerned that ATI can't figure it out themselves.

What I would love to hear is AMD/ATI's commented to Linux and the even more so the end user. How about a contest to Linux users? How about a special offer? or maybe even something that says Thanks we appreciate you as a customer.

How about a little more for this relationship?

- BTW, I'm still happy with AMD and I can only hope that they gets ATI up to speed.


Thanks



:confused:

[knutbert]

Hello,

there's one thing I've been wondering about ever since I bought my Laptop equipped with a Moility Radeon X1900:

The Mobility X1900 has not shown up in any of the release notes I've seen - not even as unsupported hardware. Also it's not among the cards listed in the driver download section of the ATI/AMD support pages. :confused:

So what's the deal with the Mobility X1900?

Is it just a OC'ed version of, say, the Mobility X1800 - or is there more to it?

And most important of all: Are there any differences as opposed to the other X1xxx cards that will be important when it comes to running the fglrx driver?

Any insight would be greatly appreciated! :)

Regards,
knutbert

[djdoo]

@bridgman:

My friend you haven't answered me :(

Is there going to bee any XV or XvMC support for AVIVO cards under 64-bit soon??

And what about EXA? How to use it??

[bridgman]

Actually, we haven't answered any of the questions in this thread yet. We printed off a big list, and the devs will be going through them and feeding the results back to Michael as the basis for a Q&A article (at least I think that's the plan).

I still don't think we're going to talk much about specific future plans but we should be able to give you a general idea.

[Berniyh]

Actually, we haven't answered any of the questions in this thread yet. We printed off a big list, and the devs will be going through them and feeding the results back to Michael as the basis for a Q&A article (at least I think that's the plan).

I still don't think we're going to talk much about specific future plans but we should be able to give you a general idea.
You answered mine, well... sort of. ;)

[Svartalf]

Sorry, what did I say to make you think that ?

It's not what you said, but rather the mixed results everyone keeps seeing from AMD that leads them to believe that the company's sort of ignoring us.

I don't see it that way, mind, but I know where this is coming from, John. And the glacial pace of things actually getting done with the fglrx driver and the tech docs getting released isn't helping the situation any.

[Vighy]

what about adding powerplay support for mobility chipsets!? I'm using the M76 (Mobility HD2600) and the support for this chipset was already there with the 8.41, but not for the powerplay feature.

Svartalf says you're ignoring us, well maybe ignoring our needs: who buys a laptop needs also power management policies..

everything else from fglrx is nice for me (didn't check if the composite corruption is gone), made exception for powerplay.

[Berniyh]

what about adding powerplay support for mobility chipsets!? I'm using the M76 (Mobility HD2600) and the support for this chipset was already there with the 8.41, but not for the powerplay feature.

Svartalf says you're ignoring us, well maybe ignoring our needs: who buys a laptop needs also power management policies..

everything else from fglrx is nice for me (didn't check if the composite corruption is gone), made exception for powerplay.
It works on some notebooks already. Mine for example.
But there seem to be quite a few chips, that are not yet supported by fglrx' powerplay, that's true.

[wohali]

Hi Mr. ATI Dev guy,

Thanks for your hard work - I realize you're probably a one-person show over there, and that you have your work cut out for you. Don't give up!

Would you be willing to work with some of us to help diagnose component video out issues on older and recent era cards (R300 and up)?

[linzerd]

What about full Xv complete support (getting rid of strange color and blocky output)... Integrated graphic chips (X200) don't handle well openGL video output, too much tearing...

[mal13]

I have problem... can't logout/switchuser/power off correctly after update to 8.01. Do i really have to wait another month (at least) before it gets fixed??

[Vighy]

I have problem... can't logout/switchuser/power off correctly after update to 8.01. Do i really have to wait another month (at least) before it gets fixed??

the same for me... but the obvious answer is "yes" so i think the right place to ask the question is on the "Catalyst 8.01" thread :-)

[Linuxhippy]

Will there be serious 2D XRender accaleration be available in future proprietary driver builds?

XRender is getting used more and more, and intel and nvidia are already working on enhancing their drivers..

lg Clemens

[lucky_]

One thing I wonder :
In less than one year (we hope so), there will be big changes in the opengl stack in linux.
So from my AMD customer point of view : will fglrx be ready for those changes ?
How AMD is anticipating those changes through fglrx and radeonhd ?
I am pretty sure that some of these questions will be adressed at FOSDEM, I ask anyway.

[bridgman]

Just so we don't miss anything, are you talking about OpenGL 3.0 or more about lower level changes like TTM and maybe modesetting going into the kernel ?

[Skinkie]

As lead developer for http://ttxinsert.sourceforge.net/ I would love to support the ATI card too. Since ATI open sourced much of its driver model I should browse through the available specs first I guess.

My question would be kind of an sort cut here.

The nVidia driver allows a user to overscan the composite output in such way that it scales the framebuffer beyond one visible line. This is great, but not all what is possible...


For the ATI card:
- Is it possible to natively insert data in the VBI region, not using the framebuffer?
- If not, is it possible to overscan the *entire* output, visible or invisible?

Would you have any tips for us in getting it to work on ATI hardware, maybe related to timing? (We now use VSYNC in OpenGL)