"Ask ATI" dev thread

[Melcar]

I want to ask users and devs (I expect to draw bridgman's attention) what is your impression of the ATi/AMD efforts with fglrx to this point.
I've read a lot in the forums and there are positive and negative (mostly) impressions of the development of the drivers. One issue, and I think most users are annoyed with, is: Are the bugs within fglrx a consecuence of the driver itself or is it highly related to the different Linux distributions and, in what extent has that been treated in the ATi Linux department?
Another issue I see is the lack of information about the different settings that one can actually use within the X configuration file. Many users expect to find this information along with the release info in the AMD website. I found the configuration options in the compiz forum (thanks djdoo). However, I believe that, in order to avoid potentially harmful misuse of the different options that one can write to the X conf. file, this should be very clearly specified with every release.

I presume the instability of the driver has more to do with user system settings. It has been said already that fglrx is only tested on a handful of distros, and I doubt every single form of hardware combination is tested. The various user experiences with the driver is evidence of that; if the driver just plain sucked and was broken no one would be able to use it successfully.
As for the documentation for settings, it has also been explained on a previous discussion here on the forums. I for one, think that all functions and parameters available for a particualr driver release are automatically put in use (depending on your card of course) making it unnecessary for the user to do much of anything besides initializing the module. The options that are usually off and can be turned on by editing configuration files, are usually still in testing; you can even say these options are turned off (and not disclosed) so as to avoid "harmful misuse" of the driver. Remember that this is a proprietary driver... they don't have to disclose everything about it if they don't want.

[bridgman]

The documentation for the Display section of xorg.conf can be summarized in one sentence. Don't be messin' with it

Seriously, Matthew has posted a few times that the direction is to get driver configuration options from amdpcsdb and to use Xorg.conf for configuring the rest of the X system. Part of the installation process involves running aticonfig to initialize the amdpcsdb file and from that point on configuration changes should be done using aticonfig or cccle. There may be a couple of exceptions to this and if so I agree we need to get them properly documented.

There are a few things on my list of "questions to ask Matthew next time I see him *and* remember the list" :

- does aticonfig --initial do anything to xorg.conf or does it only change admpcsdb ?

- are there any configuration options which are currently configurable only through xorg.conf, or should we be using aticonfig (and hence amdpcsdb) for everything already ?

- would it be possible to make the option handling a bit more verbose, particularly in the case where there is a conflict between xorg.conf and amdpcsdb entries ? Not sure this is necessary though, since it is only an issue if you have xorg.conf Display options and in general we are recommending that you do not...

I should probably mention again that this thread is specifically for accumulating questions to the ati devs, but I think we've all pretty much given up on any hope of thread discipline anyways

[duby229]

The documentation for the Display section of xorg.conf can be summarized in one sentence. Don't be messin' with it

Seriously, Matthew has posted a few times that the direction is to get driver configuration options from amdpcsdb and to use Xorg.conf for configuring the rest of the X system. Part of the installation process involves running aticonfig to initialize the amdpcsdb file and from that point on configuration changes should be done using aticonfig or cccle. There may be a couple of exceptions to this and if so I agree we need to get them properly documented.

There are a few things on my list of "questions to ask Matthew next time I see him *and* remember the list" :

- does aticonfig --initial do anything to xorg.conf or does it only change admpcsdb ?

- are there any configuration options which are currently configurable only through xorg.conf, or should we be using aticonfig (and hence amdpcsdb) for everything already ?

- would it be possible to make the option handling a bit more verbose, particularly in the case where there is a conflict between xorg.conf and amdpcsdb entries ? Not sure this is necessary though, since it is only an issue if you have xorg.conf Display options and in general we are recommending that you do not...

I should probably mention again that this thread is specifically for accumulating questions to the ati devs, but I think we've all pretty much given up on any hope of thread discipline anyways

Here's a question for the devs.....

Why deviate from accepted standard practice? Why create a buggy proprietary tool like aticonfig that breaks compatibility with proper configuration?

I certainly can understand the need for automation. But at the risk of breaking compatibility and telling people that they cant use the proper (and standard) outlets for configuration (in this case xorg.conf)is just plain retarded.

I think this whole move to replace xorg.conf needs to be re-evaluated. I personally think that xorg.conf is an excellent tool. Some of the options in xorg.conf that requires an X restart should be rewritten to support on the fly modifications, but otherwise it's the perfect place to store configuration. It's plain text so anything can read it. Syntax is simple and straight forward. It seems to be ideal in my mind.

I agree that we need a bit more automation, but breaking compatibility with xorg.conf is just plain stupid, and then telling people not to modify it, retarded....

[bridgman]

I think the use of amdpcsdb is partially driven by the need for something that CCCLE can own and update as needed, and partially by code sharing across OSes (although I think the first one is the primary driver).

The open source drivers have no control panel, have dedicated code for X and are able to follow accepted practices pretty much everywhere (although of course even there we see argument about what accepted practices are). There are some early attemtps at building control panels (desktop config tools) over the open drivers but they are pretty basic today.

You mentioned "a buggy tool like aticonfig" -- I don't *think* I have seen any bug reports against aticonfig itself, have I missed something ?

Kano's recent post in another thread points out another issue; that drivers and GPUs are sufficiently complex that a "one size fits all" xorg.conf isn't such a practical thing these days but packager's scripts really want to write out the same xorg.conf for every GPU. If we want to give a good user experience we need to set some chip-specific defaults or we need to rewrite the entire option set to be more high level rather than matching 1:1 with specific implementation details as they do today. By "higher level" I mean options which can be interpreted appropriately by the driver in a chip-specific way. Today we have options like "VideoOverlay" and "TexturedVideo" where different generations of GPU simply need different settings or things don't work right. We can deal with this more easily in amdpcsdb (which we control) than in xorg.conf (which the distros and packagers control).

There is still hot debate about how best to manage on-the-fly settings changes and so far I haven't seen any resolution. If a good standard emerges I imagine we would adopt it fairly aggressively, but right now the answer is alwasy along the lines of "um, well, we really need a new userspace daemon to...".

I agree that we need a bit more automation, but breaking compatibility with xorg.conf is just plain stupid, and then telling people not to modify it, retarded....

But you do have to admit that the two go together, ie if you have a different mechanism for managing driver options then telling people to go ahead and put potentially conflicting settings in xorg.conf doesn't make much sense either

[smlbstcbr]

The documentation for the Display section of xorg.conf can be summarized in one sentence. Don't be messin' with it

Seriously, Matthew has posted a few times that the direction is to get driver configuration options from amdpcsdb and to use Xorg.conf for configuring the rest of the X system. Part of the installation process involves running aticonfig to initialize the amdpcsdb file and from that point on configuration changes should be done using aticonfig or cccle. There may be a couple of exceptions to this and if so I agree we need to get them properly documented.

There are a few things on my list of "questions to ask Matthew next time I see him *and* remember the list" :

- does aticonfig --initial do anything to xorg.conf or does it only change admpcsdb ?

- are there any configuration options which are currently configurable only through xorg.conf, or should we be using aticonfig (and hence amdpcsdb) for everything already ?

- would it be possible to make the option handling a bit more verbose, particularly in the case where there is a conflict between xorg.conf and amdpcsdb entries ? Not sure this is necessary though, since it is only an issue if you have xorg.conf Display options and in general we are recommending that you do not...

I should probably mention again that this thread is specifically for accumulating questions to the ati devs, but I think we've all pretty much given up on any hope of thread discipline anyways

Actually, is it really necessary to have two different tools inside the driver to modify the amdpcsdb? (aticonfig and cccle)
Should it make more sense to handle the pcsdb by only one tool to modify it? In the case of fglrx, I believe that having aticonfig inside the cccle would make more sense than using them separately. aticonfig DOES modify, at some extent, the X configuration file, then amdpcsdb needs xorg.conf to work, in some way. (methinks).
And finally, I think that is very a interesting idea to use pscdbs to store configuration from the driver, so one can actually play with X without killing the driver
PS> What kind of questions do you expect to be asked?

[MikeEx]

Are there any plans for real dual screen support? (besides big-desktop)
It would be amazing to have dual screen support like windows has.

I know you said in the past that the main focus was on the 3D rendering market.
But since you guys switched strategies and are focused on features for the user desktop experience;
Will new ways to get dual screen on ati hardware come about?

In windows I can play "full screen" games on one screen and watch "full screen" movies on another at the same time.
and not being able to do this in linux is a turn off.

Do other vendors have this limitation?
Is it a limitation with X itself?

[bridgman]

Actually, is it really necessary to have two different tools inside the driver to modify the amdpcsdb? (aticonfig and cccle) Should it make more sense to handle the pcsdb by only one tool to modify it? In the case of fglrx, I believe that having aticonfig inside the cccle would make more sense than using them separately. aticonfig DOES modify, at some extent, the X configuration file, then amdpcsdb needs xorg.conf to work, in some way. (methinks).
And finally, I think that is very a interesting idea to use pscdbs to store configuration from the driver, so one can actually play with X without killing the driver

As I understand it, the reason for keeping aticonfig separate is that having a separate command line tool makes it easy for packagers to use it in scripts. I imagine there is a fair amount of common code but not 100% sure.

PS> What kind of questions do you expect to be asked?

This referred to one poster asking users to post their own experiences with fglrx in this thread. I thought that could be done better in a different thread. The dev questions here are all fine so far, although "why do you guys suck so much ?" was only funny the first time

[DaedalusIcarus]

Ok, here's a fairly short one.

I took a look at the catalyst 8.7 release note and found a fair bit of new Mobility chips on the supported list.
To my dismay, the support covered 34XX and 38XX mobility chips, but not the 36XX which lies in between (and which I'll have in a notebook which is on its way to me).

The question is:
Do you have any clue whether or not these chips will be supported ? And what makes them special enough to not support them this time around ? Again, I know nothing of it (obviously) but seeing as they're all 3XXX mobility chips I would think that adding support for this last series would be trivial ?

That's it, hopefully it's among the "ok to ask" questions

[BlackStar]

The previous driver (8.6) was able to drive my 4850, even though it was not listed as supported.

There's a good chance that the 8.7 drivers will support your card (maybe the QA is not complete or something).

[bridgman]

DaedalusIcarus, I will check. It may be that we hadn't finished qual'ing the 36xx by the release cutoff date or that there had been some kind of problem with support for that specific chip.