Page 3 of 6 FirstFirst 12345 ... LastLast
Results 21 to 30 of 56

Thread: OpenCL Support Atop Gallium3D Is Here, Sort Of

  1. #21
    Join Date
    Sep 2008
    Posts
    332

    Default

    good to know.
    thanks

  2. #22
    Join Date
    Aug 2009
    Posts
    28

    Default

    Quote Originally Posted by bridgman View Post
    We'll have a better idea once the 3xx-5xx Gallium3D driver is further along.

    Cooper is starting to come up to speed on the r300g driver and will help there; the "plan" is still that 6xx/7xx classic mesa, 3xx-5xx Gallium3D and 6xx/7xx KMS/GEM/TTM/DRI2 will all finish off at roughly the same time. All of them seem to be pretty close now; between MostAwesomeDude's work and nha porting the shader compiler across I have to think that most of the heavy lifting for the 3xx-5xx Gallium3D driver has been done.

    Once those three are all working, we can tell you roughly how long it will take for the 6xx/7xx Gallium3D driver
    Here's hoping the 8xx driver won't lag too much.
    You seem to have so much work on your plate

  3. #23
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,409

    Default

    Remember that it's not just us doing the work. Our developers are supposed to be "a small part of a much larger community".

  4. #24
    Join Date
    Aug 2009
    Posts
    28

    Default

    I reallistically can't see outside devs bringing a full-featured driver for a just-released hardware. And I can't see AMD releasing specs way before the hardware is selling.
    So community work will always be good for infrastructure, porting and debugging, but the core work has to be done by insiders if it's meant to be on time (not years after the hardware is on the shelves).

  5. #25
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,409

    Default

    Depends what you mean by "core work". I agree that our time is generally best spent adding support for new GPUs, since that is the one area where access to inside information can speed up understanding and troubleshooting even if the inside information can't be released.

    That said, there are also a few places where pitching in a bit of effort might be able to "push something over the hump" and make it possible for community developers to make progress on other parts of the stack. That's how I see the 3xx-5xx Gallium3D driver, and why I think it's worthy of some time.
    Last edited by bridgman; 09-02-2009 at 11:41 AM.

  6. #26
    Join Date
    May 2009
    Posts
    80

    Default

    Hopefully basic 3d accel and KMS for r600+ will make it to Fedora 12

  7. #27
    Join Date
    Aug 2009
    Posts
    28

    Default

    Quote Originally Posted by bridgman View Post
    Depends what you mean by "core work". I agree that our time is generally best spent adding support for new GPUs, since that is the one area where access to inside information can speed up understanding and troubleshooting even if the inside information can't be released.

    That said, there are also a few places where pitching in a bit of effort might be able to "push something over the hump" and make it possible for community developers to make progress on other parts of the stack. That's how I see the 3xx-5xx Gallium3D driver, and why I think it's worthy of some time.
    Exactely. r300g is both infrastructure (looking to improving Gallium3D) and porting work, so it's best done by the community but can be done only on that kind of hardware: many years old (r300 is 7 years old) and well-known by people outside AMD.

    But an r800g driver could only be made by AMD (otherwise it'd be ready in 2016), that's why I hope you'll manage to get it out on time.

  8. #28
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,409

    Default

    I expect that the first step for Evergreen 3D will be adding support to the classic Mesa driver - that will get functionality into users hands much more quickly.

    Once support has been added to the classic mesa driver, anyone in the community can write "r800g".

  9. #29
    Join Date
    Aug 2008
    Posts
    77

    Default

    I have to say that the plans outlined by bridgman are all very reasonable, and I agree that it's the Right Thing for going forward.

    We've had a short discussion about r300 vs. r300g on IRC without any real conclusion. Obviously, the long term focus will be on r300g, there's no doubt about it; the question is whether classic Mesa will get OpenGL 2.0 support.

    Personally, I increasingly side towards not adding OpenGL 2.0 to the classic driver. Better to stabilize it at an OpenGL 1.5 level for the conservative folk, and then focus on getting up to OpenGL 2.1 for Gallium.

  10. #30
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,409

    Default

    Yep. Once r300g gets a bit further it will (hopefully) become a lot easier to decide where each new feature should be implemented, and at that point it seems likely that anything more than low-hanging fruit will go into r300g. Right now there's a strong temptation to add functionality to r300 "because it is there".

    If we can continue to share the shader compiler between r300 and r300g (thank you !!) I guess it's possible that r300 may end up as "1.5 plus GLSL" but there may be other driver enhancements required to support GLSL that I haven't realized yet. I have no ideal how GLSL arrays are implemented, for example
    Last edited by bridgman; 09-02-2009 at 03:10 PM.

Tags for this Thread

Posting Permissions

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