Announcement

Collapse
No announcement yet.

AMD Releases Additional R600 GPU Programming Documentation

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • AMD Releases Additional R600 GPU Programming Documentation

    Phoronix: AMD Releases Additional R600 GPU Programming Documentation

    In the second NDA-free documentation dump, AMD has just released programming data on the M76 and RS690 graphics processors. While the RadeonHD developers have already had these documents, this information will help the free software community in understanding the internal workings of AMD's graphics processors. In this article, we have information on this just-released data as well as what else the community can expect in the way of documentation in the near future.

    http://www.phoronix.com/vr.php?view=11655

  • Noboutlifob
    replied
    Great site

    the Best site


    I like your site
    Thank for your work for us!

    Thank you, I will add it to my bookmarks




    best regards

    Dolly


    ___________________
    earn money on the internet

    Leave a comment:


  • highlandsun
    replied
    Originally posted by bridgman View Post
    Info on how to set up and use the IDCT/MC hardware. Some of this will be covered in the tcore drop but the bulk of the info will come after we get 3d info out there, since 3d is a pre-requisite for a lot of the video rendering stuff.
    Thanks for the response. I'll keep an eye out for those milestones.

    Leave a comment:


  • pzad
    replied
    Originally posted by chrisr View Post
    So is that "broken" as in "It's a bug in the code, and we can fix it", or as in "It's a bug and we don't know how to fix it"? Or maybe "The particular hardware doesn't support that functionality"? Or perhaps even "The hardware should support that functionality, but doesn't for some unknown reason."?

    So many possibilities...
    It is r300 driver limitation.

    https://bugs.freedesktop.org/show_bug.cgi?id=8056

    Leave a comment:


  • chrisr
    replied
    Explicit, yes. Clear? No.

    Originally posted by glisse View Post
    Regarding the problem you face the message is pretty explicit: multi-texturing is broken with dxt compressed texture.
    So is that "broken" as in "It's a bug in the code, and we can fix it", or as in "It's a bug and we don't know how to fix it"? Or maybe "The particular hardware doesn't support that functionality"? Or perhaps even "The hardware should support that functionality, but doesn't for some unknown reason."?

    So many possibilities...

    Leave a comment:


  • bridgman
    replied
    Originally posted by lucky_ View Post
    Is the schedule of each documentation release, defined by the progress of radeonhd ? You said that tcore was almost ready to publish but you needed to keep it for some reason.
    My questions is do we need to wait for the radeonhd driver to take complete advantage of the doc before a new release of doc happens ?
    When we are preparing (or, in the case of tcore, sanitizing) information for release we give it to the radeonhd developers when we think it is "pretty much the same as what we are going to release publicly" but before the final review. The final review and cleanup takes a variable amount of time depending on what we find in the review. In the case of tcore we found more references to unreleased ASICs and parts from other non-PC business units than I initially expected so we're still cleaning it up.

    This is why I'm not publishing a schedule for documentation releases, just a sequence and a rough idea of when things will happen. Until we actually get deep into the reviews and discussions we don't really know how long each activity will take. Modelling effort requirements (and hence schedule) for documentation cleanup is actually proving to be harder than modelling and scheduling software development, which is another interesting surprise. It's certainly more like modifying a large legacy code base you have never seen before than designing and writing code from scratch.
    Last edited by bridgman; 01-08-2008, 06:37 PM.

    Leave a comment:


  • yoshi314
    replied
    Well as a programmer who did spend quite bit of time on r300 i would say that current r300 driver is dead end. The code is ugly, wrongly designed and with lot of hack all around.
    well, since this time more documentation will [hopefully] be available, i'd say a total rewrite is not such a bad idea.

    i didn't think that the driver is such a mess, though. it "just works" for me all the time.

    Leave a comment:


  • lucky_
    replied
    Originally posted by bridgman View Post
    Info on how to set up and use the IDCT/MC hardware. Some of this will be covered in the tcore drop but the bulk of the info will come after we get 3d info out there, since 3d is a pre-requisite for a lot of the video rendering stuff.
    Is the schedule of each documentation release, defined by the progress of radeonhd ?
    You said that tcore was almost ready to publish but you needed to keep it for some reason.
    My questions is do we need to wait for the radeonhd driver to take complete advantage of the doc before a new release of doc happens ?

    Leave a comment:


  • bridgman
    replied
    Originally posted by highlandsun View Post
    What info is needed to implement e.g. XvMC support?
    Info on how to set up and use the IDCT/MC hardware. Some of this will be covered in the tcore drop but the bulk of the info will come after we get 3d info out there, since 3d is a pre-requisite for a lot of the video rendering stuff.

    Leave a comment:


  • val-gaav
    replied
    Originally posted by airlied View Post
    rs690 modesetting is the same as the r500 parts, so it needs atombios or radeonhd support to set modes. the 3D engine is like the 3D engine on rs480, but there is also a large chunk of work just programming the memory controller on these chips. Setting up the memory controller is tricky (maybe atombios will make it easier).

    Once the memory controller is working, the current Mesa r300 driver should work on top of it all fine, however the current Mesa r300 driver doesn't fully support "vertex shader"-less cards, googleearth and many games work, compiz however has resisted fixing, I'd hope to remedy this situation since I wrote the current "vertex shader"-less codepaths, but time as ever is the enemy.
    Thanks for the clarification on this. Now I understand why rs690 is in the radeonhd driver.

    Leave a comment:

Working...
X