Page 29 of 111 FirstFirst ... 1927282930313979 ... LastLast
Results 281 to 290 of 1109

Thread: "Ask ATI" dev thread

  1. #281
    Join Date
    Dec 2007
    Location
    Merida
    Posts
    1,098

    Default

    Quote Originally Posted by smlbstcbr View Post
    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.

  2. #282
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,284

    Default

    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
    Last edited by bridgman; 07-26-2008 at 12:57 PM.

  3. #283
    Join Date
    Nov 2007
    Posts
    1,353

    Default

    Quote Originally Posted by bridgman View Post
    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....

  4. #284
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,284

    Default

    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
    Last edited by bridgman; 07-26-2008 at 01:37 PM.

  5. #285
    Join Date
    Dec 2007
    Location
    down the street around the corner
    Posts
    26

    Default

    Quote Originally Posted by bridgman View Post
    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?
    Last edited by smlbstcbr; 07-26-2008 at 09:54 PM.

  6. #286
    Join Date
    Oct 2007
    Posts
    16

    Default

    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?

  7. #287
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,284

    Default

    Quote Originally Posted by smlbstcbr View Post
    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.

    Quote Originally Posted by smlbstcbr View Post
    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

  8. #288

    Default

    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

  9. #289
    Join Date
    Oct 2007
    Location
    Under the bridge
    Posts
    2,099

    Default

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

  10. #290
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,284

    Default

    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.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •