Page 4 of 5 FirstFirst ... 2345 LastLast
Results 31 to 40 of 41

Thread: AMD Releases Additional R600 GPU Programming Documentation

  1. #31
    Join Date
    Jan 2008
    Posts
    177

    Default

    What info is needed to implement e.g. XvMC support?

  2. #32
    Join Date
    May 2007
    Posts
    228

    Default

    Quote Originally Posted by chrisr View Post
    There are far simpler programs than Compiz that have trouble with the Mesa R300 driver. Try the "rubik" hack from xscreensaver, for example...

    And I'm not sure if this message is trying to warn me of a driver bug or a hardware limitation either:

    Has any of the new documentation allowed for the R300 driver to be enhanced further without reverse engineering?
    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. Truly what is needed is a rewrite and i see gallium as an opportunity to do so and do it right from the beginning. Unfortunately we are in a business with short time frame and i am sure more manpower will be put into patching r300 to have somethings working as soon as possible.

    Regarding the problem you face the message is pretty explicit: multi-texturing is broken with dxt compressed texture.

  3. #33
    Join Date
    Dec 2007
    Posts
    248

    Default

    Quote 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.

  4. #34
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,279

    Default

    Quote 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.

  5. #35
    Join Date
    Dec 2007
    Posts
    91

    Default

    Quote 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 ?

  6. #36
    Join Date
    Sep 2006
    Location
    PL
    Posts
    906

    Default

    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.

  7. #37
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,279

    Default

    Quote 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 at 05:37 PM.

  8. #38
    Join Date
    Jul 2007
    Posts
    428

    Default Explicit, yes. Clear? No.

    Quote 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...

  9. #39
    Join Date
    Jan 2008
    Posts
    3

    Default

    Quote 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

  10. #40
    Join Date
    Jan 2008
    Posts
    177

    Default

    Quote 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.

Posting Permissions

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