Announcement

Collapse
No announcement yet.

AMD Continues Updating Its R500 Documentation

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

  • phoronix
    started a topic AMD Continues Updating Its R500 Documentation

    AMD Continues Updating Its R500 Documentation

    Phoronix: AMD Continues Updating Its R500 Documentation

    It was over two years ago that AMD first released its R500 3D programming documentation to the general public without any NDAs, which was followed by the R600/700 3D documentation along with older R300-class documents as well. While we have yet to see proper 3D programming documentation for the ATI Radeon HD 5000 "Evergreen" GPUs that were released last year, the R500 3D documentation continues to be revised...

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

  • V!NCENT
    replied
    @MostAwesomeDude,
    Would a 9800pro (older r3x0) be useful?

    Leave a comment:


  • Temar
    replied
    Originally posted by MostAwesomeDude View Post
    http://www.x.org/wiki/CorbinSimpson lists the cards I have.
    You got a lot of old crap :-)

    Feel free to send me cards I don't have, but I make no guarantees about what I do with them. :3
    Are you interested in Nvidia cards, too? I got a Nvidia 7xxx and a 8xxx. Maybe a 9xxx, too if I can find it. And if you are lucky I might even find some old crap cards in my drawer from different vendors (mostly Nvidia) :-)

    Leave a comment:


  • Dieter
    replied
    > Depends on what you mean by complete.

    Complete meaning that everything we might want/need to know about how
    to use the chip is documented and available on the web with no NDA.

    datasheet: pinout, Voltages (min, max, etc.), timing diagrams, etc.
    the usual EE stuff.

    programming: how to use *all* the features.

    > DSPs would be OK for implementing codec du jour except there aren't any
    > DSPs in a typical PC system while there are usually is a pile of shader engines.

    My (feeble) understanding is that DSPs would be better than shaders due to
    (1) integer vs floating point, (2) they would use less power and (3) maybe
    be less expensive. (There is also the FPGA approach, but FPGAs are expensive
    and power hungry.) E.g. if you are starting from scratch designing a
    programmable video decoder, DSP would be the best way to go? Less
    expensive and lower power consumption than decoding using a CPU or using
    a GPU's shaders?

    Leave a comment:


  • nanonyme
    replied
    Originally posted by bridgman View Post
    For clarity, we didn't promise to separate out DRM from decode, just to make sure the issue of useability with open source drivers *was* on the table with future designs and that we did proceed *if* the impact on cost & performance was not prohitive.

    In other words we promised to *try*, no more.
    Fair enough, simply putting the matter on the table during planning meetings is already a good thing.

    Leave a comment:


  • agd5f
    replied
    For reference, the xvmc/vaapi decode support in the intel driver is shader-based (at least for pre GMA 4500HD asics).

    Leave a comment:


  • whizse
    replied
    Originally posted by MostAwesomeDude View Post
    In all seriousness, I was referring to the idea that there might be GPUs out there that have full-on MPEG-4 decoding onboard, that are fully supported by some open driver. </thatsthejoke>
    Intel, I guess, for G45 and up, but I haven't tried it myself yet.

    Not sure how they handled the whole DRM situation though...

    Leave a comment:


  • agd5f
    replied
    On cards prior to r6xx, video decode was done using the 3D engine (there was no UVD on those asics), so the hardware is capable and the documentation is available.

    Leave a comment:


  • MostAwesomeDude
    replied
    Originally posted by Temar View Post
    What do you need and in which country do you live in?
    http://www.x.org/wiki/CorbinSimpson lists the cards I have. Feel free to send me cards I don't have, but I make no guarantees about what I do with them. :3

    In all seriousness, I was referring to the idea that there might be GPUs out there that have full-on MPEG-4 decoding onboard, that are fully supported by some open driver. </thatsthejoke>

    Originally posted by TheCycoONE View Post
    Does this documentation mean we're a step closer to getting FSAA support in the open source drivers?
    Yes! Somebody read the article!

    I have a series of patches that does MSAA on r300-r500 for Gallium, and I'll merge that as soon as it works correctly. Also, SSAA will be trivial in Gallium; somebody just has to write up a bit of glue and add support for the SSAA extension in GL. (And also maaaaybe extend DRI/GLX. Ugh.) FSAA might be tricker, depending on exactly how the HW works. Supposedly, it's in r300-r500, but I haven't quite confirmed. Come to think of it, I'm not sure if the code I have right now is MSAA or FSAA. Figures.

    Leave a comment:


  • bridgman
    replied
    Depends on what you mean by complete. I don't think we have any more documentation in the pipe for 5xx and earlier so I guess you could say it's complete now.

    The new documentation should halp with implementation of MSAA.

    DSPs would be OK for implementing codec du jour except there aren't any DSPs in a typical PC system while there are usually is a pile of shader engines.

    Leave a comment:

Working...
X