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

Thread: 3d development

  1. #1
    Join Date
    Dec 2006
    Posts
    82

    Default 3d development

    I remember reading around that 3d on the R500 is *similar* to the R300 and might be able to be ported. I understand there are some differences that make it harder rather than easier. (mentioned in Dave Airlie's blog)

    Does anyone know if there is any ongoing work on this front going on with mesa dri driver development? Or are developers waiting for the docs before proceeding?

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

    Default

    It's a bit of both. Since most of the display, modesetting and video overlay stuff are controlled by registers we can create extracts of the register information, turn them into documents, and have a pretty good start. There are still questions and gaps but they're manageable.

    On the 3d side there's a lot more interaction between the registers (plus the fact that a lot of the work is done through the command processor and never touches registers) so simple register-by-register documentation isn't really enough. Our current plan (which still seems on track) is to make more use of sample code on the 3d side, by open-sourcing some of the new OpenGL driver. We're thinking about patching that into the existing R3xx+ mesa driver so that the code can actually be executed and used (and, most likely, re-written ).

    In shorter words, yes developers are waiting for the docs but since we plan to provide some working code along with the docs it won't take as long to get up to speed.

  3. #3
    Join Date
    Dec 2006
    Posts
    82

    Default

    Sounds good.

    I look forward to having 3d on my desktop again. (8.40 doesn't play well with f8)

  4. #4
    Join Date
    Jul 2007
    Posts
    405

    Default

    About the 3d backend code you keep talking about. Is it similar in function to the driver end of gallium3d? Could it be converted to a functional gallium3d driver without a lot of architectural changes?

    This would be huge, because it would be a big leg-up on driver development to be able to use Gallium's state tracker.

    I really like the look of Gallium3d. I'm not a very experienced programmer, but it seems like a very elegant approach to me to separate "translating" graphics operations and providing a high-level interface for the api.

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

    Default

    We're looking at that now. There are definitely some non-trivial differences -- a big one is that we put the shader compilers further up the stack than gallium does so some of the mid-level APIs are very different -- but the design objectives were certainly pretty similar, and both were optimized for fully shader-based chips.

    Should be able to give a better answer in a couple of weeks.

  6. #6
    Join Date
    Jul 2007
    Posts
    405

    Default

    Even with the differences, it sounds like a mostly functional gallium3d driver might not be to hard to build, even if parts of the existing code have to be re-written. Reusing code is always good .

    With that advantage, I guess building a traditional mesa driver wouldn't make a lot of sense, so Gallium3d is probably the way to go.
    Last edited by TechMage89; 01-03-2008 at 05:48 PM.

  7. #7
    Join Date
    May 2007
    Posts
    233

    Default

    Quote Originally Posted by TechMage89 View Post
    Even with the differences, it sounds like a mostly functional gallium3d driver might not be to hard to build, even if parts of the existing code have to be re-written. Reusing code is always good .

    With that advantage, I guess building a traditional mesa driver wouldn't make a lot of sense, so Gallium3d is probably the way to go.
    The gallium driver in itself might be easy but to get somethings on the screen (my guess is that most people want to see their 3d application on screen, but that just a wild guess ) you need many pieces to be put together and this is the tricky part where in my opinion X provide a real painfull infrastructure: dri. Hopefully dri2 looks a lot more better than current dri.

  8. #8
    Join Date
    Jul 2007
    Posts
    405

    Default

    The linux graphics system needs a lot of improvements. It looks like it's going to get the though. I just hope it's sooner rather than later.

  9. #9
    Join Date
    Dec 2006
    Posts
    82

    Default

    Is the 3d stuff still expected out of AMD sometime this quarter?

  10. #10

    Default

    The tcore information, etc should be out soon.

Posting Permissions

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