Page 1 of 2 12 LastLast
Results 1 to 10 of 18

Thread: What functionality is supported for RV670?

  1. #1
    Join Date
    Jul 2007
    Location
    Stockholm, Sweden
    Posts
    49

    Default What functionality is supported for RV670?

    I think it's quite difficult to fint current information on the status of different features of the different radeon drivers.

    Anyhow, I have a new computer which I mean to use mainly for gaming, which of course means Windows. But it would be nice to be able to run Linux on it as well. So I'm wondering whether this is a pointless excercise at the moment or whether it would be worthwile.

    My graphics card is a passively cooled HD3870 (RV670?).

    For it to be worthwile, to me, the kernel/X/driver would have to support the following:

    1) Working 2D graphics. With working I mean useable, snappy, not 100% cpu usage for a second just because a window is resized. VT switching must be stable.
    2) Power management. I have a passively cooled card; I want a quiet system and I don't want the card to burn itself out.
    3) Support for hardware scaling etc for watching movies.

    Is there a combination of software that can cope with this?

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

    Default

    There is a useful wiki page which is kept reasonably up to date :

    http://www.x.org/wiki/RadeonFeature

    As of today, the open source support for RV670 is just modesetting and shadowfb acceleration. The two acceleration features you are looking for have been largely implemented and we are trying to get through the IP review to release them to the public. We haven't done much with 6xx/7xx power management yet but that will be the next priority after getting 6xx/7xx 3D support released into the wild.

    The fglrx driver has all those things today, if you are running a supported OS or are willing to do some tweaking.
    Last edited by bridgman; 12-19-2008 at 12:01 PM.

  3. #3
    Join Date
    Jul 2007
    Location
    Stockholm, Sweden
    Posts
    49

    Default

    That's a useful feature matrix - it went directly to my bookmarks.

    Would my card fall under R600 or under RS690 here? (Or neither, perhaps?)

    The sad fact remains though that still, what is it, 15 months after AMD's initial "Open Source Initiative", there is still no useable driver for these cards. (Open source that is, fglrx is not useable to me, at least, because of prolems when rebuilding kernels, and because of bugs.) A company with AMD's resources should've been able to have a full-fetured driver out in this time period, if the management really cared.

    I just hope people doesn't go and buy these cards believing they are actually useful under Linux today.

  4. #4
    Join Date
    Jul 2007
    Location
    Stockholm, Sweden
    Posts
    49

    Default

    BTW, will power management be part of the kernel mode setting in the future?

    That seems like the obvious place to put it to me, and it would be very neat as well, having gfx power management as soon as the kernel has booted. Like cpufreq for the cpu.

  5. #5

    Default

    Your RV670 fall under the R600 family. If you have an updated driver from git (i.e. from 16 december or later) you can also see all the features supported using "man radeon" (previuos driver version did not have a good feature section).

  6. #6
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,577

    Default

    I think you will get conflicting answers re: whether power management will be "part of kernel modesetting" or just "part of the kernel" but there is general consensus that putting power management in the drm (the kernel portion of the graphics stack) will be the best solution.

    Since a number of usage scenarios do not include drm today (mostly legacy enterprise distros, but they support a lot of users), I expect there may also be some basic power management implemented in the X driver, but that would presumably be disabled if drm was present.

    Bitnick, our open source plan was never for AMD to write the driver themselves but to "kickstart" the development through partnership with Novell/SuSE then support community development of the driver from that point. We also maintain a small team of developers to get around the chicken/egg problem where it's hard to write documentation unless you are writing at least parts of the driver at the same time.

    The rate of progress will depend in large part on the extent that community resources are contributing. The fglrx driver is still our primary vehicle for supporting new GPUs at launch, although over time I expect you will see open source support become available a lot closer to launch time.
    Last edited by bridgman; 12-19-2008 at 01:33 PM.

  7. #7
    Join Date
    Oct 2008
    Posts
    93

    Default

    Quote Originally Posted by bitnick View Post
    I just hope people doesn't go and buy these cards believing they are actually useful under Linux today.
    i dont. i dont think alot of people do either. amd/ati always seem to be behind.

  8. #8
    Join Date
    Dec 2007
    Posts
    248

    Default

    Quote Originally Posted by bridgman View Post
    Bitnick, our open source plan was never for AMD to write the driver themselves but to "kickstart" the development through partnership with Novell/SuSE then support community development of the driver from that point. We also maintain a small team of developers to get around the chicken/egg problem where it's hard to write documentation unless you are writing at least parts of the driver at the same time.
    That gives AMD the second possition on both fields. Nvidia leads with their blob being the best blob. Intel leads with it's open source driver being first with new technologies (kms,dri2, gem) and having faster open source support for new cards...

    What's left for AMD/ATI is being the only one to provide both blob and open source drivers... though I wonder how successfull that can be in the long run.

    You were the first one to provide docs without NDA, and I think we all will remember about it. The question is if that is enough to choose your cards while you guys are second in both driver types.
    Last edited by val-gaav; 12-19-2008 at 08:05 PM.

  9. #9
    Join Date
    Oct 2008
    Posts
    93

    Default

    i prefer the open source drivers. fglrx worked acceptably on the 780g that i had. the video tearing was annoying but tolerable. it didnt crash, at least i dont think so. (gigabyte board usually locked up before it had a chance). if it were not for the buggy sata/ahci and usb i would probably have tried amd again. but why be a beta tester ?

  10. #10
    Join Date
    Jul 2007
    Location
    Stockholm, Sweden
    Posts
    49

    Default

    I don't know, I think it's ok to leave it to "the community" to develop the drivers, with just a few developers in-house to slowly do things the community cannot or will not take on, fix difficult bugs and so on. And it's great to "kick-start" the development the way AMD has done.

    But community involvement requires documentation, and let's face it: that's still not there. The first docs (register list) were quite useless; you'd have to already be an AMD developer with a lot of inside knowledge to make any use of them. Later (e.g. apr 08) docs seems to be of higher quality, although I haven't looked very deep. Still: 3D is missing, PowerPlay is missing (or perhaps I have just missed it?) ... as long as useful docs aren't out there, I think it's quite ugly to blame the community for not having drivers ready!

Posting Permissions

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