Page 7 of 12 FirstFirst ... 56789 ... LastLast
Results 61 to 70 of 118

Thread: Bridgman Is No Longer "The AMD Open-Source Guy"

  1. #61
    Join Date
    Sep 2010
    Posts
    144

    Default

    Quote Originally Posted by entropy View Post
    Btw, does anybody know of an attempt to reverse engineer the UVD functionality?
    If there hasn't been such an attempt - why not?

    Maybe there are good technical arguments why this is practically impossible. (?)
    There isn't any reverse engineering effort that I know of. The reason is probably less technical and more that no one's bothered to do it.

  2. #62
    Join Date
    Oct 2010
    Location
    Amsterdam
    Posts
    290

    Default

    I like to thank John for his replies on this forum.

    I learned allot from it, and was happy the way he replied when I had a problem.
    No bs because he worked for amd.

    I am also happy he did not run away from the sometimes unfair attacks. ( unfair as in, that he was too blame for everything amd ever did, or did not )

    Tim welcome.

    I might be an optimist, but what I understand from this thread, is that AMD has learned from earlier mistakes.
    More people are now working on the linux part.

  3. #63
    Join Date
    Nov 2008
    Location
    Old Europe
    Posts
    904

    Default

    Quote Originally Posted by Plombo View Post
    There isn't any reverse engineering effort that I know of. The reason is probably less technical and more that no one's bothered to do it.
    Thanks. I was thinking of a potential deep entaglement between the UVD block and DRM/Encryption
    and thus a major obstacle to reverse-engineering efforts, even for unprotected data streams.

  4. #64
    Join Date
    Feb 2011
    Posts
    12

    Default

    Well, speaking of compilers:

    Do you have any information regarding open CL support on AMD GNC?

    Folding on AMD 7970 is worthless. PG claims that AMD sdk does not sufficiently support open CL, hence open MM is not optimized, and hence Folding Cores are not optimized.

    I know it is a topic that is a bit of a stretch for this forum....but I do see in this case where robust compilers, open Cl drivers will be paramount to the success of the HSA initiative.

    I have had my card since January, and it works well for gaming, but the compute potential of the new architecture is certainly not being utilized to its fullest across the software ecosystem.

    Blame is often directed back at AMD for failures of compilers and drivers.

    Just curious about your inside perspective and opinion if this will happen soon, or if the compute capability of discrete graphics will be eclipsed / replaced by the HSA initiative.

  5. #65
    Join Date
    Nov 2009
    Location
    Italy
    Posts
    906

    Default

    Quote Originally Posted by cube View Post
    How is that possible, that Intel has open source video acceleration for a long time (from the beginning?) on (AFAIK) nearly all graphics chips, and AMD can't do it ? And they still support DRM and HDCP on Windows - as we can see, it can be done...
    This question had been answered hundreds of times: Intel designed the decoding unit with open source in mind while amd didn't care to sunder the drm part.
    ## VGA ##
    AMD: X1950XTX, HD3870, HD5870
    Intel: GMA45, HD3000 (Core i5 2500K)

  6. #66
    Join Date
    Jun 2012
    Posts
    20

    Default

    Quote Originally Posted by mdk777 View Post
    Well, speaking of compilers:
    Do you have any information regarding open CL support on AMD GNC?
    Folding on AMD 7970 is worthless. PG claims that AMD sdk does not sufficiently support open CL, hence open MM is not optimized, and hence Folding Cores are not optimized.
    This is not true from my experience. Back in the Stream SDK < 2.4 days there were always some bugs encountered, but OpenCL is fully supported now.
    The scientific community still swears by CUDA, because nvidia dumped a lot of marketing effort into the science community. Convincing them to try OpenCL instead of CUDA, is like trying to convert a Fortran user to C/C++/..., because "Fortran is on average 10% faster" (you hear that a lot from these guys).

    I don't know who PG is, but send him some current benchmarks of similar code on CUDA and OpenCL and tell him that the SDKs are ready.

  7. #67
    Join Date
    Sep 2007
    Location
    Connecticut,USA
    Posts
    953

    Default

    Quote Originally Posted by not.sure View Post
    He probably got tired of arguing with Q
    LMAO, now the guy taking bridgman's place may be next to fall victim to Q's trolling

    At any rate, congrats to bridgman!

  8. #68
    Join Date
    Nov 2007
    Posts
    209

    Default

    Quote Originally Posted by Gps4l View Post
    I like to thank John for his replies on this forum.
    I learned allot from it, and was happy the way he replied when I had a problem.
    No bs because he worked for amd.

    I am also happy he did not run away from the sometimes unfair attacks. ( unfair as in, that he was too blame for everything amd ever did, or did not )

    Tim welcome.

    I might be an optimist, but what I understand from this thread, is that AMD has learned from earlier mistakes.
    More people are now working on the linux part.
    +1.
    and.. I long for a day when opensource AMD's linux GPU on par with Intel's

  9. #69
    Join Date
    Oct 2009
    Posts
    126

    Default

    Thanks Bridgman for all your work, patience and reponses on this forum.

    Tim, good luck in your new work!

  10. #70
    Join Date
    Feb 2011
    Posts
    12

    Default

    1. Moving to a new shader architecture (GCN), new memory management (GPUVM) and new shader compiler (llvm) at the same time. This was kind-of necessary but it meant that we had far more work in process where you couldn't see an obvious benefit. Using llvm was partly to build a good foundation for an open source OpenCL stack, and partly to get a more capable shader compiler into the graphics stack.

    This first point in Bridgeman's post is what I was talking about.

    These steps made code optimized for the previous architecture run like crap on the new.

    While your experience:

    This is not true from my experience. Back in the Stream SDK < 2.4 days there were always some bugs encountered, but OpenCL is fully supported now.
    May be true of some software, for others the deficit can run in 70-90%.

    I understand that HSA will benefit from eliminating the PCIE bus and associated legacy.

    However, it will be difficult to develop a software ecosystem when you can't model a integrated GPU on the start of the art discrete card (AMD 7970 performing worse than a AMD 6850)

    Anyway, I didn't come to complain, just asking how they see the SDK development, if they are achieving their goals.

Posting Permissions

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