Page 4 of 6 FirstFirst ... 23456 LastLast
Results 31 to 40 of 53

Thread: AMD Releases OpenCL ATI GPU Support For Linux

  1. #31
    Join Date
    Oct 2008
    Posts
    93

    Default

    This is great that AMD/ATI is supporting linux, but i assume this is proprietary. Is there an open source alternative, eiher as an independent package or with xorg-ati? Is there any aditional documentation needed for this ?

    I wonder how impossible it would be for this to work on older cards, and if an open source driver could take advantage of this.

    matt

  2. #32
    Join Date
    Jul 2008
    Posts
    1,731

    Default

    Quote Originally Posted by smitty3268 View Post
    What NVidia is saying is that certain C++ features weren't possible in previous generations because the hardware lacked the necessary support. See this anandtech article for some more info: http://www.anandtech.com/video/showdoc.aspx?i=3651&p=6
    yes, I read that. Sounds like 'you will be able to use c++ to program for the gpu' and not 'you can write c++ code and the card will eat it directly'.

  3. #33
    Join Date
    Oct 2008
    Posts
    3,244

    Default

    Yep. That's probably for the best anyway - it's a really bad idea to just run normal c++ application code on a GPU, because it's almost certainly going to be mostly single-threaded and run much faster on a normal CPU. Where I see this being useful is for things like C++ matrix libraries, etc., and I imagine even then you'll have to write code specifically for the hardware in order to get any kind of decent performance, just like you do with CUDA now.

  4. #34
    Join Date
    Oct 2008
    Posts
    3,244

    Default

    Quote Originally Posted by mattmatteh View Post
    This is great that AMD/ATI is supporting linux, but i assume this is proprietary. Is there an open source alternative, eiher as an independent package or with xorg-ati? Is there any aditional documentation needed for this ?

    I wonder how impossible it would be for this to work on older cards, and if an open source driver could take advantage of this.

    matt
    There's an open source gallium state tracker currently under development, but it's going to be awhile before the r600g driver is working. They haven't even started it yet (12 months?).

    I don't think it will work for anything earlier than r600 because of hardware limitations - at that point you'd just be running it through the software pipe on the CPU.

  5. #35
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,571

    Default

    If we thought the r600g driver was going to take a year to write we would have started it a long time ago

    Once we have a solid r300g base I don't think it should take too long to port the 6xx/7xx code across from the classic Mesa driver.

  6. #36
    Join Date
    Feb 2008
    Posts
    52

    Default

    Gallium's OpenCL tracker is pre-alpha, IIRC. Free OpenCL will happen, just not yet. AFAIK there's no complete free OpenCL platform for any OS, so I'm not going to split any hairs.

    nVidia and AMD's OpenCL Linux development is (probably) shared with Windows driver development, so now that fglrx is sync'd with the Windows codebase it's a cheap ride. Of course there's packaging, testing, etc, which is actually a lot of work - but the core code is shared.

    Pre-4xxx cards can do interesting GPGPU work, but OpenCL demands more than what older cards can do. OpenCL won't run fully on a GeForce <8k either!

    As for me, I'm planning to put my 4830 back in my quad-core and start playing with it this weekend. If I really get into it I'll probably snag a 58xx whenever it's a good enough value for me to upgrade.

  7. #37
    Join Date
    Jun 2006
    Posts
    311

    Default

    Quote Originally Posted by mattmatteh View Post
    This is great that AMD/ATI is supporting linux, but i assume this is proprietary. Is there an open source alternative, eiher as an independent package or with xorg-ati? Is there any aditional documentation needed for this ?

    I wonder how impossible it would be for this to work on older cards, and if an open source driver could take advantage of this.

    matt
    Remember that OpenCL is fundamentally HW agnostic. Multi-core CPU and multi-core GPUs are both targets (albiet for differing workloads).

    The AMD OpenCL driver that was released supports both CPU (AMD and Intel) and GPU (ATI).

    As others have suggested, OpenCL expects a certain level of capability that is very difficult to provide using older GPU hardware. If the hardware capability isn't there then you would simulate the missing functionality on the CPU. If a punt to software occurs, you may as well be using the CPU OpenCL implementation anyway.

    Regards,

    Matthew

  8. #38
    Join Date
    Oct 2008
    Posts
    3,244

    Default

    Quote Originally Posted by bridgman View Post
    If we thought the r600g driver was going to take a year to write we would have started it a long time ago

    Once we have a solid r300g base I don't think it should take too long to port the 6xx/7xx code across from the classic Mesa driver.
    Well that's very good news to hear. I know people complain when they think you guys are missing deadlines that they've heard, but a little bit more info on when these upcoming things are going to be ready would be nice even if it's very vague, like sometime next summer.

    I was just guessing based on what I've heard that the 300g driver wouldn't be ready until mesa 7.8 which i figured would be 6 months, and then tacked on another 6 to do the 600g driver.
    Last edited by smitty3268; 10-15-2009 at 02:47 AM.

  9. #39
    Join Date
    Dec 2007
    Posts
    2,404

    Default

    Only r7xx (and rv670) GPUs support double precision ops.

  10. #40
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,571

    Default

    Quote Originally Posted by smitty3268 View Post
    Well that's very good news to hear. I know people complain when they think you guys are missing deadlines that they've heard, but a little bit more info on when these upcoming things are going to be ready would be nice even if it's very vague, like sometime next summer.
    Well, there's the first mistake (not yours)

    There are no deadlines. We make rough estimates for how long a small group of developers, all working on multiple projects, will take to do something they've never done before. We try to update the estimates as new information comes in, but if anyone thinks of that as a deadline the discussion is out of control already.

    If we were talking about the third or fourth Gallium3D driver to go into everyday use we could talk about hard plans and maybe even deadlines, but the primary schedule risk for 300g is the fact that (right now) there's a good chance it will be the first. That implies more of a learning curve and even more schedule uncertainty.

    Quote Originally Posted by smitty3268 View Post
    I was just guessing based on what I've heard that the 300g driver wouldn't be ready until mesa 7.8 which i figured would be 6 months, and then tacked on another 6 to do the 600g driver.
    Ahh, I see your reasoning. It makes sense, but the thinking is 300g in 7.8 because 7.7 is too close for anyone to have confidence so 7.8 is the next option. However, the devs don't need to wait until 7.8 before starting work on 600g, just until 300g has progressed far enough that the remaining work looks like bug fixing rather than architectural or API changes. My guess is that 300g and 600g will finish quite close together in time, and hopefully by doing all the heavy lifting in 300g rather than "learning everything twice" the overall time will be minimized. That's the hope anyways
    Last edited by bridgman; 10-15-2009 at 11:46 AM.

Posting Permissions

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