Page 2 of 4 FirstFirst 1234 LastLast
Results 11 to 20 of 31

Thread: In Road To OpenCL, R600g LLVM Back-End Arrives

  1. #11
    Join Date
    Aug 2009
    Location
    Russe, Bulgaria
    Posts
    505

    Default

    As I see in the git branch, thare is shitload of code ~85k locs, devoted to AMDIL. I believe this is the real AMD IL used in the proprietary driver, since I can't believe even Tom can't write so much code for 2 months. This is just fantastic, and really shows how much AMD are devoted to FOSS. This makes me proud owner of AMD's platform. Thanks Tom.

  2. #12

    Default

    you will not (1) export, re-export or release to a national of a country in
    Country Groups D:1, E:1 or E:2 any restricted technology, software, or source
    code you receive hereunder.
    -1000 for the license. This code is not open source.

    Open source doesn't just mean access to the source code. The distribution terms of open-source software must comply with the following criteria:

    1. Free Redistribution

    The license shall not restrict any party from selling or giving away the software as a component of an aggregate software distribution containing programs from several different sources.

    http://www.opensource.org/osd.html

  3. #13
    Join Date
    Nov 2008
    Location
    Germany
    Posts
    5,411

    Default

    Quote Originally Posted by AnonymousCoward View Post
    -1000 for the license. This code is not open source.
    i think this is just against the law "Country Group A - Bureau of Industry and Security (BIS)": http://www.google.de/url?sa=t&rct=j&...N1v5pA&cad=rja

    a License can only be in the law not out of the law. http://www.bis.doc.gov/encryption/lechart1_sec508.htm

    but this doesn't matter evil countries can easily transfer this code to russia,china,iran and so one.
    Last edited by Qaridarium; 12-10-2011 at 01:24 AM.

  4. #14
    Join Date
    Mar 2007
    Location
    DG, IL, USA
    Posts
    195

    Default

    Exciting..One step closer to being able run FAH on the gpu under linux..
    Those who would give up Essential Liberty to purchase a little Temporary Safety,deserve neither Liberty nor Safety.
    Ben Franklin 1755

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

    Default

    Quote Originally Posted by AnonymousCoward View Post
    -1000 for the license. This code is not open source.
    I'll check that with our legal folks. The license doesn't seem to conflict with the portion of the definition you quoted, but there's a section further down the definition text which says that reminding licensees about the need to comply with export control law is OK but adding restrictions directly is not.

    The license text on the AMDIL bits appears to reference the current US export laws and qualifies the restriction based on the type of content (ie basically saying "if the US export control laws restrict it then you can't export...", not sure whether that qualifies or not since the restriction only applies to "restricted" content and the definition of restricted presumably comes from the current BIS regs.

    any restricted technology, software, or source code you receive hereunder
    Last edited by bridgman; 12-10-2011 at 10:01 PM.

  6. #16
    Join Date
    Nov 2007
    Posts
    1,353

    Default

    I'm not sure I understand the need for all these abstractions... I thought the whole point of gallium was to make a single abstraction so that others wouldnt be required? Shouldnt it just be clover >> tgsi >> gpu, if run on the gpu, or clover >> llvm >> cpu, if run on the cpu?

    Also would performing all these redundant translations effectively hurt end performance.... doesnt translating from this to that to these to those hurt performance? also assuming that one IR is less capable than another, (thinking of opengl) wouldnt you lose capability during one or more of these translations?
    Last edited by duby229; 12-11-2011 at 12:40 AM.

  7. #17
    Join Date
    Nov 2008
    Location
    Germany
    Posts
    5,411

    Default

    Quote Originally Posted by bridgman View Post
    I'll check that with our legal folks. The license doesn't seem to conflict with the portion of the definition you quoted, but there's a section further down the definition text which says that reminding licensees about the need to comply with export control law is OK but adding restrictions directly is not.

    The license text on the AMDIL bits appears to reference the current US export laws and qualifies the restriction based on the type of content (ie basically saying "if the US export control laws restrict it then you can't export...", not sure whether that qualifies or not since the restriction only applies to "restricted" content and the definition of restricted presumably comes from the current BIS regs.
    how it works to make the code structure of AMDIL compatible with Gallium3D?

    a simple rewrite? or a automate translating tool? or a chance in Galium3D ?

    how is this possible in the past the official point was its not possible to use fglrx/catalyst source code in the galium3D driver.

    or is this only true for graphic stuff?

  8. #18
    Join Date
    Jul 2008
    Location
    Germany
    Posts
    638

    Default

    Quote Originally Posted by Qaridarium View Post
    how is this possible in the past the official point was its not possible to use fglrx/catalyst source code in the galium3D driver.
    AMD IL is not an big secret and if you want you can implement it http://developer.amd.com/sdks/amdapp...ication_v2.pdf

  9. #19
    Join Date
    Jan 2007
    Posts
    459

    Default

    Quote Originally Posted by AnonymousCoward View Post
    I don't get all this hype about OpenCL. I'm sure that there are some specialized niche applications making use of OpenCL but as a consumer I'd rather see AMD devoting some manpower to finally get video decoding working on the open drivers.
    given the year+ of stated legal review to be put in place to finally open up the UVD decode block for linux use that never seems to actually happen, and the fact that they cant even be bothered to compile and release the OpenCL OpenVideo driver for Linux video decode library that apparently relies on that closed UVD code block, and has existed for the windows SDK for a full year....

    then you have as much chance (aka almost nil) of them doing that video decoding work now, as the so called HD 7000 Series ,the latest and greatest GCN (Graphics Card Next, got to love those PR innovators and their names to sell it to the masses) architecture has of actually dumping that closed Obsolete and dead UVD block and actually replacing it with a real open Linux usable hardware assisted video decode and actual Video ENCODE with SW patches within another 3 years, unlike the Intel and ARM/NEON cores that have that hardware encode/decode block capability right now, and perhaps far more importantly, are actively sending GIT patches to the FFMPEG/AVCONV developers etc. to make use of these HA blocks today.
    Last edited by popper; 12-11-2011 at 07:35 AM.

  10. #20
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,404

    Default

    Quote Originally Posted by duby229 View Post
    I'm not sure I understand the need for all these abstractions... I thought the whole point of gallium was to make a single abstraction so that others wouldnt be required? Shouldnt it just be clover >> tgsi >> gpu, if run on the gpu, or clover >> llvm >> cpu, if run on the cpu??
    I think that is pretty much the plan, although our current thinking is clover >> llvm >> gpu for compute without using tgsi. The glsl ir >> tgsi >> llvm >> gpu path is just for testing right now but I think we'll use it for initial GCN support as well.

    Quote Originally Posted by duby229 View Post
    Also would performing all these redundant translations effectively hurt end performance.... doesnt translating from this to that to these to those hurt performance? also assuming that one IR is less capable than another, (thinking of opengl) wouldnt you lose capability during one or more of these translations?
    The translations tend to be pretty cheap compared to the processing that is done with the translated results. IIRC the only translations in the production stack are GLSL IR>>Mesa IR for older graphics drivers and GLSL IR>>TGSI for Gallium3D drivers. If LLVM works out OK for GCN we'll probably keep the GLSL IR>>TGSI>>LLVM IR>>GPU path until the next round of serious discussions about IR. If no consensus forms and it turns out the TGSI>>LLVM IR translation is expensive then I guess it would make sense to generate LLVM IR directly from GLSL IR up in the common Mesa code, so the graphics path for GCN would be glsl ir >> llvm ir >> gpu.

Posting Permissions

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